303 should be used

Issue #418 resolved
Travis Spencer created an issue

Section 2.2.1 point 18 says:

shall not use the HTTP 307 status code when redirecting a request that contains user credentials to avoid forwarding the credentials to a third party accidentally (see section 4.11 of [I-D.ietf-oauth-security-topics])

This should be updated, IMO, to:

shall not use the HTTP 307 status code when redirecting a request that contains user credentials to avoid forwarding the credentials to a third party accidentally (see section 4.11 of [I-D.ietf-oauth-security-topics]); should use the HTTP 303 status code when redirecting the user agent using status codes.

Rationale:

The only HTTP redirect code unambiguously defined to drop the the body of an HTTP POST request is a 303.

https://blog.acolyer.org/2016/11/07/a-comprehensive-formal-security-analysis-of-oauth-2-0/

Comments (9)

  1. Filip Skokan

    307 is the only 3xx status known to relay the body of a request after IIRC modern browsers implement 302 handling as if it was a 303 already.

    I believe the language should reflect the security-topics BCP - if there’s the need it would be updated there first.

  2. Travis Spencer reporter

    So, a financial-grade security specification should only echo some other security BCP and not define anything additional?

    Are browsers the only user agent the spec cares about? Why rely on an ad-hoc standard based on common browser behavior?

  3. Daniel Fett

    After thinking a bit more about this, maybe FAPI is the right place to give more concrete advice here. After all, we’re doing that in many places of the spec.

  4. Takahiko Kawasaki

    If FAPI 2.0 recommends specific HTTP status codes (e.g. 303) instead of prohibiting some (i.e. 307), it also should be taken into consideration that the examples in RFC 6749 are using 302.

  5. Log in to comment