On Fri, Jun 25, 2010 at 12:07 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Thursday, June 17, 2010 2:56 PM > >> >> 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. > > But those are two different parts of the client. Returning a direct access > token uses the fact that the end-user it present which provides a measure of > security because a good UI can help explain to the end-user what is going on > and put context into the transaction. If we force clients who need the access > token both in the client and on the server to use only the code mode, then > they need to find a way to share that access token. However, an access token > issued using a code and client secret will potentially have more power than > an access token issued using the user-agent direct communication. > > The alternative of using both flows means annoying the end-user.
Not if the second flow is done in immediate mode. >> > 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. > > I think relying on immediate mode is a possible but more complex solution > which can break depending on the state of cookies and sessions. Not sure if a JavaScript client can reliably work without an immediate mode. Access tokens are short lived, the user would have to approve every single renewal (which could be every hour). Again, all I am saying is that it would help to have a very detailed use case for this token_and_code mode, to see if it is really needed. Or, an actual implementation. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
