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

Breno de Medeiros breno at google.com
Tue Dec 4 19:50:43 UTC 2012


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