Subject: [OAUTH-WG] Redirect_uri: provided at the client registration, missing in client redirects

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 06 Jun 2013 14:17:10 +0100

Hi,

I'd like to clarify one thing with respect to the treatment of redirect_uri.

My understanding it is possible for a client application to pre-register 
a redirect_uri but not actually specify it as a query parameter when 
redirecting a user back to the Authorization service - in which case it 
is that pre-registered redirect URI which AS will eventually use to 
redirect the user back to.

Is it still considered to be a safe-enough approach ? If yes - then both 
confidential and public(implicit) clients are OK to use it this approach 
of dropping a redirect_uri during the initial user redirects ?

I'm just asking given that I recall the experts recommending that a 
current redirect_uri parameter must be exactly equal to the 
pre-registered one.

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Jun 2013 15:38:16 +0200

Perhaps it is better to say that from a security point of view a client must only be redirected back to a URI that exactly matches a pre registered redirect URI.

The reasons for that should be clear from Facebooks recent issues with trying to pattern match.

In the instance where there is exactly one registered redirect_uri and no redirect_uri is sent in the request redirecting to the registered URI is fine.

In code flow with a confidential client sending the redirect_uri with the code to the token endpoint helps mitigate the problem of unregistered redirect_uri,  however it leaves open possibilities for the code to be stolen.    It can't be used by an attacker to get the token, but it can be replayed at the legitimate client and relies on the AS correctly comparing the redirect_uri sent ing the authorization request to the redirect_uri sent to the token endpoint.   

That is theoretically secure but is not something a client can verify,  it also places additional state requirements on the AS.

Note Connect always requires the rediret_uri to be sent even if there is only one redirect_uri registered.  That is for interoperability reasons.   If some AS always required it as they are allowed to by the spec and some didn't require it, the client always needs to send it to work with any AS.   

John B.

On 2013-06-06, at 3:17 PM, Sergey Beryozkin <[email-masked]> wrote:

> My understanding it is possible for a client application to pre-register a redirect_uri but not actually specify it as a query parameter when redirecting a user back to the Authorization service - in which case it is that pre-registered redirect URI which AS will eventually use to redirect the user back to.
> 
> Is it still considered to be a safe-enough approach ? If yes - then both confidential and public(implicit) clients are OK to use it this approach of dropping a redirect_uri during the initial user redirects ?
> 
> I'm just asking given that I recall the experts recommending that a current redirect_uri parameter must be exactly equal to the pre-registered one.
> 
> Thanks, Sergey
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 06 Jun 2013 16:54:40 +0100

Hi
> In the instance where there is exactly one registered redirect_uri and no redirect_uri is sent in the request redirecting to the registered URI is fine.

OK, I think I understand, eventually, even if a redirect_uri is not 
available as a parameter then the single (and it has to be a single 
only) pre-registered redirect_uri is used, so the requirement expressed 
in your first sentence above is met.

> That is theoretically secure but is not something a client can verify,  it also places additional state requirements on the AS.

I'm a bit lost here, sorry. Are you talking here about might happen if a 
client has not pre-registered redirect_uri ? If yes then the above is 
clear (I think)

> Note Connect always requires the rediret_uri to be sent even if there is only one redirect_uri registered.  That is for interoperability reasons.   If some AS always required it as they are allowed…
Sure, that makes sense; I'm actually thinking of making it configurable 
for us may be,

Many thanks

Sergey

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Jun 2013 19:02:12 +0200

Inline.

On 2013-06-06, at 5:54 PM, Sergey Beryozkin <[email-masked]> wrote:

> OK, I think I understand, eventually, even if a redirect_uri is not available as a parameter then the single (and it has to be a single only) pre-registered redirect_uri is used, so the requirement expressed in your first sentence above is met.
> 
>> 
> I'm a bit lost here, sorry. Are you talking here about might happen if a client has not pre-registered redirect_uri ? If yes then the above is clear (I think)

Yes.   A client that is not confidential must always register redirect_uri even if it is using code flow.  Otherwise anyone can use the client_id with any redirect_uri.
A confidential client using code flow is allowed not to have a registered redirect_uri as there is a check by sending the redirect_uri to the token endpoint. 
However I personally think that is risky as that is not as likely to be well tested.   So you can if both sides know what they are doing, but I wouldn't recommend it. 
> Sure, that makes sense; I'm actually thinking of making it configurable for us may be,
> 
> Many thanks
> 
> Sergey
>> John B.
>>