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>