[Openid-specs-ab] redirect_uri matching clarification

Nat Sakimura sakimura at gmail.com
Mon May 21 20:03:59 UTC 2012


Actually, it would be great if you could ticket this issue at the bitbucket
so that we can track.

Cheers,

=nat via iPhone

On 2012/05/21, at 23:21, "Anganes, Amanda L" <aanganes at mitre.org> wrote:

  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.

 and

10.6

 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

782-271-3103

aanganes at mitre.org



_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab



_______________________________________________
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/20120522/8fb6bf9b/attachment.html>


More information about the Openid-specs-ab mailing list