> -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > 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. > > 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. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
