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

Breno de Medeiros breno at google.com
Wed Dec 5 17:58:52 UTC 2012

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


More information about the Openid-specs-ab mailing list