+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:donald.cof...@reminetworks.com> donald.cof...@reminetworks.com From: Bill Mills [mailto:wmills_92...@yahoo.com] Sent: Thursday, May 21, 2015 4:13 PM To: Mike Jones; Antonio Sanso; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm +1 On Thursday, May 21, 2015 12:29 PM, Mike Jones <michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com> > wrote: +1 I vehemently concur that that working group should stay completely clear of facilitating this insecure practice. -- Mike -----Original Message----- From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org> ] On Behalf Of Antonio Sanso Sent: Thursday, May 21, 2015 12:41 AM To: John Bradley Cc: oauth@ietf.org <mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] redircet_uri matching algorithm On May 21, 2015, at 4:35 AM, John Bradley <ve7...@ve7jtb.com <mailto: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 >> <mailto: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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
