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

[Raffi Krikorian <[e-mail]>]

twitter is working on a version where we will actually allow the
specification of an explicit array of registered URIs, and we do strict
matching against the elements of that array to see if any match.  we thought
of allowing just subdomain globbing and wildcards, but that seemed
problematic for GAE like situations....

On Wed, May 12, 2010 at 7:31 AM, Luke Shepard <[e-mail]> wrote:

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



-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi