Dear Justin:
Your answer is comprehensive and very helpful :-) Great thanks :-) Best Regards Brent On Wed, 9 Jan 2013 12:38:06 -0500, Justin Richer wrote: > 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). 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 : >> >>> 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] [8] 写于 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 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] [2] >>>> https://www.ietf.org/mailman/listinfo/oauth [3] >>>> -- >>>> Thanks & Regards, >>>> Prabath >>>> >>>> Mobile : +94 71 809 6732 >>>> >>>> http://blog.facilelogin.com [4] >>>> http://RampartFAQ.com_______________________________________________ [5] >>>> OAuth mailing list >>>> [email protected] [6] >>>> https://www.ietf.org/mailman/listinfo/oauth [7] >> _______________________________________________ >> OAuth mailing list >> [email protected] [10] >> https://www.ietf.org/mailman/listinfo/oauth [11] > > _______________________________________________ > OAuth mailing list > [email protected] [12] > https://www.ietf.org/mailman/listinfo/oauth [13] Links: ------ [1] mailto:[email protected] [2] mailto:[email protected] [3] https://www.ietf.org/mailman/listinfo/oauth [4] http://blog.facilelogin.com [5] http://RampartFAQ.com_______________________________________________ [6] mailto:[email protected] [7] https://www.ietf.org/mailman/listinfo/oauth [8] mailto:[email protected] [9] mailto:[email protected] [10] mailto:[email protected] [11] https://www.ietf.org/mailman/listinfo/oauth [12] mailto:[email protected] [13] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
