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 <uid...@google.com> wrote: >> >> On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu <mscurte...@google.com> >> wrote: >>> >>> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav <e...@hueniverse.com> >>> wrote: >>>> >>>>> -----Original Message----- >>>>> From: Dick Hardt [mailto:dick.ha...@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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
