Authorization server advertises PKCE with S256
Authored by Stanley Hong · AgentReserve (founder).
Every parsed authorization server metadata document advertises `S256` in `code_challenge_methods_supported`. RFC 9700 (OAuth 2.0 Security BCP) and OAuth 2.1 require PKCE on every authorization-code exchange, with S256 as the only acceptable challenge method (`plain` is forbidden).
When this rule runs
Only applies when the server signals that authentication is required (HTTP 401/403). Excluded from the score on public servers.
Why it matters
Without S256-capable PKCE, an authorization server cannot bind a code exchange to the client that requested it — opening the flow to authorization-code interception. RFC 9700 / OAuth 2.1 mandate it; advertising only `plain` (or omitting the field entirely) signals a server stuck on pre-2.1 behavior.
Pass condition
Every parsed authorization server metadata document advertises `S256` in `code_challenge_methods_supported`.
Fail condition
At least one parsed authorization server metadata document omits `code_challenge_methods_supported` or advertises only `plain`.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"missing": ["https://issuer.example.com"], "advertised": {"https://issuer.example.com": ["plain"]}}
Remediation
Advertise `code_challenge_methods_supported: ["S256"]` (or include `S256` alongside any legacy entries) in your authorization server metadata, and require PKCE for the authorization-code grant.
Methodology
This rule belongs to the Auth discovery posture dimension. When authorization is required, whether the server cooperates with the standards-based discovery chain — RFC 9728 protected resource metadata, RFC 8414 authorization server metadata, validated issuers, and safe grant types.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.