On Thu, Jun 17, 2010 at 2:30 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Thursday, June 17, 2010 11:08 AM >> To: David Recordon >> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user >> authorization endpoint >> >> Yes, I am aware of that thread. I did ask some questions there which are >> unanswered. > > Please repeat them so we can address them now.
That's what I did below. >> Basically, why cannot be that problem solved by 2 different requests, both >> done by the JavaScript layer? >> >> If latency is a problem, it would be good to know exactly where. I assume >> that authorization codes are issued very infrequently. Does this new >> token_and_code mode eliminate a transaction every two weeks? >> Does that make a difference? > > The advantage of the user-agent flow is that it address the lack of client > authentication with the presence of the end-user. The server might not know > who the client really is, but it does know that the right user is sitting in > front of the client authorizing the request. It doesn't solve phishing but it > provides some security. Sure, but how is this affected by token_and_code? The authz server knows who the user is when it issues the access token and the authorization code. The authorization code is passed down to the client server and now the client server asks for access/refresh tokens. No user this time but potentially there is a client secret. > In the case where a client (native application or user-agent) works in tandem > with a server-based component, using just the web-server flow has two > disadvantages I'm aware of: the client has to be more complex because it > requires callbacks in order to obtain the access token from the server > (multiple calls and more complex calls than just a simple server-hosted > script), The JavaScript client can either use the authorization code with a direct call (as you probably suggest), but then it cannot pass the authorization code down to the client server anymore. The JavaScript client can do a separate User-Agent call in immediate mode to get an access token directly. This is what it would normally do. No point in swapping the authorization code since it can be exchanged only once. > but it also lose the benefit of the user presence for security. With the User-Agent immediate call this is not lost. > The problem is now moved to the communication between the server component > and the user-agent component of the client. > >> Also, when and authorization code is issued I guess it cannot be an >> immediate request. If an approval page is shown to the user anyhow, then a >> subsequent immediate request to also grab an access token makes no >> difference at all. > > Why not? Both the web-server and user-agent flows were supposed to have > immediate mode. I was saying that it makes no difference from a latency perspective, The end user just clicked an "Approve" button and was redirected, and extra call (direct or immediate) will probably not be felt at all. Thanks, Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
