The client in the is case is a server. The front channel involves making indirect connection through the user agent.
The back channel is a direct TLS protected server to server communication without the users browser in the path. John B. On 2012-11-29, at 7:01 PM, Ariel Barreiro <[email protected]> wrote: > Aha, maybe that's the bit that I didn't understand that good then... front > channel and back channel, although I can see difference I am not quite sure > of how is it different on the implementation > > Client request to the auth end point is through a browser... fine, you send > the redirect uri. After authenticating you get back to the redirect_uri with > the auth code. > > Isn't it the client, again, with the auth code, the one that initiates the > request to the token end point? I see no different channel on the requests. > > > On Thu, Nov 29, 2012 at 7:44 PM, Justin Richer <[email protected]> wrote: > The request to the auth endpoint is front channel, through a browser. The > request to the token endpoint is back channel, server-to-server. These are > very, very different attack surfaces. If an attacker has access to and > control of both channels, you're pretty hosed anyway and OAuth (nor TLS, nor > basically anything else I can think of) will help you. > > The security model in OAuth comes from limiting the knowledge at each part of > the transaction and spreading the risk appropriately. > > -- Justin > > > On 11/29/2012 04:43 PM, Ariel Barreiro wrote: >> But so the protection of sending the SAME redirect_uri in both the auth end >> point and token end point makes not much of a sense when there is a >> registered URI, and if there's not, an attacker, as far as I understood, can >> compromise both the request to the auth end point as well as the token end >> point, so I would assume that it doesn't make much sense either. >> >> >> On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer <[email protected]> wrote: >> So here's the breakdown of how the redirect uri works: >> >> >> >> - If the client sends a redirect URI to the auth endpoint, and the client >> has registered one or more redirect URIs, it MUST match one of the redirect >> URIs it had registered. (for a soft definition of "match" -- it can be >> prefix, or pattern, or exact string, so long as the AS knows how to do it, >> IIRC) >> - If the client does not send a redirect URI to the auth endpoint, and the >> client has either only registered one or the AS has some notion of a >> "default" redirect URI, the AS will just use that one. >> >> Now the part that seems to trip people up: >> >> - If the client had sent a redirect URI to the auth endpoint, then it MUST >> send the EXACT SAME redirect URI to the token endpoint. This request is >> back-channel and protected with the client's credentials. >> - If the client did not send a redirect URI to the auth endpoint, then it >> does NOT send a redirect URI to the token endpoint. >> >> >> So here's where the protection comes in. If the attacker modifies the >> request to the auth endpoint so that it has a different redirect URI, then >> that redirect URI MUST match one that's attached to the client_id in the >> request. Furthermore, the call to the token endpoint to get the token MUST >> also contain that modified redirect URI as well as any client credentials >> needed to make the call. A "good" client will send a "good" redirect URI, >> even if the code has been sent someplace else in the mean time. >> >> Hope this clears things up, >> >> -- Justin >> >> >> On 11/29/2012 04:24 PM, Ariel Barreiro wrote: >>> But isn't having a registered redirect URI on the authorization end point >>> enought to prevent this, why is it required to send the redirect URI to the >>> token end point if the previous method prevents it? >>> >>> I appreciate a lot your response but I am still finding it hard to picture >>> it, and, was in your explanation a modification to the request URI? >>> >>> >>> On Thu, Nov 29, 2012 at 6:25 PM, John Bradley <[email protected]> wrote: >>> A confidential client authenticates to the token endpoint preventing an >>> attacker from getting the token. >>> >>> In the case of a public client if you get the code and redirect URI then >>> you can get the token. (Why confidential clients are better than public >>> ones) >>> >>> Sending the redirect URI to the token endpoint protects the client from the >>> case where client A gets a code for user B because the user logged into A >>> and A is using the client ID of client Z because it wants to impersonate >>> user B at client A. Client A pretending to be client Z can easily get >>> the code. However the redirect URI that the real client Z sends will be >>> different than the one the fake client Z used to get code and the real >>> client A won't be able to exchange the code for a access token and be >>> tricked into thinking that the resource owner is the one presenting it the >>> code. >>> >>> That is the long explanation. The short one is unregistered redirect URI >>> are bad. Sending the redirect URI to the token endpoint protects clients >>> from becoming confused about the presenter of the code. >>> Nothing is going to help a public client if someone intercepts code. >>> >>> John B. >>> >>> On 2012-11-29, at 3:05 PM, Ariel Barreiro <[email protected]> wrote: >>> >>>> Still I can't see how to prevent the attack. I understand that there is >>>> no redirection when requesting an access token, however, the protocol >>>> requests the client to send the redirect_uri to the token end point to >>>> validate it was the same used in the authorization. If the authorization >>>> was compromised, couldn't the access token request be forged as well? >>>> >>>> >>>> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt <[email protected]> wrote: >>>> There is no redirection when requesting an access token. Token requests >>>> are typically out-of-band from the user. The attack only happens during >>>> an authorization redirect flow in the browser. >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> [email protected] >>>> >>>> >>>> >>>> >>>> >>>> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >>>> >>>> > I am struggling a bit to understand this attack and the advice in to how >>>> > to prevent. I understand that if I, as an attacker, can change the >>>> > redirection uri when authorizing, can not it as well change the redirect >>>> > uri when requesting an access token? >>>> > >>>> > Any explanation examples on how this attack might work and how sending >>>> > the redirect_uri when requesting the access toekn prevents it are >>>> > welcomed. >>>> > >>>> > Thanks, >>>> > Ariel.= >>>> > _______________________________________________ >>>> > 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 >> >> > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
