[Openid-specs-ab] redirect_uri matching clarification

Nat Sakimura sakimura at gmail.com
Mon May 21 21:37:09 UTC 2012


Thanks!

On Tue, May 22, 2012 at 5:21 AM, Anganes, Amanda L <aanganes at mitre.org>wrote:

>  Done. Reported as issue #593. I also linked it to the other related
> redirect_uri issue I reported a few days ago, #591, which is about the
> expected/required behavior for clients who do not have registered
> redirect_uris.****
>
> ** **
>
>
> https://bitbucket.org/openid/connect/issue/591/behavior-for-clients-without-registered
> ****
>
>
> https://bitbucket.org/openid/connect/issue/593/standard-redirect_uri-registration
> ****
>
> ** **
>
> *Amanda Anganes*
>
> Info Sys Engineer, G061****
>
> The MITRE Corporation****
>
> 782-271-3103****
>
> aanganes at mitre.org****
>
> ** **
>
> *From:* Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Monday, May 21, 2012 4:04 PM
> *To:* Anganes, Amanda L
> *Cc:* John Bradley; openid-specs-ab at lists.openid.net
>
> *Subject:* Re: [Openid-specs-ab] redirect_uri matching clarification****
>
>  ** **
>
> 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****
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120522/c1d84179/attachment.html>


More information about the Openid-specs-ab mailing list