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" <n...@daaku.org> wrote:
> On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lahav <e...@hueniverse.com>
> 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
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
