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

John Bradley ve7jtb at ve7jtb.com
Tue Dec 4 20:06:14 UTC 2012


Would the Authorization server MUST support the redirect_uri, but it is optional for the client to send if it has only one registered be a compromise?


On 2012-12-04, at 4:50 PM, Breno de Medeiros <breno at google.com> wrote:

> On Tue, Dec 4, 2012 at 11:45 AM, Brian Campbell
> <bcampbell at pingidentity.com> wrote:
>> 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 doubt. You can simply supply the redirect_uri to an OAuth2 library.
> They need to support it.
> 
>> 
>> 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
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> --Breno



More information about the Openid-specs-ab mailing list