> On 20 May 2015, at 19:37, David Waite <[email protected]> wrote: > > >> On May 16, 2015, at 1:43 AM, Patrick Gansterer <[email protected]> wrote: >> >> "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+\\/“] > > 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?
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 from the perspective of dynamic > registration. And we already have a workaround - instead make your client > rely on the state parameter. 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". > 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 algorithm required by >> the client. ATM a client has no possibility to know how a server handles the >> redirect_uris. > > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
