+1
On Thursday, May 21, 2015 12:29 PM, Mike Jones
<[email protected]> wrote:
+1
I vehemently concur that that working group should stay completely clear of
facilitating this insecure practice.
-- Mike
-----Original Message-----
From: OAuth [mailto:[email protected]] On Behalf Of Antonio Sanso
Sent: Thursday, May 21, 2015 12:41 AM
To: John Bradley
Cc: [email protected]
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm
On May 21, 2015, at 4:35 AM, John Bradley <[email protected]> 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 <[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+\\/"]
>>
>> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
