<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The client is allowed to include query parameters in the registered redirect URI, and the server MUST preserve them.<div><br></div><div>I think Breno is just saying they are included in the string match.</div><div><br></div><div>The redirect_uri from the request must match exactly match one of the registered redirect URI.</div><div><br></div><div>This is consistent with the MUST register a redirect URI in the Connect spec. </div><div><br></div><div>One of the questions was should we relax the requirement to register a redirect_uri?</div><div><br></div><div>It looks like not registering will break at least Google.</div><div><br></div><div>I have yet to hear a good reason for allowing client_id with un-registerd redirect_uri.</div><div><br></div><div>John B.</div><div><br><div><div>On 2012-05-22, at 3:45 PM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">OK. So, the client should register the redirect_uri without any query parameters. <div>And the match is between that and the redirect_uri parameter in the request. </div><div><br></div><div>Thanks. </div><div><br></div><div>
Nat<br><div><br><div class="gmail_quote">On Wed, May 23, 2012 at 4:29 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>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.</p>
<div class="HOEnZb"><div class="h5">

<div class="gmail_quote">On May 22, 2012 11:28 AM, "Nat Sakimura" <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

By saying "we match the redirect_uri exactly", I suppose you mean you test that <div>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. </div>


<div><br></div><div>This means that even if there is only one redirect_uri registered, you always require redirect_uri in the request. Is that so? </div><div><br></div><div>=nat<br><div><div><br></div><br><div class="gmail_quote">


On Wed, May 23, 2012 at 3:05 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Tue, May 22, 2012 at 10:58 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<br>
> Just to clarify.<br>
><br>
> The value of the state parameter changes each time so it cannot be<br>
> registered to be exact match of course.<br>
><br>
> So what is the concrete matching rule?<br>
><br>
> Match the scheme, host, port and query parameter names?<br>
<br>
</div>No, we match the redirect_uri exactly. The only way to pass state in a<br>
request to Google Auth server is to use the state parameter.<br>
<div><div><br>
><br>
> =nat via iPhone<br>
><br>
> On 2012/05/19, at 14:34, Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>> wrote:<br>
><br>
>> Google authz server requires exact match and allows no query<br>
>> parameters. The OAuth2 protocol was designed to support this by adding<br>
>> a pre-defined state parameter.<br>
<br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
--Breno<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>


<br>
</div></div>
</blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
<br>
</div></div>
</blockquote></div><br></div></body></html>