Subject: [OAUTH-WG] redircet_uri matching algorithm

From: Patrick Gansterer <[email-masked]>
Date: Sat, 16 May 2015 09:43:23 +0200

"OAuth 2.0 Dynamic Client Registration Protocol” [1] is nearly finished and provides the possibility to register additional “Client Metadata”.

OAuth 2.0 does not define any matching algorithm for the redirect_uris. The latest information on that topic I could find is [1], which is 5 years old. Is there any more recent discussion about it?

I’d suggest to add an OPTIONAL “redirect_uris_matching_method” client metadata. Possible valid values could be:
* “exact”: The “redirect_uri" provided in a redirect-based flow must match exactly one of of the provided strings in the “redirect_uris” array.
* “prefix”: The "redirect_uri" must begin with one of the “redirect_uris”. (e.g. "http://example.com/path/subpath” would be valid with [“http://example.com/path/“, “http://example.com/otherpath/”])
* “regex”: The provided “redirect_uris” are threatened as regular expressions, which the “redirect_uri” will be matched against. (e.g. “http://subdomain.example.com/path5/“ would be valid with [“^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/“]

If not defined the server can choose any supported method, so we do not break existing implementations. On the other side it allows an client to make sure that a server supports a specific matching algorithm required by the client. ATM a client has no possibility to know how a server handles the redirect_uris.

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29
[2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html

--
Patrick Gansterer

---

From: David Waite <[email-masked]>
Date: Wed, 20 May 2015 11:37:33 -0600

> On May 16, 2015, at 1:43 AM, Patrick Gansterer <[email-masked]> wrote:
> 

I don’t know if this is appropriate. For example, If a server is unwilling to support arbitrary regex matching, how would a client which required this be able to register dynamically? Or conversely: if a client did not require regex matching, why would they request this from a server?

If a client requests regex or prefix, it was built to rely on these to work. If some set of servers choose not to support regex or prefix for scope or security reasons, this hurts interoperability from the perspective of dynamic registration. And we already have a workaround - instead make your client rely on the state parameter.

A client doing code or implicit should specify exact return URLs in their registration, and if they need to send the user someplace else after authentication it should be represented to the client by their state param.

> If not defined the server can choose any supported method, so we do not break existing implementations. On the other side it allows an client to make sure that a server supports a specific matching…

The clients should be more than reasonably safe in assuming exact matching works. If the server won’t support exact matching on the redirect_uris supplied it should fail registration.

-DW

---

From: Bill Burke <[email-masked]>
Date: Wed, 20 May 2015 14:00:21 -0400

> A client doing code or implicit should specify exact return URLs in their registration, and if they need to send the user someplace else after authentication it should be represented to the client…

Nice workaround, but you are then making the client more difficult to 
implement and the state param larger and more complex.  prefix matching 
seems like it would be a very common thing that an auth server supports 
and clients would want to have.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 May 2015 14:43:54 -0400

You don’t have to encode the parameters into the state parameter, just have them be referenceable *from* the state parameter, so it’s complexity doesn’t change. What I’ve seen done in several implementations (including our own) is that you generate a random State value, then save that into the session, along with any other stateful information like an ultimate target URI or other parameters. When the request comes back, I look back inside the session object to see if the state value matches what I’d stored earlier. If so, I can get out all the rest of the stuff that we stored before the auth request.

 — Justin

> On May 20, 2015, at 2:00 PM, Bill Burke <[email-masked]> wrote:
> 
> 
> 
> Nice workaround, but you are then making the client more difficult to implement and the state param larger and more complex.  prefix matching seems like it would be a very common thing that an auth server supports and clients would want to have.
> 
> 
> 
> --
> Bill Burke
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Wed, 20 May 2015 23:35:17 -0300

I think the correct answer is that clients should always assume exact redirect_uri matching, and servers should always enforce it.  

Anything else is asking for trouble.

If clients need to maintain some state the correct thing to do is use the state parameter, and not append extra path or query elements to there redirect_uri.

A significant number of security problems in the wild come from servers not enforcing this.

I may be taking an excessively hard line, but partial matching is not something we should be encouraging by making easier.

I did do a draft on a way to safely use state https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt

John B.

> On May 16, 2015, at 4:43 AM, Patrick Gansterer <[email-masked]> wrote:
>

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 21 May 2015 07:41:28 +0000

> Anything else is asking for trouble.

FWIW I completely agree with John here…

regards

antonio

---

From: Mike Jones <[email-masked]>
Date: Thu, 21 May 2015 19:29:27 +0000

+1

I vehemently concur that that working group should stay completely clear of facilitating this insecure practice.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Antonio Sanso
Sent: Thursday, May 21, 2015 12:41 AM
To: John Bradley
Cc: [email-masked]
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm

> Anything else is asking for trouble.

FWIW I completely agree with John here...

regards

antonio

>> "OAuth 2.0 Dynamic Client Registration Protocol" [1] is nearly finished and provides the possibility to register additional "Client Metadata".
>> 
>> I'd suggest to add an OPTIONAL "redirect_uris_matching_method" client metadata. Possible valid values could be:
>> * "exact": The "redirect_uri" provided in a redirect-based flow must match exactly one of of the provided strings in the "redirect_uris" array.
>> * "prefix": The "redirect_uri" must begin with one of the "redirect_uris". (e.g. "http://example.com/path/subpath" would be valid with ["http://example.com/path/", "http://example.com/otherpath/"])
>> * "regex": The provided "redirect_uris" are threatened as regular expressions, which the "redirect_uri" will be matched against. (e.g. "http://subdomain.example.com/path5/" would be valid with ["^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/"]
>>

---

From: Bill Mills <[email-masked]>
Date: Thu, 21 May 2015 20:13:27 +0000 (UTC)

+1 

     On Thursday, May 21, 2015 12:29 PM, Mike Jones <[email-masked]> wrote:

 +1

                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Antonio Sanso
Sent: Thursday, May 21, 2015 12:41 AM
To: John Bradley
Cc: [email-masked]
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm

regards

antonio

---

From: Pedro Igor Silva <[email-masked]>
Date: Thu, 21 May 2015 16:25:49 -0400 (EDT)

----- Original Message -----
> From: "Antonio Sanso" <[email-masked]>
> To: "John Bradley" <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, May 21, 2015 4:41:28 AM
> > I think the correct answer is that clients should always assume exact
> > redirect_uri matching, and servers should always enforce it.
> > 

+1

> 
> 
> > 
> > If clients need to maintain some state the correct thing to do is use the
> > state parameter, and not append extra path or query elements to there
> > redirect_uri.
> > 
> > I may be taking an excessively hard line, but partial matching is not
> > something we should be encouraging by making easier.
> > 
> > I did do a draft on a way to safely use state
> > https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt
> > 
> > John B.
> > 
> > 
> >> "OAuth 2.0 Dynamic Client Registration Protocol” [1] is nearly finished
> >> and provides the possibility to register additional “Client Metadata”.
> >> 
> >> OAuth 2.0 does not define any matching algorithm for the redirect_uris.
> >> The latest information on that topic I could find is [1], which is 5
> >> years old. Is there any more recent discussion about it?
> >> 
> >> I’d suggest to add an OPTIONAL “redirect_uris_matching_method” client
> >> metadata. Possible valid values could be:
> >> * “exact”: The “redirect_uri" provided in a redirect-based flow must match
> >> exactly one of of the provided strings in the “redirect_uris” array.
> >> * “prefix”: The "redirect_uri" must begin with one of the “redirect_uris”.
> >> (e.g. "http://example.com/path/subpath” would be valid with
> >> [“http://example.com/path/“, “http://example.com/otherpath/”])
> >> * “regex”: The provided “redirect_uris” are threatened as regular
> >> expressions, which the “redirect_uri” will be matched against. (e.g.
> >> “http://subdomain.example.com/path5/“ would be valid with
> >> [“^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/“]
> >> 
> >> If not defined the server can choose any supported method, so we do not
> >> break existing implementations. On the other side it allows an client to
> >> make sure that a server supports a specific matching algorithm required
> >> by the client. ATM a client has no possibility to know how a server
> >> handles the redirect_uris.
> >>

---

From: "Donald F. Coffin" <[email-masked]>
Date: Fri, 22 May 2015 00:59:25 -0400

+1

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

2335 Dunwoody Crossing Suite E

Dunwoody, GA 30338-8221

Phone:      (949) 636-8571

Email:        <mailto:[email-masked]> [email-masked]

From: Bill Mills [mailto:[email-masked]] 
Sent: Thursday, May 21, 2015 4:13 PM
To: Mike Jones; Antonio Sanso; John Bradley
Cc: [email-masked]
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm

+1

On Thursday, May 21, 2015 12:29 PM, Mike Jones <[email-masked] <mailto:[email-masked]> > wrote:

+1

                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Antonio Sanso
Sent: Thursday, May 21, 2015 12:41 AM
To: John Bradley
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm

regards

antonio

>> On May 16, 2015, at 4:43 AM, Patrick Gansterer <[email-masked] <mailto:[email-masked]> > wrote:
>> 
>> [email-masked] <mailto:[email-masked]> 

> [email-masked] <mailto:[email-masked]> 

_______________________________________________
OAuth mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/oauth

---

From: Patrick Gansterer <[email-masked]>
Date: Wed, 20 May 2015 22:34:46 +0200

> On 20 May 2015, at 19:37, David Waite <[email-masked]> wrote:
> 
> 

The point is not that a client can register at every server in that case, but to know the (possible) (in)compatibility during registration already. Otherwise a client can only do an authentication request (which might not be possible when specific login-credentials are required) to check if the required redirect_uri_matching_algorithm is supported by the server.

> If a client requests regex or prefix, it was built to rely on these to work. If some set of servers choose not to support regex or prefix for scope or security reasons, this hurts interoperability…

This is possible if there is a predefined list of redirect_uris. Imagine a services where every user gets his/her own subdomain, which all have a redirect_uri like https://user1.example.com/oauth/callback.
With the current concept every subdomain must be listed to get the OAuth stuff working on every subdomain.
Now not every subdomain under example.com should be required to register as a client, but only the TLD services hosted at example.com, example.net and example.org, which all have their own subdomains like https://user5.example.org.

There is for sure the possibility to have a central “OAuth gateway” e.g. at https://oauth.example.com/, witch only need to register one redirect_uri (e.g. https://oauth.example.com/oauth/callback), but would be  an additional dependency for the “user*”-subdomains, since they have to pass the OAuth request then to the “gateway".

> The clients should be more than reasonably safe in assuming exact matching works. If the server won’t support exact matching on the redirect_uris supplied it should fail registration.

Since not all OAuth services do exact matching AFAIK, this would be an option to allow those services to tell their matching algorithm to the client.

—-
Patrick