On Mon, Apr 19, 2010 at 8:39 AM, Eran Hammer-Lahav <[email protected]> wrote:
>
>
>> -----Original Message-----
>> From: Brian Eaton [mailto:[email protected]]
>> Sent: Monday, April 19, 2010 8:37 AM
>> To: Dick Hardt
>> Cc: Eran Hammer-Lahav; OAuth WG
>> Subject: Re: [OAUTH-WG] Clarification: authorization server matching of
>> redirect URI
>>
>> On Sun, Apr 18, 2010 at 10:35 PM, Dick Hardt <[email protected]> wrote:
>> > The spec should describe how the redirect URI is verified to what is
>> registered. I can enumerate the options for discussion adding in the state
>> parameter as an option.
>>
>> Note that there are two spots where the AS does some URI matching.
>>
>> The first is before redirecting the user to the callback URI.  This seems
>> doomed to being service provider specific, unfortunately.
>
> I agree. If someone wants to suggest some security consideration text that 
> would be good.

If this is authz server specific I can see the following problem:
- authz server 1 allows regular expressions in registered callback URLs
- client integrates with authz server 1 and designs its own
implementation based on these callback URLs, uses load balancing on
different hosts and passes state through query parameters
- authz server 2 comes along and it requires strict matching on callbacks
- client wants to integrate with authz server 2 as well, but will have
to rewrite everything because the load balancing and state
infrastructure will not work

In order to support interop I think it would be useful to specify how
callbacks are matched.

Proposal:
- path and query string are strictly matched (the spec has a state parameter)
- host names can contain a wild card (to allow for load balancing)
- port and scheme strictly matched

For example:
- registered callback: https://*.example.com/client?controller=oauth2
- matching callbacks:
  https://example.com/client?controller=oauth2
  https://sv1.example.com/client?controller=oauth2
  https://sv2.n1.example.com/client?controller=oauth2
- not matching:
  https://example.net/client?controller=oauth2
  https://example.com/client?controller=oauth2&user=x
  http://example.com/client?controller=oauth2
  https://example.com:8080/client?controller=oauth2


Marius
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to