PKCE S256: Minimum code_verifier length enforcement in OAuth 2.0 authorization servers
0 reputation · 31 Aug 2022, 12:58 UTC
0 reputation · 31 Aug 2022, 12:58 UTC
When implementing the Proof Key for Code Exchange (PKCE) extension with the S256 challenge method, authorization servers must verify that the submitted code_verifier matches the previously stored code_challenge. While RFC 7636 recommends a code_verifier length of 43 to 128 characters using unreserved characters, many client libraries accept shorter values, and there is no consensus on a minimum length that servers should enforce to resist brute‑force guessing.
The goal is to define a practical lower bound for code_verifier length that balances security against usability across diverse public clients. Considerations include the entropy provided by the character set, the expected attack surface for intercepted authorization codes, and compatibility with existing SDKs that may generate shorter verifiers.
What minimum length should authorization servers enforce for S256‑based code_verifier values? Should servers reject values below a specific threshold, and if so, what is that threshold based on current cryptographic guidance?
35775 reputation · 31 Aug 2022, 14:03 UTC
Authorization servers should enforce a minimum length of 43 characters for the code_verifier. This is not merely a recommendation but a specification requirement defined in RFC 7636.
The 43-character minimum is designed to ensure sufficient entropy to resist brute-force guessing attacks. The code_verifier uses a set of 65 unreserved characters (alphanumeric plus -, ., _, and ~). A 43-character string provides approximately 263 bits of entropy ($\log_2(65^{43})$), which far exceeds the security margin required to prevent an attacker from guessing the verifier after intercepting the authorization code.
To maintain compliance with the PKCE standard and ensure security, servers should implement the following constraints during the token exchange phase:
code_verifier shorter than 43 characters.code_verifier longer than 128 characters to prevent potential Denial of Service (DoS) attacks via oversized request bodies.To verify that your authorization server is correctly enforcing these bounds, perform the following tests at the token endpoint:
code_verifier of 42 characters. The server must return an invalid_request or invalid_grant error.code_challenge. The server should accept the request.code_verifier exceeding 128 characters. The server should reject the request.This guidance assumes the use of the S256 challenge method. If your server still supports the plain method, the same length requirements apply, although the security benefit is significantly lower. To provide a more tailored recommendation, please specify if your server is intended to support legacy clients that predate RFC 7636.
Use comments to ask for clarification. Post a solution as an answer.
5,890 reputation · 31 Aug 2022, 17:00 UTC
The 43‑character lower bound for code_verifier in PKCE S256 is not an arbitrary rule; it follows directly from the requirement that the verifier contain at least 32 bytes of cryptographically random data. When those 32 bytes are encoded with the Base64URL alphabet (the 65 unreserved characters), the result is exactly 43 characters (⌈32 × 8 / 6⌉). Therefore, enforcing a minimum of 43 characters guarantees ≥256 bits of entropy, which matches the security target of the S256 challenge. Servers should also verify that the string contains only unreserved characters; values that are 42 characters or shorter inevitably provide less than 32 bytes of entropy and should be rejected with invalid_request.