----- Original Message ----- > From: "Antonio Sanso" <asa...@adobe.com> > To: "John Bradley" <ve7...@ve7jtb.com> > Cc: oauth@ietf.org > Sent: Thursday, May 21, 2015 4:41:28 AM > Subject: Re: [OAUTH-WG] redircet_uri matching algorithm > > > 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
+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. > > > > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
