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

Mike Jones Michael.Jones at microsoft.com
Fri Dec 7 19:36:51 UTC 2012


Hi Tim,

To be clear, we're not allowing OpenID Connect clients to leave out the redirect_uri.  The specification still always requires that they be present.

All this does is allow servers to choose not to treat a missing redirect_uri as an error, since some dual-purpose (Connect and other purposes) OAuth endpoints want to allow this in the non-Connect case and it avoids special-case error handling for those servers.

But a Connect client will still be required to include the redirect_uri and will likely fail with most servers (including, I assume, Google's) if they don't include it.

                                                            -- Mike

From: Tim Bray [mailto:tbray at textuality.com]
Sent: Friday, December 07, 2012 7:57 AM
To: Mike Jones
Cc: Brian Campbell; <openid-specs-ab at lists.openid.net>; Naveen Agarwal
Subject: Re: [Openid-specs-ab] Question to Google about redirect_uri parameter in authorization request

For the record, I disagree; It is *extremely* bad practice for an RP to leave out the redirect_uri, increasing the likelihood that your setup will suddenly break one morning because of an unrelated server-side config change.  Altering the spec to allow this misbehavior weakens the interoperability of the standard.

But I guess I'm in the minority here.  -Tim
On Thu, Dec 6, 2012 at 9:44 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
OK - for the purposes of the pending update spec release, I'm going to update the specs to be internally consistent and require clients to send the redirect_uri value.  But I'll also make it clear that servers may choose not to trigger an error when a request is received without a redirect_uri and there is exactly one registered redirect_uri value.  (Credit to John Bradley for this idea.)  That way, conforming clients will always send it but servers that are looser with this behavior for other OAuth requests can continue to be loose in that way with OpenID Connect requests as well.

Thanks all for the good discussion.

                                                            -- Mike

From: Brian Campbell [mailto:bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>]
Sent: Thursday, December 06, 2012 2:19 PM
To: Mike Jones
Cc: Breno de Medeiros; <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>; Naveen Agarwal
Subject: Re: [Openid-specs-ab] Question to Google about redirect_uri parameter in authorization request

Sorry for the slow response. Responses inline.

On Wed, Dec 5, 2012 at 5:50 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
Brian, is the current inconsistency within the Connect specs that you've identified in this sentence in http://openid.net/specs/openid-connect-standard-1_0.html#anchor9: "Ensure that the redirect_uri parameter is present if the redirect_uri parameter was included in the initial Authorization Request and that their values are identical for the Scheme, Host, Path, and Query Parameter segments"?  If the phrase "if the redirect_uri parameter was included in the initial Authorization Request" were deleted, would the Connect specs then be self-consistent, in your view?


As far as it's requiredness on the authorization and token requests, I think that would do it (with a little wordsmithing on that statement anyway).   Looking at all the places I referenced in the ticket, I thought it was a mistake and I guess I was really expecting it would be changed to optional. *Sigh*


Or are you also concerned that this language in http://openid.net/specs/openid-connect-registration-1_0.html#anchor3 would be inconsistent: "redirect_uris - RECOMMENDED for Clients using the code flow with a query parameter encoded response. REQUIRED for Clients requesting implicit flow fragment encoded responses as defined in OAuth 2.0 [OAuth2.0]. A space-delimited list of redirect URIs. One of the URL MUST match the Scheme, Host, and Path segments of the redirect_uri in the authorization request."?  Or do people also believe that registering redirect_uris should always be REQUIRED?

I don't know the reasoning for having it that way so can't really comment on if registering redirect_uris should always be required. It is maybe a little awkward that it's sort of optional there in registration but text like "The Scheme, Host, Path, and Query Parameter segments of this URI MUST match one of the redirect_uris registered for the client_id in the OpenID Connect Dynamic Client Registration 1.0<http://openid.net/specs/openid-connect-standard-1_0.html#OpenID.Registration> [OpenID.Registration] specification." from http://openid.net/specs/openid-connect-standard-1_0.html#rf_prep sort of read as though a client will always have uris registered.  That text also could potentially be interpreted as a hard dependency of standard on dynamic registration but maybe I'm being too nit-picky...


                                Thanks all,
                                -- Mike


_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto: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/20121207/9613f1a5/attachment.html>


More information about the Openid-specs-ab mailing list