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

[Naitik Shah <[e-mail]>]

Thanks! That sounds great.

On Tue, Jul 13, 2010 at 3:00 PM, Eran Hammer-Lahav <[e-mail]>wrote:

> This is clearly a third flow - hybrid (of user-agent and web-server) - and
> not just a variant of the user-agent flow. It should be presented with its
> own flow diagram and description. I also think the user-agent and
> web-server
> flow names are misleading. They need to be replaced with more descriptive
> names. Something like (I don¹t like these, just trying to demonstrate):
>
> Web-server --> 2 step flow (get code, get token)
> User-agent --> direct flow (get token)
> Hybrid --> hybrid flow (get code and token, get token)
>
> In an attempt to accommodate Brian's request for more concentrated flow
> descriptions, I am working on coming up with come middle ground between -05
> and -10.
>
> ----
>
> As for the specification of the end-user authorization endpoint:
>
> Please answer this based on actual use cases. When returning parameters
> using the redirection URI call, which of these combinations make sense?
>
>         | Code | Token | Code & Token
> ---------+------+-------+--------------
> Fragment |  a   |   1   |   3
> Query    |  2   |   b   |   c
> Split*   | n/a  |  n/a  |   d
>
> * token in fragment, code in query
>
> Known use cases:
>
> 1 - current user-agent flow
> 2 - current web-server flow
> 3 - as described by Brian and Naitik
>
> Questionable use cases:
>
> a -
> b -
> c -
> d - current -10 code-and-token proposal
>
> EHL
>
>
> On 7/13/10 2:27 PM, "Naitik Shah" <[e-mail]> wrote:
>
> > On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lahav <[e-mail]>
> > wrote:
> >> This looks reasonable, however, I am no longer see the value in the
> hybrid
> >> mode of token and code. If the code is passed in the fragment, the
> client has
> >> to pass it to the server. If that is the case, why can¹t the server
> reply
> >> back with the access token? Is the entire purpose just a performance
> >> optimization so the client doesn¹t have to wait for the server response
> >> before it has an access token?
> >>
> >
> > I think there are two use cases here, and they are not mutually
> exclusive.
> > Some apps are mostly just server side, and would end up doing a full page
> > refresh, and here the code in the query param would probably be
> acceptable.
> > Some apps are mostly just client side, and here the code is irrelevant
> and the
> > access token in the fragment is all that matters. But we also have
> hybrids
> > where we want the code in a cookie/JS callback, and we'll also use the
> access
> > token on the client to dynamically update the UI by accessing some
> protected
> > data (this is what the Data enabled XFBML tags do in the Facebook JS SDK
> for
> > instance). While the server can do the code to access_token exchange, it
> can't
> > return it to the JS safely if it does not support https. Even if it did,
> it
> > would mean more overhead for the developer to build an endpoint that does
> this
> > work and cooperates with a JS SDK which wants the access_token for making
> API
> > calls.
> >
> >
> > -Naitik
> >
> >
>
>