Drop redirect_uri as a required parameter in the token request?

[aaronpk]

I believe the theory behind including the redirect_uri in the token request was to avoid some mixup attacks. However PKCE would solve that attack in a much more elegant way, which suggests that we don't need the redirect_uri in this request at all anymore. Would it make sense to drop this parameter from the request entirely? Or at least switch it to optional? (If there's some attack I'm not thinking of that this prevents please let me know!)

[tlodderstedt]

+1

That's the conclusion of https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-3.5

"This document therefore recommends to instead bind every authorization code to a certain client instance on a certain device (or in a certain user agent) in the context of a certain transaction."

[dickhardt]

What about non-PKCE scenarios? Fine dropping it if it is now just security theater -- but not sure that is the always the case.

[aaronpk]

It's not clear from the meeting minutes whether the decision was to drop this parameter from the request entirely or just make it more clear that it's optional in the token request. I think we agreed to drop it entirely as long as that is clearly documented in the "changes from OAuth 2.0" section

[aaronpk]

We discussed this during the side meeting at IETF 114, and the resolution was to leave this as is. Currently the spec says the redirect_uri in the authorize request is only required if there are multiple registered, and it's only required in the token request if it was included in the authorize request. While some existing ASs may not be following these rules exactly, any change to the rules in either direction would cause more interop problems than it solves.

[tlodderstedt]

The redirect URI does not serve any meaningful purpose in the token request. I therefore think it should be removed.

If we care about backward compatibility (which we don't at the authorization endpoint), we could make acceptance mandatory for ASs but sending the redirect URI optional for clients.

[aaronpk]

As discussed at IETF 115, we agreed to:

• Remove the redirect_uri parameter from the token endpoint request
• For backwards compatibility, note that ASs that support 2.0 clients will need to allow the redirect_uri parameter, and if provided, should also enforce it
• Document in the "Differences from OAuth 2.0" section that an OAuth 2.1 client that doesn't send the redirect_uri will not work with an OAuth 2.0 server that expects it

I also just realized, the breaking change isn't even as breaking as it was made out to be during the meeting. OAuth 2.0 only requires the redirect_uri in the token request if it was provided in the authorization request. So technically there are OAuth 2.0 ASs that currently don't require the redirect_uri parameter in all cases.

[panva]

It is not clear which (if any) 2.1 behaviour makes this change possible. AS implementers that want to support both 2.0, or 2.0 + BCP and 2.1 behaviours need to know exactly when its okay to drop the requirement to provide the parameter.

OAuth 2.0 only requires the redirect_uri in the token request if it was provided in the authorization request.

I believe there to be only a handful of servers that support this optional behaviour.

[aaronpk]

ASs should be following the current RFC6749 guidance and only requiring the redirect_uri parameter in the authorization request if more than one is registered, then following that, only require the redirect_uri parameter at the token endpoint if one was provided in the authorization request given the authorization code being used. If an AS has its own policy of requiring the redirect_uri all the time, then that is outside the scope of RFC6749, it's a decision the AS made that client developers would have to follow for that particular AS.

Since this parameter is after issuing the authorization code to the client, the AS already knows which client this is, so it could have a mechanism for clients to opt in to all the 2.1 requirements, including this.

Since there are many ASs that require the parameter all the time, many OAuth client library always include it. That behavior would still be allowed with the new text.

One comment I made at the end of this discussion at the meeting was that after we finish documenting the changes from OAuth 2.0 (#97), we should revisit this item. If it turns out this is the only change that breaks OAuth 2.1 clients from working with OAuth 2.0 servers, then we could roll this back. I suspect that won't be the case though.

[tlodderstedt]

@panva the fact that PKCE is mandatory in 2.1 makes this change possible, as it effectively detects injection attempts (which was the main reason for including the effective redirect URI in the token request in 2.0)

[panva]

Cheers @tlodderstedt. @aaronpk, I believe what Torsten noted above should make it to #97.