Inconsistent treatment of redirect_uri parameter

[Brian Campbell]

OAuth 2.0 (RFC 6749!) defines redirect_uri as an optional parameter in an authorization request in cases where the client has a single unambiguous redirect_uri registered with the AS and then only requires it in an access token request when it had previously been included in the corresponding authorization request [1].

The treatment of redirect_uri in the Connect specs isn't always consistent with OAuth, however, and is also somewhat internally inconsistent though different Connect specs.

Standard has redirect_uri required in the authorization request [2] while allowing it to be omitted in the token request [3]. Messages has it required [4] as does Basic [5] and Implicit [6]. The wording in Registration seem to suggest that it's required [7].

I'd argue that Connect should be consistent with the OAuth for redirect_uri treatment. It should be optional/required under the same conditions as in OAuth (unless there is some compelling reason to differ). It might make sense to just defer directly to OAuth for the core parameter definitions and only define in Connect additional parameters or those that do need to be treated differently.

[1] http://tools.ietf.org/html/rfc6749#section-3.1.2.3

http://tools.ietf.org/html/rfc6749#section-4.1.1

http://tools.ietf.org/html/rfc6749#section-4.1.3

http://tools.ietf.org/html/rfc6749#section-4.2.1

[2] http://openid.net/specs/openid-connect-standard-1_0.html#rf_prep

[3] http://openid.net/specs/openid-connect-standard-1_0.html#anchor9

[4] http://openid.net/specs/openid-connect-messages-1_0.html#auth_req

[5] http://openid.net/specs/openid-connect-basic-1_0.html#rf_prep

[6] http://openid.net/specs/openid-connect-implicit-1_0.html#rf_prep

[7] http://openid.net/specs/openid-connect-registration-1_0.html#anchor3

[OpenID Foundation]

(Reply via [e-mail]):

I am writing this on a flight from FRA to ROM without being able to look at the specs referenced so I may be off, but as far as I remember, WG decision was to require them. It was a decision made a while ago to bolster the security property of OAuth. I think it was Google who argued strongly for it. Subsequently, we went to modify the specs. Apparently we failed to do it properly in Standard, so we need to fix it.

=nat via iPhone

Oct 19, 2012 23:13?$B!"?(BBrian Campbell [e-mail] ?$B$N%a%C%;!<%8?(B:

[Vladimir Dzhuvinov]

Brian's suggestion seems to make sense.

In our current implementation of OpenID Connect upon receiving an Authz Request the IdP makes a DB request to fetch the client details by client_id. With that it also gets the registered redirect URI. So, from a request processing perspective, passing the redirect_uri is redundant unless multiple URIs have been registered and the client has to select one.

The only security related argument I'm able to see for making redirect_uri mandatory is to guard against buggy IdPs that somehow store or retrieve an incorrect redirect URI value for the client. If the IdP however has to verify the redirect_uri parameter against its registration record, such slippage could be caught more easily I suppose.

If there are other security arguments for making the redirect_uri parameter mandatory, I would be interested to hear them.

[Michael Jones]

The behavior of always requiring a registered redirect_uri is simpler and more consistent than the OAuth behavior, which has more special cases. On the working group call, we decided that unless a compelling case is made that we're disabling important functionality by doing things the current way, that we should leave things as-is. Brian, can you make a case that it's important in some case NOT to have a registered redirect_uri?

[Brian Campbell]

I think requiring a registered redirect_uri is fine. What I'm saying here is that core OAuth treats the redirect_uri parameter as optional on an authorization request when there is only one registered redirect_uri for the client and that I believe the Connect specs should be consistent with that.

[Michael Jones]

It is this way because currently Google always requires the redirect_uri value. Brian, could you start a thread on the list with with Breno and Naveen asking if they'd be OK with relaxing the spec to allow the redirect_uri parameter not to be present when only one redirect_uri is registered?

Similarly, for the same reasons, we currently require sending the redirect_uri to the token endpoint even in cases where OAuth doesn't require it because we already have a single registered redirect_uri. We should probably discuss this at the same time.

[Michael Jones]

Fixed #669 - Inconsistent treatment of redirect_uri parameter

→ <<cset ac84d0a78b35>>