Re: [OAUTH-WG] Clarification: authorization server matching of redirect URI

[Eran Hammer-Lahav <[e-mail]>]

I am not sure we can specify how callbacks are registered which is where your syntax resides. The whole registration process is out of scope. The server has *something* and needs to match the callback in the request to it.

My proposal is to provide a narrow facility with the client state parameter which makes this simple, but somewhat limited, and allow servers to support a more robust system using any client provided callback parameter.

My problem is that I don't know where to put these rules because we don't have a section dealing with callback registration.

EHL

> -----Original Message-----
> From: Marius Scurtescu [mailto:[e-mail]]
> Sent: Monday, April 19, 2010 10:46 AM
> To: Eran Hammer-Lahav
> Cc: Brian Eaton; Dick Hardt; OAuth WG
> Subject: Re: [OAUTH-WG] Clarification: authorization server matching of
> redirect URI
> 
> On Mon, Apr 19, 2010 at 8:39 AM, Eran Hammer-Lahav
> <[e-mail]> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Brian Eaton [mailto:[e-mail]]
> >> 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 <[e-mail]>
> 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