[Openid-specs-ab] Additional issues with redirect

Breno de Medeiros breno at google.com
Tue May 22 19:29:22 UTC 2012


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120522/72282958/attachment.html>


More information about the Openid-specs-ab mailing list