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.
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:oauth-boun...@ietf.org] *On Behalf Of *Richard Snowden
*Sent:* Wednesday, 23 July 2014 2:57 AM
*To:* oauth@ietf.org
*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?
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?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
