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

John Bradley ve7jtb at ve7jtb.com
Tue Dec 4 18:37:19 UTC 2012


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121204/0491da79/attachment.html>


More information about the Openid-specs-ab mailing list