Security
An OAuth 2.0 and OpenID Connect security checklist
A condensed, sourced checklist from RFC 9700 and OpenID Connect Core for reviewing an OAuth or OIDC integration, client or server side.
The short answer
The current reference for OAuth security is RFC 9700, the OAuth 2.0 Security Best Current Practice. Its core requirements: use the authorization code flow with PKCE, never implicit or password grants; match redirect URIs exactly; sender-constrain or rotate refresh tokens; restrict token audience and privilege; and validate every token you receive. This checklist condenses those points for a review.
Sources last reviewed .
Client side
- Authorization code flow with PKCE (S256); no implicit grant; no resource owner password grant.
- state or nonce checked on every callback.
- Exact redirect URIs registered; no open redirects on the redirect endpoint.
- ID token validated: signature, iss, aud, exp, nonce.
- Tokens never in URLs or logs; refresh tokens stored server-side or in platform secure storage.
- Least-privilege scopes and resource indicators.
Server side
- PKCE required per client; plain method rejected.
- Authorization codes single-use and short-lived.
- Refresh tokens rotated with reuse detection, or sender-constrained.
- Client authentication with keys (private_key_jwt or mTLS) for high-value clients.
- Issuer identification in authorization responses, or distinct redirect URIs per issuer, to prevent mix-up attacks (RFC 9700 section 4.4).
- Pushed authorization requests (RFC 9126) where request integrity matters.
Keep reading
Protocols and how-tos
PKCE explained: how it protects the authorization code
Protocols and how-tos
How to implement the OpenID Connect authorization code flow
Security
Token theft and replay: how bearer tokens are stolen and how to limit the damage
Glossary: OAuth 2.0 · OpenID Connect (OIDC) · PKCE · DPoP
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.