[OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Benjamin Häublein <[e-mail]>]

Hello everyone,
I think RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients", section 4.6. "Server Verifies code_verifier before Returning the Tokens" leaves a tiny gap regarding the handling of verification when no code challenge was present in the authorization request:
   Upon receipt of the request at the token endpoint, the server
   verifies it by calculating the code challenge from the received
   "code_verifier" and comparing it with the previously associated
   "code_challenge", after first transforming it according to the
   "code_challenge_method" method specified by the client.
It is unspecified how the server should behave when "code_verifier" is present, but "code_challenge" and "code_challenge_method" were not set in the initial authorization request.
The following example worked for three well-known authorization servers where the client was configured in a way that PKCE could be used, but was not enforced:
Authorization Request:
https://XXXX/auth?client_id=YYYY&response_type=code&scope=openid+profile&redirect_uri=https://localhost
Subsequent Token Request:
POST /token HTTP/1.1
Host: XXXX
Content-Length: 256

code=ZZZZ&grant_type=authorization_code&client_id=YYYY&redirect_uri=https%3A%2F%2Flocalhost&code_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
As a result, an access token was issued although the code_verifier provided in the token request did not match the code_challenge and code_challenge_method in the authorization request.

Many applications consider the usage of PKCE as enough protection from Login-CSRF and do not use state or nonce (for example this blog entry by Daniel Fett https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ suggests, that neither state nor nonce are necessary when PKCE is used). However, when the authorization server is not configured to require a specific code_challenge_method from the client and the authorization behaves as described in the example, PKCE does not protect from Login-CSRF.
I think the following mitigations are possible:

  *   Enforce usage of PKCE in the client configuration in the Authorization Server
  *   Implementation of the authorization server returns an error in the Access Token Response when code_verifier is present in the token request, but no code_challenge and code_challenge_method is present in the authorization request.
  *   Additionally, when the behavior of an AS is correct (verification of code_verifier fails when no code_challenge was present), a client that relies on PKCE for CSRF protection must always include a code_verifier parameter in the token request (even if no code_verifier is present on the client side).

Best regards,

Benjamin Häublein
Senior Consultant

cirosec GmbH
Ferdinand-Braun-Strasse 4
74074 Heilbronn
Germany
Phone: [phone]
Fax: [phone]
Mobile: [phone]
www.cirosec.de

HRB Stuttgart 107883
CEO Stefan Strobel, CFO Peter Lips