plain
Registry Context
`plain` uses the PKCE code verifier unchanged as the code challenge. RFC 7636 permits it only when a client cannot support `S256` for a technical reason and knows through out-of-band configuration that the authorization server supports `plain`. Current OAuth security guidance favors `S256`.
Technical Summary
For `plain`, `code_challenge = code_verifier`, and the token endpoint compares the submitted verifier directly with the stored challenge. RFC 7636 makes `plain` the default when `code_challenge_method` is omitted. RFC 9700 advises using methods that do not expose the verifier in the authorization request; currently, only `S256` meets that criterion.
When Used
Only when the client cannot support `S256` for a technical reason and has out-of-band knowledge that the authorization server supports `plain`. Although omission of `code_challenge_method` defaults to `plain` under RFC 7636, clients should explicitly use `S256` under current security guidance.
Normative Requirements
Clients
RFC 7636 - Section 4.2
use `S256`.
Condition: If the client is capable of using `S256`.
If the client is capable of using "S256", it MUST use "S256".
RFC 7636 - Section 4.3
send the `code_challenge` parameter in the authorization request.
Condition: When using PKCE.
code_challenge REQUIRED. Code challenge.
RFC 9700 - Section 2.1.1
use a PKCE code challenge method that does not expose the verifier in the authorization request.
Condition: When using PKCE; currently, `S256` is the only such method.
When using PKCE, clients SHOULD use PKCE code challenge methods that do not expose the PKCE verifier in the authorization request.
RFC 7636 - Section 4.3
send the `code_challenge_method` parameter; if omitted, it defaults to `plain`.
Condition: When sending a PKCE authorization request.
code_challenge_method OPTIONAL, defaults to "plain" if not present in the request.
Authorization servers
RFC 9700 - Section 2.1.1
enforce correct use of `code_verifier` at the token endpoint.
Condition: If the client sent a valid `code_challenge` in the authorization request.
If a client sends a valid PKCE code_challenge parameter ... the authorization server MUST enforce the correct usage of code_verifier at the token endpoint.
token endpoint
RFC 7636 - Section 4.6
continue processing the token request normally.
Condition: If the directly compared `code_verifier` and `code_challenge` values are equal.
If the values are equal, the token endpoint MUST continue processing as normal.
RFC 7636 - Section 4.6
return an `invalid_grant` error response.
Condition: If the directly compared `code_verifier` and `code_challenge` values are not equal.
If the values are not equal, an error response indicating "invalid_grant" ... MUST be returned.
Validation Guidance
Flag `plain` unless it is established that the client cannot support `S256` for a technical reason and has out-of-band knowledge that the authorization server supports `plain`.
When `code_challenge_method=plain`, compare `code_verifier` and `code_challenge` directly without hashing or another transformation.
Return `invalid_grant` when the submitted verifier does not equal the stored challenge.
Warn when `code_challenge_method` is omitted because RFC 7636 defaults it to `plain`, which exposes the verifier in the authorization request.
Prefer an explicit `code_challenge_method=S256`.
Security Notes
RFC 9700 - Section 2.1.1
`plain` exposes the PKCE verifier in the authorization request. RFC 9700 warns that an attacker able to read that request can break PKCE's protection; currently, `S256` is the only registered method identified there as not exposing the verifier.
Reference
Section 4.2 of RFC7636
Details
- Entry Id
plain- Code Challenge Method Parameter Name
plain- Change Controller
IESG- Reference
Section 4.2 of RFC7636