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

John Bradley ve7jtb at ve7jtb.com
Tue Dec 4 20:12:05 UTC 2012


OK that is what I thought your position was.


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

> 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