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

Nat Sakimura issues-reply at bitbucket.org
Thu Mar 21 13:20:34 UTC 2019


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

Nat Sakimura:

Opening another ticket for #175 to close the original issue while #175 can talk about app2app security models, etc. 

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