Hi,

can anyone give me a hint regarding this:
*https://groups.google.com/forum/?fromgroups#!topic/dotnetopenid/7PE5J...
*<https://groups.google.com/forum/?fromgroups#!topic/dotnetopenid/7PE5J...>

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

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

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

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

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-...
).

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

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.

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.

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.

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.

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.

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 t...@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

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.

On 2012-07-15, at 10:00 AM, Fred wrote:

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

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.

On 2012-07-15, at 12:35 PM, Fred wrote:

I see. Thx and wishes
Fred

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.

--
--
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