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

Brian Campbell bcampbell at pingidentity.com
Tue Dec 4 19:45:25 UTC 2012


The argument that variability harms interoperability is a fair one (though
not always so straightforward) but would have been better made around this
parameter during the development of OAuth because the variability is
already written into RFC 6749. I think it'd be hard to argue that the
Connect spec suite has any precedent of eschewing variability in favor of
interoperability or simplicity so deferring to that here seems a bit
arbitrary.

Putting this requirement into Connect introduces a different kind of
variation all together. Whether or not the parameter is required (under the
particular circumstance of a single registered redirect uri) would depend
on if you are doing plain old OAuth or if you are doing Connect. That seems
even worse IMHO and will certainly be a pain to support.

I raised the issue originally because the difference between the two
related specs caused some actual confusion amongst some folks I was working
with (including people who are involved in working on/with both of these
specs). It seemed really awkward, to me anyway, to have Connect treat a
parameter that's defined in OAuth differently than OAuth treats it. I'd
prefer to see consistent treatment between the two specs but it's not worth
fighting about so I'll drop it, if others really want it this way. At the
very least, however, the various Connect specs need to be consistent with
themselves.



On Tue, Dec 4, 2012 at 11:37 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> I think we are agreed that the authorization server needs to be able to
> accept redirect URI.
>
> The question is if a client has one and only one redirect URI registered
> should not sending the redirect URI cause:
> 1: an error
> 2: a redirect to the registered URI.
>
> RFC 6749 states in Sec 3.1.2.3
>
> If multiple redirection URIs have been registered, if only part of
> the redirection URI has been registered, or if no redirection URI has
> been registered, the client MUST include a redirection URI with the
> authorization request using the "redirect_uri" request parameter.
>
>
> As redirect_uri  is an optional parameter the spec allows not sending it
> in the case where one redirect URI is registered.
>
> I think the argument Breno is making is that the spec allows the
> Authorization server to always require a redirect_uri so it is best to
> train people to always send it all the time.
>
> The only downside to that is in bandwidth constrained environments it adds
> extra characters to the request, that don't serve any real security purpose.
>
> In the interests of maximum interoperability the connect spec takes the
> position that redirect_uri is always sent, to avoid breaking at some IdP
> that require it for there OAuth implementations.
>
> The other place this effects is the request to the token endpoint.  in sec
> 4.1.3 the redirect_uri parameter is sent in the original request to the
> authorization server it must also be sent to the token endpoint.
>
> So if space bandwidth is a issue we are sending it twice.  (I do actually
> have a large deployer who is concerned about this)
>
> Currently Connect requires the redirect_uri to always be sent be sent in
> the request to the token endpoint as the request_uri is always sent to the
> authorization endpoint.
>
> The RFC allows this one condition of a single registered redirect_uri to
> be used to reduce request size.  The question is if consistency is more
> important than size to us?
>
> That is my analyses of the current situation.
>
> John B.
>
>
> On 2012-12-04, at 2:52 PM, Breno de Medeiros <breno at google.com> wrote:
>
> -1
>
> In my experience, every variation is harmful for interop, and is
> expensive for developers to learn about.
>
> All OAuth2-compliant providers need to accept a redirect_uri is specified.
>
> On Tue, Dec 4, 2012 at 9:30 AM, Brian Campbell
> <bcampbell at pingidentity.com> wrote:
>
> Sorry for the re-post - I wanted to send this with Breno and Naveen
> directly
> in the distribution list to increase the likelihood that they'd actually
> see
> it (but forgot the first time).
>
>
> ---------- Forwarded message ----------
> From: Brian Campbell <bcampbell at pingidentity.com>
> Date: Tue, Dec 4, 2012 at 10:17 AM
> Subject: Question to Google about redirect_uri parameter in authorization
> request
> To: "<openid-specs-ab at lists.openid.net>" <openid-specs-ab at lists.openid.net
> >
>
>
> Hey Breno and/or Naveen,
>
> Would you guys be OK with relaxing the Connect specs to allow the
> redirect_uri parameter to be omitted from an authorization request when
> only
> one redirect_uri is registered for the given client?
>
> The reason I'm asking it that the Connect specs are more strict about the
> redirect_uri parameter than the base OAuth spec and I'd submitted at ticket
> [1] requesting that Connect align with the RFC that it extends from. The
> Connect editors have said the added constraint on the parameter was placed
> there because it's how the the Google implementation worked and asked me to
> follow up with you guys [2] to understand why you were requiring it and if
> it is OK to relax that requirement in the Connect specs.
>
> Can you shed some light on that decision and/or just give the to make the
> change at the spec level?
>
> Thanks in advance,
> Brian
>
>
> [1]
>
> https://bitbucket.org/openid/connect/issue/669/inconsistent-treatment-of-redirect_uri
>
> [2]
>
> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121203/002612.html
>
>
>
>
> --
> --Breno
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121204/ca2735c7/attachment-0001.html>


More information about the Openid-specs-ab mailing list