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

John Bradley ve7jtb at ve7jtb.com
Fri Dec 7 12:51:00 UTC 2012


I think that is the best compromise.   A client that doesn't send a redirect_uri is not compliant and may not work with most Connect servers.  A server is not forced to throw a error for something that is allowed in OAuth 2 but can if that is it's policy.

That allows for more OAuth Authorization servers to comply without having more special logic to throw errors based on the receipt of a particular scope.

John B.

On 2012-12-07, at 2:44 AM, Mike Jones <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] 
> 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> 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 theredirect_uris registered for the client_id in the OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specification." fromhttp://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
> 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/cb247762/attachment.html>


More information about the Openid-specs-ab mailing list