Subject: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation"

From: Ariel Barreiro <[email-masked]>
Date: Thu, 29 Nov 2012 14:53:30 -0300

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.=

---

From: Phil Hunt <[email-masked]>
Date: Thu, 29 Nov 2012 10:01:50 -0800

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-masked]

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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Ariel Barreiro <[email-masked]>
Date: Thu, 29 Nov 2012 15:05:07 -0300

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-masked]> 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-masked]
>
>
>
>
>
> > 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.=

---

From: Justin Richer <[email-masked]>
Date: Thu, 29 Nov 2012 13:29:36 -0500

This is why OAuth strongly suggests that Clients pre-register a set of 
valid redirect_uris, so that the URI being presented to the Auth 
Endpoint MUST match one that's been registered ahead of time.

  -- Justin

On 11/29/2012 01:05 PM, Ariel Barreiro 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-masked] 
> <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
>
>
>
>
>
>     > 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.=
>     > [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Nov 2012 17:25:32 -0300

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-masked]> 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?
> 
>

---

From: Ariel Barreiro <[email-masked]>
Date: Thu, 29 Nov 2012 18:24:56 -0300

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-masked]> wrote:

> 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.
> 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?
>
>
>> > 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

---

From: Justin Richer <[email-masked]>
Date: Thu, 29 Nov 2012 16:35:45 -0500

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-masked] 
> <mailto:[email-masked]>> 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.
>     On 2012-11-29, at 3:05 PM, Ariel Barreiro <[email-masked]
>     <mailto:[email-masked]>> 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?
>>
>>
>>         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/>
>>         > 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.=

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Nov 2012 18:39:58 -0300

Sending it to the token endpoint is only supposed to be required when you are not using a registered redirect URI.

Some authorization servers always require it, that is allowed by the spec but not required. 

Unregistered redirect URI were intended to allow deep linking or embedding other arbitrary query parameters in the redirect URI. 
Those things should be in state but some people wanted this alternative.

John B.

On 2012-11-29, at 6:24 PM, Ariel Barreiro <[email-masked]> 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?
> 
>

---

From: Ariel Barreiro <[email-masked]>
Date: Thu, 29 Nov 2012 18:43:44 -0300

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-masked]> wrote:

> - 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
> - 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.
>
>
> 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.
>
> picture it, and, was in your explanation a modification to the request URI?
>
>
>>  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)
>>
>>  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.
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 29 Nov 2012 16:44:45 -0500

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-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>     - 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,
>>     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?
>>
>>
>>         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.
>>
>>>         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
>>>         On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>              Token requests are typically out-of-band from the user.
>>>              The attack only happens during an authorization
>>>             redirect flow in the browser.
>>>
>>>             Phil
>>>
>>>             @independentid
>>>             > 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.=

---

From: Ariel Barreiro <[email-masked]>
Date: Thu, 29 Nov 2012 19:01:58 -0300

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-masked]> wrote:

> 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
>
>
> 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
>> MUST send the EXACT SAME redirect URI to the token endpoint. This request
>> is back-channel and protected with the client's credentials.
>>> 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
>>>> 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-masked]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> sending the redirect_uri when requesting the access toekn prevents it are
>>>> welcomed.
>>>> >
>>>> > Thanks,
>>>> > Ariel.=

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Nov 2012 11:07:04 -0300

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-masked]> 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.
> 
> 
> 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
> 
> 
>> 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.
>> 
>> 
>> - 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.
>> 
>> - 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.
>>

---

From: Ariel Barreiro <[email-masked]>
Date: Fri, 30 Nov 2012 11:19:44 -0300

But when we are talking of redirection URI manipulation, are we talking of
compromising the server or some place in the networking route in which the
request_uri can be changed or we are talking of a compromise in the user
browser?

When I think of redirection URI manipulation, I would think that I would
chnge the redirect_uri, so that the authorization code is sent somwhere
else. If that's the case, then wherever the authorization code is received,
it can be used to request a token from that place and that seems perfectly
possible, always talking with unregistered redirect_uris

On Fri, Nov 30, 2012 at 12:07 PM, John Bradley <[email-masked]> wrote:

> The client in the is case is a server.  The front channel involves making
> indirect connection through the user agent.
>
> 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.
>
>>> 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)
>>> 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?
>>>
>>>> is no redirection when requesting an access token, however, the protocol
>>>> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt <[email-masked]>wrote:
>>>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 30 Nov 2012 11:02:53 -0500

Your attack only works if the bad client can make a request to the token 
endpoint with that code, which is only true if it's either a public 
client with no secret or the bad client has stolen the secret from the 
good client. In the latter case, you need to revoke and re-register your 
'good' client at the server.

And the network paths are very different. One uses HTTP 302's through a 
browser, which is outside the control of the client. The other uses 
direct HTTP calls to the auth server, no browser. The latter is a much 
harder target to crack, especially with client credentials on the line.

  -- Justin

On 11/30/2012 09:19 AM, Ariel Barreiro wrote:
> But when we are talking of redirection URI manipulation, are we 
> talking of compromising the server or some place in the networking 
> route in which the request_uri can be changed or we are talking of a 
> compromise in the user browser?
>
> When I think of redirection URI manipulation, I would think that I 
> would chnge the redirect_uri, so that the authorization code is sent 
> somwhere else. If that's the case, then wherever the authorization 
> code is received, it can be used to request a token from that place 
> and that seems perfectly possible, always talking with unregistered 
> redirect_uris
>
>
> On Fri, Nov 30, 2012 at 12:07 PM, John Bradley <[email-masked] 
>     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-masked]
>>     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-masked]
>>         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
>>
>>
>>>         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
>>>         On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             - 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.
>>>
>>>             - 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,
>>>>             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-masked] <mailto:[email-masked]>> 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
>>>>                 That is the long explanation.  The short one is
>>>>                 unregistered redirect URI are bad. Sending the
>>>>                 redirect URI to the token endpoint protects clients
>>>>                 On 2012-11-29, at 3:05 PM, Ariel Barreiro
>>>>                 <[email-masked] <mailto:[email-masked]>> 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
>>>>>                     There is no redirection when requesting an
>>>>>                     access token.  Token requests are typically
>>>>>                     out-of-band from the user.  The attack only
>>>>>                     <http://www.independentid.com/>
>>>>>                     > 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
>>>>>                     > 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.=