Thanks! That sounds great. On Tue, Jul 13, 2010 at 3:00 PM, Eran Hammer-Lahav <[email protected]>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" <[email protected]> wrote: > > > On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lahav <[email protected]> > > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
