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
