oauth2: web-client and resource-server in one

[Fred]

Hi,

 

can anyone give me a hint regarding this:

https://groups.google.com/forum/?fromgroups#!topic/dotnetopenid/7PE5JZ4QapM

 

I think my problem is, that in that scenario the web-client plays two oauth2-roles: the role of the client as well as the role of the resource-server.

For me, it seems, that DNOA currently doesn't provide a clean solution for this though this scenario should be conform with oauth2.

 

Please correct me or confirm me ...

 

Wishes,

Fred

 

[David Christiansen]

Hi Fred, 

Using OAuth for the scenario single application you are depicting seems overkill to me but maybe I am misunderstanding you. Are you certain you require you need to use OAuth - My point is that are much simpler solutions when the 'client' of a 'resource' is the same application.

Regards,
DC

[Fred]

Hi David,

 

I think, that depends on the sight. The mentioned client is a web-application and I want the user to authenticate against it with a pre-existing identity of which only the auth-server is aware of. That would allow the user to sign into my web-application using his or her twitter-identity (if twitter supports oauth 2).

 

I've implemented such scenarios using ws-trust/saml as well as using OAuth WRAP/SWT and wondering, how to implement this with OAuth 2 by the use of DNOA.

 

Wishes,

Fred

[Andrew Arnott]

Twitter does not support OAuth 2.  And even if it did, if your scenario is ultimately to log users in with remote identities, then your web site isn't a resource server after all.  Thus far you've explained your site as both the client and resource server, but the resource server (when OAuth 2 is misused as an authentication protocol) is the one that exchanges an access token for the user's identity, so that would make Twitter the resource server rather than your site.  

In which case, although I still advocate OpenID 2.0 (and eventually OpenID Connect when that's stable and available), your question should be answerable by this:

don't try to deserialize the access token -- it's not for you -- it's for Twitter, or whatever the real resource server is.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

 

Wishes,

Fred

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/XWg-uDVCSkIJ.

To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

[Fred]

Hi Arnott,

 

thx in adv for this reply. I think, this leads to an interesting discussion. On the one side, OAuth (2) is defined as authorization protocol, as you mentioned. On the other side, it seems to be used for authentication too (apart the fact, that authentication needs some form of authorisation). For instance, the Windows Azure Access Control uses OAuth WRAP to enable Users to log into a Web-App. using credentials they have at facebook, google and so on. In addition to this, OAuth WRAP as well as OAuth 2 distinguish between the resource server and the auth server, which would make single-sign-on-solutions easier. There are some samples on the web, that use OAuth 2 to log into REST-services as it seems to fit quite good in the World of REST (for instance, http://zamd.net/2012/05/04/claim-based-security-for-asp-net-web-apis-using-dotnetopenauth/).

 

What do you think about thouse arguments?

 

Let's assume, that in my sample I don't use a preexisting oauth 2 auth server but an onwn one. In this case the resource server would need the possibility to decrypt the received token, wouldn't it?

 

Wishes,

Manfred

 

[Andrew Arnott]

On Sat, Jul 14, 2012 at 9:43 PM, Fred <manfred...@gmx.net> wrote:

thx in adv for this reply. I think, this leads to an interesting discussion. On the one side, OAuth (2) is defined as authorization protocol, as you mentioned. On the other side, it seems to be used for authentication too (apart the fact, that authentication needs some form of authorisation).

I'm not sure I follow your reasoning.  Authentication is merely proving who I am -- it grants no privileges to the person receiving that confirmation. Whereas authorization is granting permissions to access some protected data, which may or may not include my identity.  While overlap exists in some applications, it is not necessary and often muddies the water.

 

For instance, the Windows Azure Access Control uses OAuth WRAP to enable Users to log into a Web-App. using credentials they have at facebook, google and so on.

I'm not nearly as familiar with ACS so I can't comment on that.  Except to say that authorization protocols can be (mis?)used as authentication protocols. I hope and expect Microsoft did so very carefully so as to not introduce security holes in the process.

 

In addition to this, OAuth WRAP as well as OAuth 2 distinguish between the resource server and the auth server, which would make single-sign-on-solutions easier.

Yes, they do separate those two roles, but I fail to understand how that makes SSO easier.  I've built SSO solutions using OpenID and it seemed straightforward enough at the protocol level.  In SSO there seems to only be two roles so I don't see how splitting up the auth server and resource server into two roles helps SSO.  But I'm happy to learn if you would please explain it to me.

 

There are some samples on the web, that use OAuth 2 to log into REST-services as it seems to fit quite good in the World of REST (for instance, http://zamd.net/2012/05/04/claim-based-security-for-asp-net-web-apis-using-dotnetopenauth/).

Yes, I sort of agree.  OAuth 2 is perfect for services.  But that's not because you're "logging into" them.  You're authorizing clients to call into the service on your behalf.  And the client may not even know who they represent -- only that they represent someone's account.

 

 Let's assume, that in my sample I don't use a preexisting oauth 2 auth server but an onwn one. In this case the resource server would need the possibility to decrypt the received token, wouldn't it?

Resource servers always need to be able to validate access tokens, whether that means verifying a signature or passing it on to the auth server to ask for verification (DNOA takes the former route).  Resource servers often also need to know what the access token represents (the user, the client, the granted scope) and therefore must be able to decrypt the token or get that info from the auth server as well.  So yes I agree in DNOA the resource server needs to be able to decrypt the access token, and DNOA has the facility to do that, which it sounds like you've already discovered.

[Fred]

Hi Arnott,

 

thx for thouse infos and your patience!!

 

Let me put my mental barrier regarding this into a sample.

 

Let's say, I would like to implement some rest-services and for thouse services I need both, authentication as well as authorization. And let's further assume, I don't want to store credentials for this service but re-use existing identities. For that, I would like to use google as an "identity provider" (security token service) or an own implementation that stores ids of my customers and is re-used in several projects.

 

Now my questions.

 

- Would it be ok in this case, to use oauth 2 for authentication as well as authorisation to prevent the need for implementing both, oauth and OpenId ? The caller could send a token he or she got from the google oauth 2 auth svr to the rest service and the rest service could use this token to access profile-data of this user at google - data like a friendly user-name, the email-address and so on. This data enables the rest-server to authenticate the user and also to authorize the user (because, there is -- for instance -- some table, that says that te...@test.com is an admin).

 

- Would this scenario also be ok, if I used my own auth server that I use for all my other projects too? In this case I could simplify things by sending claims about the user (username, email-address etc.) within the aouth 2 token as extra data. As in this case, the rest-service is the resource-server, it could directly decrypt the token and fetch this extra data.

 

Thanks for this discussion and best wishes,

Fred

 

[John Bradley]

OAuth tokens are not audience restricted to the client.  This allows for several trivial attacks when you start passing around the tokens.

Facebook Connect using OAuth 2.0 is completely insecure as a result of this in many existing implementations.

OpenID Connect introduces standard methods to prevent this attack.

Rolling your own SSO with OAuth 2.0 may or may not be secure depending on your design.

I can't review every home grown design, that is why there is a openID Connect standard in the final stages, and a security warning in OAuth 2.0 cautioning people about some of the attacks OAuth itself is not intended to prevent.

Large respected sites you are currently using are in the process of trying to shut down the holes that they have created.  So you need to be careful about just copying a example from Facebook, Apple, ForeSquare and others.   

This old blogpost of mine goes into some of the issues.

http://www.thread-safe.com/2012/04/followup-on-oauth-facebook-login.html

John B.

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/oI-yHHeeqbMJ.

[Fred]

Hi John,

thx for your reply. To put it in a nutshell: for security reasons, it is a bed idea to authorize a service via a oauth token to access my google-profile to find out my google-user-id, email-address and name to authenticate and authorize me.

Is that correct?

Wishes,
Fred

[John Bradley]

It is not bad to use OAuth to authorize a service to get your information.

The problem is that depending on the flow anyone you have ever given access to your google profile can also do exactly the same thing.

The client can be authorized to get the info, but can not assume the person presenting the token is you.

It is the difference between authentication and authorization.

John B.

> --
> You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/6RHoXi-Zo3cJ.

[Fred]

I see. Thx and wishes
Fred

[Fred]

Hi John,

 

at [1], google describes how to login with google using OAuth 2. So it seems, that they are mis-using OAuth 2 for authentication, don't they?

 

They mention, that every received token has to be validated by sending it to a specific url (see section Validating the Token). The response contains an audience which should be the requesting application.

 

Is this one of the workarounds, you mentioned, people implement, to shut down security issues when misusing OAuth 2 for authentication?

 

Is sending around the state-variable another workaround that addresses this issue?

 

Wishes,

Fred

 

[1] https://developers.google.com/accounts/docs/OAuth2Login

[Andrew Arnott]

Yes, including the audience in the response (and the client validating that it is the expected value) is the mitigation for this security vulnerability.

The state variable addresses a different security issue.

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/5gCpcIP3M9YJ.

To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--