[Openid-specs-ab] redirect_uri matching clarification

Anganes, Amanda L aanganes at mitre.org
Mon May 21 14:21:11 UTC 2012

It sounds like the current discussion around redirect_uri's may change the intended meaning of these sections, so I will hold off on suggesting text until that discussion has reached consensus. It sounds like several others have also had differences when interpreting this text.

--Amanda Anganes
From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Thursday, May 17, 2012 3:56 PM
To: Anganes, Amanda L
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] redirect_uri matching clarification

Yes this is not a change from the OAuth 2 requirements.

Sec 4.1.3 of Oauth core states:

REQUIRED, if the "redirect_uri" parameter was included in the

         authorization request as described in Section 4.1.1<http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.1.1>, and their

         values MUST be identical.

 The authorization server

   MUST require public clients and SHOULD require confidential clients

   to register their redirection URIs.  If a redirection URI is provided

   in the request, the authorization server MUST validate it against the

   registered value.

The client is allowed to add additional query parameters to the redirect_uri and the server must pass them through.

If you have better wording please get it to us.

John B.

On 2012-05-17, at 12:01 PM, Anganes, Amanda L wrote:

A few developers here have asked questions about the connection between sections 2.3.1 and 3.1.1 with regard to redirect_uri matching.

2.3.1, Authorization Request: "Scheme, Host, and Path 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 [OpenID.Registration] specification."

3.1.1, Token Request: "The Authorization Server MUST: ... 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."

Pulling out these two sections and placing them side by side, these developers have been confused as to why there are two different requirements. Does "identical" in 3.1.1 mean the two strings must be exactly the same, or does it refer to the scheme, host, and path matching indicated in 2.3.1?

Taking the whole document into consideration, it makes sense why these two requirements are different - query parameters can be passed in the Authorization Request redirect_uri, and that URI should still be able to be matched against the registered URIs. Thus it makes sense to check scheme, host, and path only. The Token Request should use the exact same redirect_uri as used in the Authorization Request, including query parameters, so the two values should be identical strings.

The wording in the spec is correct, but I think it would benefit from some more explanation to call out the difference between the checks done at the two endpoints. I can suggest text if others agree that this is worth clarifying.

Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
aanganes at mitre.org<mailto:aanganes at mitre.org>

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>

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

More information about the Openid-specs-ab mailing list