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

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

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