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 [email protected]https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
