Clarify allowed use of `state` and required CSRF protection in FAPI 2.0 SP

While taking a closer look at OAuth 2.1 and the implications of using PKCE instead of state for CSRF protection, we (Pedram and Tim) briefly revisited FAPI 2.0 SP.

In particular, Section 10.12 of RFC 6749 mandates that Clients implement CSRF protection for their redirect endpoint (without mandating a particular mechanism to do so). Several more recent specifications (OAuth 2.1, the OAuth Security BCP) suggest the use of PKCE to accomplish CSRF protection, e.g., the Security BCP states that "Clients [...] MAY rely on the CSRF protection provided by PKCE."
However, this requires that the Client somehow binds the PKCE verifier to a particular user agent, and both OAuth 2.1 and the BCP require such binding.
Without this binding, an implementation may put the PKCE verifier into the state parameter (without any relation to a particular user agent), rendering PKCE useless (even if the state parameter is encrypted and signed, see the attached figure).

As for FAPI 2.0 SP, the normative text discusses neither the state parameter nor CSRF protection, but the table "Main Differences to FAPI 1.0" mentions using PKCE as CSRF protection. However, FAPI 2.0 SP does not explicitly require Clients to bind PKCE verifiers to user agents. Readers may misinterpret that table entry as "PKCE is sufficient for CSRF protection", especially since the BCP mentions this as well, but miss the extra requirement of binding the verifier to the user agent as laid out in the BCP.
Hence, we think it makes sense to clarify this in FAPI 2.0 SP.

A note on the formal security analysis and why this issue did not surface there: Since the normative text requires PKCE but does not suggest (and neither does the PKCE RFC) to rely on PKCE for CSRF protection, the analysis model follows RFC 6749 in that the Client's redirect endpoint employs CSRF protection (by - among other things - binding the PKCE verifier to a (secure) user agent session).

‌

Comments (7)