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