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
