[Openid-specs-ab] Additional issues with redirect

John Bradley ve7jtb at ve7jtb.com
Tue May 22 20:13:24 UTC 2012


The client is allowed to include query parameters in the registered redirect URI, and the server MUST preserve them.

I think Breno is just saying they are included in the string match.

The redirect_uri from the request must match exactly match one of the registered redirect URI.

This is consistent with the MUST register a redirect URI in the Connect spec. 

One of the questions was should we relax the requirement to register a redirect_uri?

It looks like not registering will break at least Google.

I have yet to hear a good reason for allowing client_id with un-registerd redirect_uri.

John B.

On 2012-05-22, at 3:45 PM, Nat Sakimura wrote:

> OK. So, the client should register the redirect_uri without any query parameters. 
> And the match is between that and the redirect_uri parameter in the request. 
> 
> Thanks. 
> 
> Nat
> 
> On Wed, May 23, 2012 at 4:29 AM, Breno de Medeiros <breno at google.com> wrote:
> Yes. The redirect_URI should be present in the request and matched exactly. This makes sense because it works identically if you register multiple URIs, e.g. for testing or deployment. Optimization here by allowing omission only when a single URI is registered would just make the API harder to understand.
> 
> On May 22, 2012 11:28 AM, "Nat Sakimura" <sakimura at gmail.com> wrote:
> By saying "we match the redirect_uri exactly", I suppose you mean you test that 
> one of the registered redirect_uri == value of the redirect_uri parameter in the authorization request? You surely do not mean the match between the registered redirect_uri and redirect_uri being constructed out of the request, which includes the state parameter. 
> 
> This means that even if there is only one redirect_uri registered, you always require redirect_uri in the request. Is that so? 
> 
> =nat
> 
> 
> On Wed, May 23, 2012 at 3:05 AM, Breno de Medeiros <breno at google.com> wrote:
> On Tue, May 22, 2012 at 10:58 AM, Nat Sakimura <sakimura at gmail.com> wrote:
> > Just to clarify.
> >
> > The value of the state parameter changes each time so it cannot be
> > registered to be exact match of course.
> >
> > So what is the concrete matching rule?
> >
> > Match the scheme, host, port and query parameter names?
> 
> No, we match the redirect_uri exactly. The only way to pass state in a
> request to Google Auth server is to use the state parameter.
> 
> >
> > =nat via iPhone
> >
> > On 2012/05/19, at 14:34, Breno de Medeiros <breno at google.com> wrote:
> >
> >> Google authz server requires exact match and allows no query
> >> parameters. The OAuth2 protocol was designed to support this by adding
> >> a pre-defined state parameter.
> 
> 
> 
> --
> --Breno
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120522/fc04095c/attachment.html>


More information about the Openid-specs-ab mailing list