Re: [OAUTH-WG] Strict equality matching of redirect_uri

FWIW, Facebook does not do strict equality matching on redirect_uri. We accept any redirect_uri that has either:

- its prefix is the registered url
- or it is a special facebook.com/xd_proxy.php url, with an origin parameter that has a prefix on the registered url

I think that the spec should leave the matching up to the server.

On May 11, 2010, at 3:13 PM, Marius Scurtescu wrote:

> On Tue, May 11, 2010 at 3:04 PM, Evan Gilbert <uidude@google.com> wrote:
>> 
>> On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu <mscurtescu@google.com>
>> wrote:
>>> 
>>> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav <eran@hueniverse.com>
>>> wrote:
>>>> 
>>>>> -----Original Message-----
>>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]
>>>>> Sent: Sunday, May 09, 2010 5:52 PM
>>>> 
>>>>>>> 3.5.1.  Client Requests Authorization
>>>>>>> 
>>>>>>> If the client has previously registered a redirection URI with the
>>>>>>>    authorization server, the authorization server MUST verify that
>>>>>>> the
>>>>>>>    redirection URI received matches the registered URI associated
>>>>>>> with
>>>>>>>    the client identifier.
>>>>>>> 
>>>>>>> Does this mean equality? Or just the same base string?
>>>>>> 
>>>>>> Right now it depends on the server.
>>>>> 
>>>>> The spec should clarify that. Suggested wording:
>>>>> 
>>>>> 
>>>>> If the client has previously registered a redirection URI with the
>>>>> authorization
>>>>> server, the authorization server MUST verify that the redirection URI
>>>>> received matches the registered URI associated with the client
>>>>> identifier. The
>>>>> components of the redirection URI that must match the registered URI is
>>>>> authorization server dependant.
>>>> 
>>>> I don't see how that helps... I also don't see why we can't just profile
>>>> this and decide on how the matching should be done. We have the state
>>>> parameter to help too.
>>> 
>>> I also think the spec should specify how the matching should be done.
>>> 
>>> If left up to the authz server then a client that designs its OAuth 2
>>> implementation will have to assume that all authz servers will do
>>> strict equality matching, otherwise it may not be able to interact
>>> with some servers.
>>> 
>>> For example, if the client assumes that it can use load balancing by
>>> varying the first part of the host name, and this may work with the
>>> fist authz server it integrate with, later this client will not be
>>> able to interact with an authz server which does strict matching on
>>> host name. And changing the load balancing architecture once deployed
>>> could be very hard.
>>> 
>>> Since there is a state parameter maybe it is enough to allow wild
>>> cards only in the domain name of the callback URI.
>> 
>> I think this we should leave this matching undefined for now - since you
>> have to preregister with every site, you will have provider-specific logic
>> anyway. This will be much more important when we have a discovery mechanism
>> for callback URLs.
> 
> If we leave undefined then that is the same as enforcing strict
> equality matching. Then let's make that explicit. Are we OK with that?
> 
> A client that eventually wants to interact with several authz servers
> will have to assume the "greatest common divisor", which is strict
> matching.
> 
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth