Justin Richer <[email protected]> 写于 2013-01-10 01:38:06: > Brent, > > If you're sending the code in the back channel directly to the Client, > as I believe you're doing from your text below, I would like you to > realize some things: > > 1) This is not OAuth, and is in fact antithetical to the OAuth way of > solving the connection problem. > 2) You are actually lowering your overall security because the access > code is no longer bound to any particular browser session with either > the client or the AS. > 3) If you're sending it directly, there is no longer any point of using > the code, since the Client is just going to turn around and send it to > the AS again to get a token. Why not just send the token? But again, > this is still not OAuth. > > > Think about it this way: There are three connections in the common OAuth > Authorization Code scenario, which is why it's known as a three-legged > OAuth flow in many circles. Each of these legs has unique properties, is > protected by different things, and is exposed to different pieces of > knowledge at different times. > > 1) Client <-> User Agent: protected by a local session of the Client's > choosing. For Web based clients this is often standard HTTP session > cookies or similar, potentially backed by a login of some type by the > user to the Client as well. This session is never exposed to the > Authorization Server. > 2) Authorization Server <-> User Agent: protected by a local session of > the Authorization Server's choosing, normally through some kind of > Primary Credential (login) that the user has a the AS. Importantly, > these credentials are never exposed to the Client. > 3) Client <-> Authorization Server: protected by the client credentials, > which are, importantly, not exposed to the user or user agent. > > By sending the code as part of the redirect, the Client is able to prove > that the User Agent actually went to the Authorization Server (2) and > got something. The Authorization Code is then sent through the bottom > leg (3) of the channel to verify that it really did come from the > Authorization Server in the context of the user that was just there in > (1).
How is Client assured the UA actually went to AS and got something by the following URL? A： GET/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com C: HTTP/1.1302Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz In other words, this mechanism that you seem to be avoiding is > exactly what makes OAuth secure. > > If you instead send the code through (3), then the Client as no way at > all of knowing that the user in (1) ever went to the authorization > server via (2). All the Client knows is that they sent the user > someplace and that a magic code showed up. It is very, very, very > dangerous and a very, very bad idea to assume that a code coming in the > back channel (3) has anything at all to do with any particular session (1). > > This approach does *not* mitigate any real security threats, and in fact > introduces a great number of others, as described here. There are much > better ways to protect the Authorization Code, and most of the best > practices are enumerated in the security considerations document. Some > of the most common are: > > 1) Make Authorization Codes one-time-use (even if you try and fail, it's > thrown away) > 2) Make Authorization Codes time out after a very short period (minutes > or seconds) > > > I hope this helps. > > -- Justin > > > > On 01/09/2013 01:42 AM, Peng Zhou wrote: > > Dear SuJing: > > > > If it is the only reason, why we send the authorization code to the > > client directly and send another notification without the > > authorization code to the RO. This way can mitigate the chance that > > the authorization code is exposed to the RO's user-agent, hence > > protecting the authorization code from leaking to possible attackers > > in a higher security levle. > > > > Best Regards > > Brent > > > > 2013/1/9 <[email protected]>: > >> Then why not let auth code be sent directly from AS to Client? > >> > >> Just want to inform RO that an auth code has been dilivered to Client? > >> > >> [email protected] 写于 2013-01-09 14:27:50: > >> > >>> Hi Brent, > >>> > >>> Few points, why this doesn't create any security implications.. > >>> > >>> 1. Authorization server maintains a binding to the Client, who the > >>> token was issued to. To exchange this to an Access token client > >>> should authenticate him self. > >>> 2. Code can only be exchanged once for an acces token. > >>> > >>> Thanks & regards, > >>> -Prabath > >>> On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc <[email protected] > >>>> wrote: > >>> Dear All: > >>> > >>> I have a question in the section 1.3.1. Authorization Code in rfc6749 > >>> The OAuth 2.0 Authorization Framework. > >>> > >>> It tells "which in turn directs the resource owner back to the client > >>> with the authorization code." > >>> > >>> Who can let me know the reason why is the authorization code sent to > >>> client through a redirection in resource owner's agent? Any security > >>> implications? > >>> > >>> Is it possible to let the authorization server send the authorization > >>> code to the client directly (not through resource owner's user-agent)? > >>> > >>> Best Regards > >>> Brent > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> -- > >>> Thanks & Regards, > >>> Prabath > >>> > >>> Mobile : +94 71 809 6732 > >>> > >>> http://blog.facilelogin.com > >>> http://RampartFAQ.com_______________________________________________ > >>> OAuth mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
