OAuth/OIDC pre-launch checklist

60+ product security checks for teams shipping SSO, OAuth, or OpenID Connect.

From the checklist

"OAuth is rarely broken by the spec. It is broken by small product and architecture decisions."

What's inside

An opinionated hardening checklist, not a compliance document.

Authorization flows & PKCE

Redirect URI allowlists

State, nonce & mix-up defense

ID & access token validation

API audience, scope & tenant checks

Refresh token & session lifecycle

The checklist

What the checklist covers

OAuth is rarely broken by the spec. It is broken by small product and architecture decisions: the wrong flow chosen for the wrong client, redirect handling that grew permissive over years, token validation that quietly skipped a step.

This is an opinionated hardening companion to RFCs 6749, 7636, 7662, 8252, 9207 and 9700 - some lines are deliberately stricter than the spec requires, to close failure modes we see in real reviews.

Much of that strictness simply tracks where the spec is going. OAuth 2.1 (the IETF draft draft-ietf-oauth-v2-1) folds OAuth 2.0, PKCE and the Security BCP into one document: PKCE mandatory for every client, exact redirect-URI matching, no bearer tokens in query strings, and the Implicit and Password grants removed. Where a check here looks stricter than the OAuth 2.0 you know, it is usually already the 2.1 default.

Compliance documents tell you what to write down; this is the other kind: what to verify on the request path.

OAuth ≠ authentication

An access token is an authorization credential, not a login assertion for the relying app. If your application needs to know who the user is, use OpenID Connect on top of OAuth and validate the security-relevant ID token claims required for the flow.

Flow and layering

No code path uses a raw access token as a login assertion for the client application. If the app needs to know who the user is, it uses OIDC and reads identity from a validated ID token.
The login flow obtains an ID token. The UserInfo endpoint may be called with an access token for additional claims, but session identity is anchored to validated ID token claims, not to UserInfo output alone. If UserInfo is used, its sub claim must exactly match the validated ID token's sub.
The user's stable internal ID is the tuple (iss, sub), never sub alone (only unique within an issuer), and never email or preferred_username (mutable and attacker-influenceable).

ID token claim validation

The iss claim is compared exact-match against the expected issuer URL. Not startsWith, not a regex.
The aud claim contains this application's registered client ID. If aud has multiple values, the token is rejected unless the additional audiences are explicitly trusted. If azp is present, it equals this client ID unless the integration has a documented reason otherwise.
The exp claim is enforced with a tight clock-skew window (at most 120 seconds); iat is used for freshness, and tokens older than a reasonable bound are rejected even if not expired.
If a nonce was sent on the authorization request, the nonce claim on the ID token is verified against the session-bound value and consumed, never accepted twice.

Signature verification

Every ID token signature is verified against the IdP's JWKS. The expected algorithm is pinned (typically RS256 or ES256) and never accepted from the token header. The none algorithm is rejected.
JWKS is refreshed on signature-verification failure to handle key rotation, rate-limited to prevent denial of service against the IdP. A missing or unknown kid fails closed and never falls back to unverified.

PKCE and public client safety

Single-page apps and mobile clients cannot keep a secret. Without PKCE, an intercepted authorization code is a free pass. Implicit Flow is deprecated; do not ship it.

Authorization Code Flow, S256, and the death of Implicit.

Redirect URI handling

Most major OAuth account-takeover writeups in the last five years start the same way: a redirect URI that matched more than it should have. Exact-match allowlists close the entire category.

Exact allowlists, callback hygiene, native apps.

State, nonce and mix-up defense

The state parameter is the OAuth flow's CSRF token. Without it, or with one that is reusable or unbound from the session, an attacker can stitch their own authorization code into your user's session.

CSRF, replay, and IdP confusion.

API token trust

An access token is untrusted input until your API validates issuer, audience, expiry, scope, tenant context, and token integrity. JWT and opaque tokens validate differently; both must be validated.

JWT vs opaque, claim validation, object-level authorization.

Refresh tokens and session lifecycle

The hidden sixth mistake. Refresh tokens live longer, fail more silently, and rarely get the same scrutiny as access tokens. They are also the easiest path to a persistent session takeover.

Rotation, family revocation, session hygiene.

Federation and client hardening

The lines outside the obvious flow that quietly determine whether your federation can be subverted. Discovery, client authentication, and account linking are where mature implementations still grow real findings.

Discovery, client auth, account linking, logging.

The full guide has all 60+ checks across these sections as a printable pass/fail PDF. Grab it using the form above.

Who it's for

SaaS teams adding SSO
Backend engineers reviewing OAuth/OIDC
CTOs and security leads preparing for enterprise buyers

Need the implementation reviewed?

Pentecton reviews OAuth/OIDC flows, token validation, redirect handling, session lifecycle, and API trust boundaries before SSO reaches production.

Discuss a product security review