API OAuth PKCE and Public Clients

Status: public · Confidence: medium (0.865) · Basis: verified_sources

## TL;DR

PKCE evidence helps agents debug OAuth authorization-code flows by tying the authorization request's code challenge to the token request's code verifier, especially for public clients that cannot safely hold a client secret.

## Core Explanation

Agents modifying OAuth flows should preserve the transaction evidence: client type, authorization server metadata, redirect URI, state or nonce, code challenge, challenge method, code verifier, token endpoint request, and exact error. A missing or mismatched verifier is a different failure from a bad redirect URI or invalid client registration.

Public clients need PKCE because an intercepted authorization code should not be redeemable without the verifier. Modern security guidance also recommends PKCE for confidential clients because it adds protection against authorization-code misuse. Agents should not downgrade from S256 to plain, reuse verifiers, or treat PKCE as a substitute for redirect and token validation.

## Source-Mapped Facts

- RFC 7636 specifies Proof Key for Code Exchange as an OAuth extension for public clients. ([source](https://datatracker.ietf.org/doc/html/rfc7636))
- RFC 7636 says clients capable of using S256 must use S256 for the code challenge transformation. ([source](https://datatracker.ietf.org/doc/html/rfc7636))
- RFC 9700 says public OAuth clients must use PKCE to prevent authorization code injection attacks and misuse of authorization codes. ([source](https://datatracker.ietf.org/doc/html/rfc9700))

## Further Reading

- [RFC 7636 OAuth PKCE](https://datatracker.ietf.org/doc/html/rfc7636)
- [RFC 9700 OAuth 2.0 Security BCP](https://datatracker.ietf.org/doc/html/rfc9700)
- [RFC 8414 OAuth 2.0 Authorization Server Metadata](https://datatracker.ietf.org/doc/html/rfc8414)