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

Breno de Medeiros breno at google.com
Tue Dec 4 20:08:03 UTC 2012


On Tue, Dec 4, 2012 at 12:06 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> 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?

This is already the case for the Authorization Server. The flexibility
with the client will only cause surprises.

>
>
> 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
>



-- 
--Breno


More information about the Openid-specs-ab mailing list