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

[Luke Shepard <[e-mail]>]

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.

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

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.

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)
2/ If the user requests either token or code_and_token, then the response comes in the fragment. Else, in the url.
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.