[Openid-specs-fapi] Issue #175: Clarify attacker model (PKCE method and CSRF protection) (openid/fapi)

Daniel Fett issues-reply at bitbucket.org
Mon Sep 17 09:04:10 UTC 2018


New issue 175: Clarify attacker model (PKCE method and CSRF protection)
https://bitbucket.org/openid/fapi/issues/175/clarify-attacker-model-pkce-method-and

Daniel Fett:

The Read-Only profile of the FAPI requires the use of PKCE (Section 5.2.2, Number 7 of Draft-05). While there are two code challenge methods defined in PKCE (either "plain" or "S256"), the FAPI requires the use of "S256", where the underlying assumption is that the authorization request leaks due to "leaking http log information in the OS" (Pre-Condition 4b of RFC 7636).

**Does the FAPI aim to protect against authorization request leaks?**

If **yes**, then how is the leakage of the state value contained in the authorization request mitigated? As described in OAuth (Section 4.1.1 of RFC 6749), the state value should be used for preventing CSRF attacks.

In Section 5.2.3 of the Read-Only profile of the FAPI, the client is required to "implement an effective CSRF protection". How can this be achieved in a way suitable for all configurations, e.g., also for native app clients, when assuming that the authorization request leaks?

If **no** (i.e., PKCE is only used for code-injection protection), then why is the more complex S256 chosen, where the plain method would work fine?




More information about the Openid-specs-fapi mailing list