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

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

The problem with the original 'type' parameter and the flows in general is that they tried to address a specific use case and then got expanded (or overloaded) with other use cases. The user-agent and web-server flows became the foundation of native applications, and there were people discussing using native application techniques for user-agent clients. At the end, the flow names and prose became more confusing than helpful (I'm not talking about the grouping of normative language).

The key here is to figure out what information about the client the server actually needs, what it should obtain during registration, and what it can figure out from other parameters. For example, if a client_id has a matching secret, do you allow it to request an access token directly in the authorization endpoint? If you do, is it going to include the same capabilities as an access token obtained using an authorization code and client authentication? It seems like we need to address these questions head on.

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.

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).

EHL




On 7/10/10 9:26 PM, "Brian Eaton" <[e-mail]> wrote:

On Sat, Jul 10, 2010 at 9:05 PM, Eran Hammer-Lahav <[e-mail]> wrote:
> There is no user-agent flow anymore.

Yeah.  That's a bug. =(

> The request was to allow it to
> obtain both when using a web-based component together with the user-agent.

Right, this didn't use to be possible, but Brian Ellin asked for this,
and several people agreed it was a good idea.  Unfortunately when that
feature got added, it broke a bunch of other stuff:
- all of the descriptive language about the user-agent flow is inaccurate
- if anyone tries to use the verification code approach with the
user-agent flow, the user-agent flow is no longer efficient

So in the quest to add a new feature, we broke other features.  Plus
we didn't get the new feature right.  This sounds like a normal
software development project. =)

Let me know what you think of the new language I proposed.

Note that this pretty much requires that the "type" parameter return
to the authorization URL.  That's a good thing.  If authorization
servers know about the client environment, they do a better job of
meeting the client's needs.

(Also note that we tried leaving this parameter out of WRAP, and
regretted it afterwards.)

Cheers,
Brian