Re: [OAUTH-WG] OAuth abstractions

["Thomson, Martin" <[e-mail]>]

Hi Torsten,

On 2010-10-22 at 18:44:56, Torsten Lodderstedt wrote:
> 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.

The form of grant becomes a secondary concern.  Whether the resource owner provides a username/password, SAML assertion, or they just redirect to a secret URI, the process is the same.  

The resource owner passes information to the authorization server that says: this person who is making this request (optionally: who can authenticate that they are this identity) is authorized to access this resource (optionally: the resource is explicitly identified).  That resource in the context of your question is the access token; it's no different for the resource that is the goal of the whole thing [1].

> 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

Note that I'm still dealing with an abstraction at this point.  The fact that this information is passed via the client is the important concern, particularly for security reasons, because the client is a shifty, nasty individual that can't be trusted at all.

Ideally, the mobile phone client doesn't need to do anything any differently, other than (perhaps) provide a different UI.  

UI is the problem.  The real concern is the potential HTML UI that has to be navigated to grant/gain authorization.  The mobile can't cope with HTML, presumably.  If this were just HTTP, it would be no trouble.

The resource that provides the access token might be accessible using username/password alone (i.e. requiring authentication, but not explicit authorization), but as long as this is only HTTP, it's not a problem. [2]

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

Directing a constrained client to a different URL might be one way to solve the problem.  Another possible way is to use conneg: have the PC client send "Accept: */html" in the request to indicate that it's willing to tolerate HTML UI.  When the mobile client doesn't, it gets different treatment.

--Martin

[1] _THE_ resource.  Maybe this needs a special name too.

[2] I'll leave aside the point that a user might not trust the client with their username/password, but I guess that we can easily create temporary ones for this...

> regards,
> Torsten.
> 
> Am 22.10.2010 00:36, schrieb Thomson, Martin:
> > blah blah blah...