Re: [OAUTH-WG] OAuth abstractions

  Martin,

great to see you contributing to the WG!

One question came into my mind: How do the other grant types (assertion, 
username/password, refresh token) fit into your abstractions? The grant 
type used also depends on the client and its capabilities, so just 
returning a single URL pointing to an access token resource might not be 
suffice.

To give an example:

Alice stores her contacts at contacts.example.com.

She uses 2 clients, one on the PC and one on a mobile phone. The PC 
client uses the standard redirect-based process. The mobile phone client 
cannot use this process because of technical limitations (small screen 
size, sparse computing power, no integration API for embedding the 
browser or custom schemes). Therefore this client uses the 
username/password flow in order to get authorization and obtain a 
refresh token. The implications with respect to the flow:
PC client: redirect to end-user authorization endpoint
Mobile phone client: access to the tokens endpoint with the user's 
credentials

So although the resource server's URL is the same in both cases, 
different URLs will be utilized to process the authorization flow.

regards,
Torsten.

Am 22.10.2010 00:36, schrieb Thomson, Martin:
> At the last meeting, I promised Blaine that I'd share a few thoughts on how I understood OAuth to operate.  It's taken me a while to find the time to marshal my thoughts, but here 'tis.
>
> After attending the meeting and tutorial, it was clear that the abstraction behind OAuth is not being effectively communicated.  A simple abstraction can be a powerful tool in dealing with a complex specification.  It seems to me that OAuth struggles as a result of trying to cover so many use cases at once.  This might be easier if the abstract model were better understood.
>
> I believe that OAuth has a very simple abstraction.  What I am going to try to do is describe that abstraction.
>
> The cunning techniques employed to circumvent technical limitations - redirection with URI fragments and so forth - are noise on the wire at this layer.  As a necessary product of having to reduce the abstraction to practice, they have little bearing on what I am going to attempt to describe.
>
> I appreciate that the process is well beyond this airy-fairy stage.  If nothing else, I hope that this jostles a few brain cells into new ways of looking at OAuth.
>
> To preface this with a warning: There's been a lot of discussion about the OAuth "protocol" and examination of its properties from the perspective of it being a thing that "uses HTTP".  There's a lot of HTTP experience that teaches the long term folly of trying to build on top of HTTP.  I'm probably going to beat on a dead horse by explaining where working _with_ HTTP (as opposed to _despite_ it) has significant advantages.
>
>
> ==First Abstraction
>
> OAuth specifies a separation between authentication and authorization.
>
> Never mind that HTTP got these mixed up early on, it doesn't now - HTTP only provides authentication.  The "Authorization" header is for authentication.  That might be implicitly used to infer authorization, but it's still fundamentally just authentication.
>
> OAuth lets a Client come to a Resource Server with separate evidence for identity and authorization.
>
> ==Goal
>
> A Client's goal is to acquire a resource from the Resource Server.  Or, to be more general, to successfully complete a particular type of (HTTP) request.
>
> In order to do this, authentication is not sufficient, the Client must also prove that it is authorized.
>
> The Client might be known to the Resource Server.  This is the authentication part.  There are existing mechanisms for that (the idea that these might be improved is a subject that comes up on occasion).  [1]
>
> ==Proving Authorization
>
> Once the Client is authenticated (or not) the Resource Server might still reject the request.  There's an HTTP 403 (Forbidden) response for this purpose.
>
> If this were at all like an HTTP 401 response, that rejection could provide the clues that could be used by the Client to determine how to acquire evidence of authorization (what OAuth calls the Access Token).
>
> I don't know if anyone has proposed this, but it seems logical to extend HTTP and work within its framework, thus:
>
>    1. Add a header to the 403 (Forbidden) response.  This header would indicate that irrespective of the identity of the client, further evidence of authorization is required (that is, an Access Token).
>
>    2. Add a request header that is intended to carry an access token.
>
> The first might be a little complex.  Unlike the 401 response, OAuth has a number of variations on how an Access Token is required and this constrains the information that can be revealed at this point.
>
> This 403 header might include virtually no clues at all.  Maybe the equivalent of "realm" - some private identifier that helps those in the know distinguish between one set of authorization requirements from another.  What information is revealed depends on the desired security properties.
>
> ==Access Token
>
> It's tempting to say that the Access Token is completely opaque to all but the Authorization Server and the Resource Server.  A private agreement between these parties could be used to determine what information is included.
>
> In the abstract sense, the definition of the request header could just provide a bit bucket for a token.  In the macro, that's all the solution requires.
>
> Obviously, the work doesn't stop there.  To ignore the access token entirely would be trivializing all the work that has been done in this area.  A separate authorization function is an important feature.  Structured agreements, such as the SAML assertions, have a significant role and formalizing formats can be extremely powerful.
>
> Then there are the security concerns that arise when you wave your hands.  Saying "magic happens here" means that people create their own magic.  And that never really works out well.
>
> So define two things:
>   - how to acquire an access token
>   - what the access token looks like, what data it contains, necessary bindings and so forth
>
> The access token format is where you get into signatures and the like.  It also depends a lot on what the use cases are and the security properties that you desire.  I'm going to concentrate on the acquisition thing first and foremost.  The format should follow from that.
>
> ==Acquiring an Access Token
>
> If the Access Token is view as an opaque lump of data [2], then there's an HTTP method that's well suited to this task: GET.
>
> GET goes a surprisingly long way to accomplishing this task.
>
> Say that the 403 response included - in the responses header, maybe a Link header - a URI.  That URI could be the URI for an Access Token resource.  Require authentication of the Client in order to successfully acquire the contents of this resource and you have dealt with the basic scenarios shown in Figures 2 and 3 of the -10 version of the spec.
>
> This URI might not directly refer to the Access Token resource.  It could lead to a chain of HTML pages that need to be navigated successfully to get to the token.
>
> The same basic abstraction also applies to the Access Grant.  The Access Grant and Access Token share a surprising number of common characteristics.  They both carry authorization information, independent of authentication.  The only difference is where they are acquired from.  An Access Grant is an Access Token for the Access Token resource.  Both are optional: the only difference being that if you don't use an Access Token, you aren't using OAuth.
>
> What if the Access Grant and Access Token used the same mechanism?  Then you just have a chaining of the same process:
>
>    Client goes to Resource Server, gets 403, 403 points to Authorization Server
>    Client goes to Authorization Server, gets 403, 403 points to Resource Owner
>    Client goes to Resource Owner, gets Access Token A (an Access Grant).
>    Client takes Access Token A to Authorization Server with Access Token A, gets Access Token B
>    Client takes Access Token B to Resource Server, gets resource
>
> You could see how this could recurse.
>
> (It also occurs that you could also parallelize the process too and require multiple Access Tokens.  The analogy would be something like: "you must first collect the sword of Knorr, the sceptre of Manoth and the crown of Zaxx before you can claim the throne of Orion".  I don't know if this fits into the existing model at all, or even if it makes sense at all.)
>
> ==Other Stuff: Crazy Out of Band Ideas
>
> That's really the core of the idea that I had, but there are a few things that I think are worth considering.
>
> Implicit in my description is the fact that the entity that demands an Access Token (Resource Server, Authz Server) needs to know about the entity that produces it (Authz Server, Resource Owner).  I don't think that this is an unreasonable constraint.  The consumer of the Access Token has to know who produced it to check whether or not the Token can be trusted enough.
>
> That could be used to push a number of things out of scope for the specification.  (Again, with due caution regarding the security properties - it might still be necessary to describe these uses, even if the on-the-wire formats aren't defined.  On-the-wire formats might still be part of external work.)
>
> A lot of specification goes into specifying the things that are being exchanged between Resource Server and Authorization Server.  These could almost all be deferred to other specifications or only talked about from the security perspective.
>
> For instance, the current request for an Access Token includes a client_id.  The reason for this is to ensure that the Access Token is correctly bound to a specific Client - so that another client can't use the token [3].  When it is assumed that the Resource Owner knows about the Authz Server, we can also assume that the Resource Owner is able to direct the Client to the Authz Server so that the Access Token it produces has the necessary bindings.
>
> Another example is the redirect.  If the client follows the link to the Authorization Server, a Referrer header might be observed by the Authorization Server.  Once the Authorization interaction is complete, the Authorization Server could redirect back to the URI it first saw.  Alternatively, this information might be buried in the URI with the other junk, as described above.  There's no need to formalize this mechanism if the agreement is private.
>
> E.g.
>    Client goes to Resource Server, gets 403 response.  The 403 contains a URI that, along with identifying the Authorization Server, includes in an opaque portion that contains additional information: the client identity, the resource the client is trying to access, and other constraints.  The Resource Server knows how to construct this URI so that the Authorization Server can make sense of this.  By navigating to this resource, the Client ultimately acquires an Access Token - probably some sort of document with a media type that identifies it as an Access Token.
>    Client brings the Access Token back to the Resource Server.  The Resource Server cracks that token open and checks it: is it valid? is it from an Authorization Server that I trust? is it for the current resource? is it for the current requester? is it valid right now?  If a check fails, the request is rejected; if they all pass, the request is permitted.
>
> Formalizing the exchange between Resource Server and Authorization Server lets an arbitrary Resource Server use an arbitrary Authorization Server.  There are good use cases for this, but they are secondary to the function I describe above.  Separating that makes a great deal of sense.
>
> ==Other Stuff: Slightly Wacky Ideas
>
> What if the resource that provides the Access Token provided the Access Token to any and all who asked?  That's not unreasonable if the token can only be used by an authenticated Client.
>
> If the resource didn't exist until the Client was authorized, then that would make this more effective.
>
> Or, maybe better yet, the resource might exist anyway, but the Client isn't told about the resource until they are authorized.  Anyone that knows the URI can use it freely, but only the authorized are ever granted knowledge of the URI.  The only condition is that the URI is hard to guess.  (See RFC5808 for a different application of this concept and a discussion of the limitations.  I'm also aware that this might have other issues in a web environment, because URIs don't stay secret with Referrer headers and the like.)
>
> In this model, the URI and Access Token are interchangeable.  If you have the URI, you can give it to someone and that's just as good as giving them a token.  This might be useful for some of the more extreme use cases.
>
> ==No-so-thin Client
>
> A lot of focus has been placed on using a client that doesn't understand OAuth for each of the use cases.  The use of redirection, particularly with URI fragments, belies this.  None of what I've suggested is impossible, it just requires that the Client have some control over the content of the HTTP requests that it makes.
>
> That doesn't require explicit support from an HTTP client, just the ability to make requests and set the content of headers.  Such support has been table stakes for a long time.
>
> Regards,
> Martin
>
>
> [1] Note that authentication is not strictly necessary, it might be sufficient to provide evidence of authorization as described in the counter-examples here: http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars/2
>
> [2] Copious caveats - as I mentioned, treating the Access Token as an opaque blob is merely a useful abstraction.  It gets you a long way.  Before you have to worry about specifics you can understand a lot about the goals and how those goals are achieved.
>
> [3] It's interesting that the Access Token producer doesn't need to validate the client identifier.  As long as they aren't duped about who they are producing the Access Token for, they don't care that the entity that is asking is the same or not - only the consumer of the token needs to check that it is OK.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth