Standard: redirect_uri registration & matching

[Former user]

There is some confusion around the requirements for redirect_uri registration and matching from sections 2.3.1 and 3.1.1 in OpenID Connect Standard.

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.”

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?

See working group threads at http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120521/001939.html and http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120514/001922.html.

Also see issue #591.

[Michael Jones]

The working group conclusion is that exact matching including the query parameters must be used.

[John Bradley]

OAuth allows unregistered redirect URI for the code flow only.

It sends the redirect URI as part of the token request for the Authorization server to compare.

I would be OK with that for "code".

The real world problem with that is that Google has taken a belt and braces approach, and requires both registration and the redirect uri in the token request.

If we have something different in the spec it will not work with google unless they agree to change.

The reality is that every page at a RP is not going to be a landing page. Having one landing page and passing the link state uri in state is not the end of the world.

I would however prefer to allow unregistered redirects for code as allowed but not mandated by OAuth.

John

[John Bradley]

Re #593 updated matching of redirect URI to include query parameters to match Google

→ bdc92b3bc5fd

[John Bradley]

Issue #591 was marked as a duplicate of this issue.

[Michael Jones]

John closed this issue with his last checkins