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:oauth-boun...@ietf.org] On Behalf Of Gil Kirkpatrick
Sent: Wednesday, July 23, 2014 10:29 AM
To: 'Richard Snowden'; oauth@ietf.org
Subject: Re: [OAUTH-WG] Please help me understand OAuth 2.0
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:oauth-boun...@ietf.org] On Behalf Of Richard Snowden
Sent: Wednesday, 23 July 2014 2:57 AM
To: oauth@ietf.org<mailto: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
