Subject: [OAUTH-WG] Please help me understand OAuth 2.0

From: Richard Snowden <[email-masked]>
Date: Wed, 23 Jul 2014 11:57:14 +0200

I am pretty familiar with the WS-* and SOAP Web Services world. At the
moment I'm trying to understand which features are available in the OAuth
2.0 world.

1) SAML tokens: This access token in OAuth 2.0 - is it similar to what SAML
tokens are for?

2) STS: Is an OAuth 2.0 Authorization Server the equivalent to a STS?

3) PDP (Policy Decision Point): Is this also handled by the OAuth 2.0
Authorization Server? Or does the Resource Server, based on the access
token, have to make the decision whether or not  grant access to a resource?

---

From: "Gil Kirkpatrick" <[email-masked]>
Date: Wed, 23 Jul 2014 10:28:46 -0700

The RFCs 6749 and 6750 are a good place to start. http://tools.ietf.org/html/rfc6749 and http://tools.ietf.org/html/rfc6750. 

The first thing to understand is that OAuth2 targets a very specific use case of a user authorizing an application (like Twitter) access to resources they own (like photos) through a resource server (like Facebook). It’s more an authN/authZ framework than a complete system, and doesn’t directly address the traditional enterprise use cases. Once you get your head around that, the rest is pretty straightforward. Because it’s lightweight and thin, OAuth2 can be used in lots of authN/authZ scenarios, for instance  OpenID Connect http://openid.net/connect/ and UMA http://docs.kantarainitiative.org/uma/draft-uma-core.html.

You’d be best off clearing your mind of SAML concepts and reading the RFCs, but to answer your questions:

1.      Not really. Access tokens represent a user-granted authorization for a specific application to access a specific resource scope. The semantics of a scopes are left to the developer, but you can think of a scope as a representation of what access(es) are allowed to what resource(s). There is no user identity information necessarily conveyed in the access token… that is what OpenID Connect is for. OpenID Connect maps pretty closely to SAML.

2.      Sort of. When the resource owner grants access, the AS issues an authorization grant code. The client then presents the grant code to the AS for an access token. The client includes the access token with each resource request, and the resource server uses the scope in the token to determine if access should be granted or not.

3.      The role of the PDP is split between the AS and the RS. The AS provides a token representing the user’s consent to access of a particular scope, and the RS interprets the scope to grant access. The scope _could_ just be a Boolean value indicating that access is allowed or not, in which case the AS would be a PDP, but in practice the scope encodes a set of permissions that the RS interprets in the context of the specific resource request.

HTH,

-gil

From: OAuth [mailto:[email-masked]] On Behalf Of Richard Snowden
Sent: Wednesday, 23 July 2014 2:57 AM
To: [email-masked]
Subject: [OAUTH-WG] Please help me understand OAuth 2.0

I am pretty familiar with the WS-* and SOAP Web Services world. At the moment I'm trying to understand which features are available in the OAuth 2.0 world.

1) SAML tokens: This access token in OAuth 2.0 - is it similar to what SAML tokens are for?

3) PDP (Policy Decision Point): Is this also handled by the OAuth 2.0 Authorization Server? Or does the Resource Server, based on the access token, have to make the decision whether or not  grant access to a resource?

---

From: Mike Jones <[email-masked]>
Date: Wed, 23 Jul 2014 17:33:54 +0000

FYI, the individual submission draft http://tools.ietf.org/html/draft-jones-oauth-token-exchange describes adding something analogous to WS-Trust token exchange to OAuth 2.0.  That will be discussed at the OAuth working group meeting tomorrow.

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Gil Kirkpatrick
Sent: Wednesday, July 23, 2014 10:29 AM
To: 'Richard Snowden'; [email-masked]
Subject: Re: [OAUTH-WG] Please help me understand OAuth 2.0

HTH,

-gil

From: OAuth [mailto:[email-masked]] On Behalf Of Richard Snowden
Sent: Wednesday, 23 July 2014 2:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] Please help me understand OAuth 2.0

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 23 Jul 2014 23:01:15 +0300

Hi,

On 23/07/14 20:28, Gil Kirkpatrick wrote:
> The RFCs 6749 and 6750 are a good place to start.
> http://tools.ietf.org/html/rfc6749 and http://tools.ietf.org/html/rfc6750.
>
> The first thing to understand is that OAuth2 targets a very specific use
> case of a user authorizing an application (like Twitter) access to
> resources they own (like photos) through a resource server (like
> Facebook). It’s more an authN/authZ framework than a complete system,
> and doesn’t directly address the traditional enterprise use cases. Once
> you get your head around that, the rest is pretty straightforward.

IMHO OAuth2 is becoming much bigger... Take the client credentials 
grant. People are using it today in the traditional scenarios, because 
OAuth2 tokens have good security properties.

Cheers, Sergey

> Because it’s lightweight and thin, OAuth2 can be used in lots of
> authN/authZ scenarios, for instance  OpenID Connect
> http://openid.net/connect/ and UMA
> http://docs.kantarainitiative.org/uma/draft-uma-core.html.
>
> 1.Not really. Access tokens represent a user-granted authorization for a
> specific application to access a specific resource scope. The semantics
> of a scopes are left to the developer, but you can think of a scope as a
> representation of what access(es) are allowed to what resource(s). There
> is no user identity information necessarily conveyed in the access
> token… that is what OpenID Connect is for. OpenID Connect maps pretty
> closely to SAML.
>
> 2.Sort of. When the resource owner grants access, the AS issues an
> authorization grant code. The client then presents the grant code to the
> AS for an access token. The client includes the access token with each
> resource request, and the resource server uses the scope in the token to
> determine if access should be granted or not.
>
> 3.The role of the PDP is split between the AS and the RS. The AS
> provides a token representing the user’s consent to access of a
> particular scope, and the RS interprets the scope to grant access. The
> scope _/could/_ just be a Boolean value indicating that access is
> allowed or not, in which case the AS would be a PDP, but in practice the
> scope encodes a set of permissions that the RS interprets in the context
> of the specific resource request.
>
> HTH,
>
> -gil
>
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *Richard Snowden
> *Sent:* Wednesday, 23 July 2014 2:57 AM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] Please help me understand OAuth 2.0
>
> moment I'm trying to understand which features are available in the
> OAuth 2.0 world.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Gil Kirkpatrick" <[email-masked]>
Date: Wed, 23 Jul 2014 16:21:06 -0700

>> IMHO OAuth2 is becoming much bigger... Take the client credentials grant.
People are using it today in the traditional scenarios, because OAuth2
tokens have good security properties.

Agreed. 

-gil