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