[Openid-specs-ab] Question to Google about redirect_uri parameter in authorization request
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
>> 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 22.214.171.124
>>> 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:
>>> 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
>>> in the distribution list to increase the likelihood that they'd actually
>>> 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
>>> 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
>>> 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
>>>  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
>>> follow up with you guys  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,
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab