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

[Bouiaw <[e-mail]>]

Could you explain how the token fragment is removed between step C and
D in the user agent profile ?
I don't understand how the http redirect request can be modified by
the user agent ....

On Wed, Jul 14, 2010 at 7:58 AM, Naitik Shah <[e-mail]> wrote:
> 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
>> >
>> >
>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>