Re: [OAUTH-WG] user-agent flow needs a rewrite

[Eran Hammer-Lahav <[e-mail]>]

On 7/13/10 1:06 AM, "Luke Shepard" <[e-mail]> wrote:

> 
> On Jul 11, 2010, at 6:37 AM, Eran Hammer-Lahav wrote:
> 
>> The server can¹t trust what the client is asking unless the client is
>> authenticated *and* the server can trust that authentication (i.e. Client
>> secret not used in a user-agent). For that, you need to establish some form
>> of trust with the client which in today¹s world means registration. If you
>> are going to perform registration, that¹s where you should ask about the
>> nature of the client so you can optimize the user experience and the overall
>> security.
> 
> There are examples of clients that pre-register, but operate in multiple
> contexts. For example, an app may have both a web and a mobile version, and
> require different auth flows depending. We have found it useful to be able to
> specify in the request what type of client is making the request.

The same client credentials should not be used in two different environment
where the security considerations are fundamentally different. For example,
the same client identifier and secret should not be used by a user-agent and
web-server to exchange an authorization code.

> I am a big fan of pre-registration but I prefer being explicit in the request
> about what should be returned.

Only when it serves an actual function (i.e. How to return parameters, which
parameters to return). Not for enforcing a security policy (that would be
silly and insecure).

>> The way I understand the Twitter use case is that the client isn¹t just a
>> user-agent trying to get both an access token and authorization code (or
>> refresh token), but a more complex client which includes both a user-agent
>> and web-based components, each providing a different functionality, but both
>> using the same, single end-user authorization (i.e. The end-user is asked
>> once).
> 
> Facebook also really wants this. And we'd like to be able to return the
> verification code in the fragment.

How is the client going to exchange this for an access token?

> I just read this bit:
> 
>    If the response type is "code_and_token", the authorization server
>    adds the "code" and "state" parameters to the redirection URI query
>    component and the "access_token", "scope", and "expires_in" to the
>    redirection URI fragment using the
>    "application/x-www-form-urlencoded" format as defined by
> 
> That strikes me as very odd - returning some params in the query, and others
> in the fragment is just weird. I think the request should specify whether it
> wants the response in the fragment or query. There are a few ways to do this:
> 
> 1/ Use a 'type' param, and define the response format along with the type (for
> instance, user-agent means it's returned in the fragment)

I have no problem with a response format request parameter, but I am not
sure what the purpose is (other than making it look less odd :-)). The
current text is based on the assumption that the user-agent is never going
to directly use the authorization code (because that requires it to have
access to the client credentials and if that is the case, it can just use
the web-server profile).

> 2/ If the user requests either token or code_and_token, then the response
> comes in the fragment. Else, in the url.

This forces the client to make another call to the server (not covered by
the redirection call which is the obvious place to handle this) to hand over
the authorization code. Again, if the client itself is exchanging the code,
what's the point?

> 3/ Create another parameter to specify how the response should come.
> 
> My preference is for #1, but I know you've tried to wrangle the spec and
> decided not to - and that seems fine. So then I would prefer #2.

Any decision made is open for debate.

My takeaway from this is that we clearly don't have a well-understood use
case. My understanding is that at the end of this hybrid mode, the
user-agent ends with one access token, and the web-server ends with another
access token. Neither side sees the access token issues to the other side
(which allows granting different access levels based on the level of client
authentication), and the user-agent never has access to the client
credentials.

EHL