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

Mike Jones Michael.Jones at microsoft.com
Fri Dec 7 05:44:23 UTC 2012


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]
Sent: Thursday, December 06, 2012 2:19 PM
To: Mike Jones
Cc: Breno de Medeiros; <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

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


More information about the Openid-specs-ab mailing list