On May 21, 2015, at 4:35 AM, John Bradley <ve7...@ve7jtb.com> wrote:
> 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. FWIW I completely agree with John here… regards antonio > > 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 <par...@paroga.com> 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+\\/“] >> >> 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 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
