[Openid-specs-ab] Question to Google about redirect_uri parameter in authorization request

Brian Campbell bcampbell at pingidentity.com
Wed Dec 5 18:26:31 UTC 2012


I think that at some level our views are informed by the current
behavior of our respective authorization server implementations. Yours
always requires redirect_uri and mine will allow it to be omitted in
the case where the client has registered a single redirect_uri. Both
are compliant (that probably favors your argument) and we both have
reasons for the current behavior. I can't change mine now as it would
impact interoperability of existing deployments.

Honestly I'm good with whatever direction the WG goes with on it. The
original reason I submitted the ticket was that the Connect specs were
inconsistent within themselves on the parameter treatment. In order to
fix that it seemed less error prone to just remove all the related
text from Connect and defer to OAuth on it. I didn't expect any
controversy on it but I've been in enough WGs that I should know
better :) I don't think I agree with your conclusions but I follow the
line of reasoning and am fine if the WG goes with that approach.


On Wed, Dec 5, 2012 at 10:58 AM, Breno de Medeiros <breno at google.com> wrote:
> For instance, today the OAuth2 spec is mute on the case where the RP
> has registered a single redirect_uri with the provider. It does not
> prohibit the provider from throwing an error. We believe Google's
> implementation that throws an error if redirect_uri is not present is
> compliant, though it probably will not interoperate will all
> OAuth2-compliant client configurations. It's probably less
> interoperable than other implementations right there. As we don't
> expect OAuth2 to provide strong interoperability guarantees, and we do
> understand very well the great value that OAuth2 brings to our
> ecosystem, we're happy to continue the current behavior.
>
> If the OIDC connect is mute on the redirect_uri issue and delegate all
> redirect_uri processing compliance to OAuth2 spec, I expect that we
> will keep our current behavior and claim full interoperability on this
> particular aspect. Perhaps that suits the OIDC WG's views just fine.
>
> On Wed, Dec 5, 2012 at 9:47 AM, Breno de Medeiros <breno at google.com> wrote:
>> On Wed, Dec 5, 2012 at 9:40 AM, Brian Campbell
>> <bcampbell at pingidentity.com> wrote:
>>> That's a fair example but the point I've been trying to make is that
>>> that variability already exists in OAuth and, even if we all agree
>>> that it's a bad thing, it can't just be undone in Connect.
>>
>> Why not? There's a long standing tradition where protocols that build
>> on other protocols define tighter compliance profiles. If OIDC
>> _contradicted_ OAuth2, that'd be certainly an issue, but it's not the
>> case. An OIDC-compliant OAuth2 solution would also be OAuth2
>> compliant. Or it could choose to implement two behaviors based on the
>> presence of the 'openid' scope.
>>
>>> An AS that
>>> currently allows for that variability in OAuth (and such things do
>>> exist) will need to now have further conditions on the variability
>>> based on what protocol is being used in the request (identified by the
>>> presence of the openid scope value I guess?). From the perspective of
>>> someone who has to develop, support and maintain such an AS, that
>>> seemed like not a particularly ideal situation. So I was looking to
>>> get consistent treatment between the spec suites because it would make
>>> my life easier. I also feel that any problems with potential ambiguity
>>> around the parameter would be exacerbated rather than helped by having
>>> Connect treat it differently.
>>
>> And so we remain in disagreement.
>>
>>>
>>> On Wed, Dec 5, 2012 at 10:05 AM, Tim Bray <tbray at textuality.com> wrote:
>>>> On Wed, Dec 5, 2012 at 8:07 AM, Brian Campbell <bcampbell at pingidentity.com>
>>>> wrote:
>>>>>
>>>>> > You don't have interoperability with OAuth2.
>>>>>
>>>>> Please spare that hyperbole for personal blog posts attacking the
>>>>> evils of big corporate America. It's a crutch argument that's largely
>>>>> untrue and any interoperability problems that OAuth 2 might suffer are
>>>>> certainly not due to the conditional optionality of one request
>>>>> parameter.
>>>>
>>>>
>>>> Calm down.  It is absolutely the case that OAuth2, for all its virtues, does
>>>> not give you interoperability in the sense that “If I protect my resources
>>>> in an OAuth2 comformant way and you protect yours in an OAuth2 conformant
>>>> way, then conformant client software will automatically work with both.”
>>>> That kind of thing is true with HTTP, and with SMTP, and with lots of other
>>>> ****P’s, but not remotely OAuth 2.0.  I’m not even sure this is a problem,
>>>> OAuth2 gives you a framework that you can build real interoperable protocols
>>>> on, which I think OIDC is trying to be.
>>>>
>>>> So, for OIDC, it is very valuable to remove as many as possible variations
>>>> and at-the-discretion-of-the-server clauses, if there is to be a reasonable
>>>> hope of good interoperability.  Every “if” statement you force on
>>>> implementers is a barrier to that.
>>>>
>>>> For example: Send a redirect_uri with your auth request, then you don’t have
>>>> to worry about breaking things when someone puts another redirect in the app
>>>> registration to do some testing on their laptop. Seems like a no-brainer to
>>>> me.
>>>>
>>>> -T
>>>>
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>
>>
>>
>> --
>> --Breno
>
>
>
> --
> --Breno


More information about the Openid-specs-ab mailing list