OAuth 2.0 and OpenID Connect Security Checklist for SaaS Applications

Overview

OAuth 2.0 is an authorization framework: it lets an application obtain limited access to a resource or service without handling the user’s password. OpenID Connect, commonly called OIDC, adds an identity layer to OAuth 2.0. It provides a defined way to authenticate a user and receive identity information, usually through an ID token and a user-information endpoint.

For a SaaS application, the normal sign-in pattern is the authorization code flow with Proof Key for Code Exchange (PKCE). The user is sent to the identity provider, authenticates there, and returns to the application with a short-lived authorization code. The application exchanges that code for tokens through a protected token request. PKCE binds the exchange to the original client request and is an important control for public clients and browser-based applications.

Keep the responsibilities separate:

• OAuth 2.0: delegated authorization and access-token handling.
• OpenID Connect: authentication, identity claims, issuer discovery, and ID-token validation.
• Your SaaS application: session creation, account selection, authorization decisions, logging, revocation behavior, and tenant isolation.

A successful provider login does not automatically prove that the resulting SaaS session is safe. Treat the callback, token exchange, identity mapping, and local session as one security boundary. For related guidance, see the Session Management Security Guide and How to Verify JWTs Safely.

What to track

1. Authorization requests and callback handling

• Use the authorization code flow with PKCE. Generate a high-entropy code verifier, derive the challenge with the provider-supported method, and use each verifier only once.
• Generate a unique state value for each login attempt. Store it in a short-lived, appropriately protected transaction record and compare it on return. Reject missing, expired, reused, or mismatched values.
• For OIDC, generate a unique nonce, bind it to the login transaction, and verify it in the returned ID token.
• Allow only exact, pre-registered redirect URIs. Avoid accepting arbitrary subdomains, path fragments, wildcard patterns, or user-supplied redirect destinations unless the provider and your design explicitly require them and the validation is narrowly constrained.
• Do not place access tokens or ID tokens in URLs, analytics events, support tickets, or client-visible error messages.

2. Token and claim validation

Validate tokens according to their intended use rather than merely decoding them. A JWT decoder can help inspect a token during development, but decoding does not verify its signature or establish trust. Check the expected issuer, audience, signature algorithm, signature, expiration, not-before value where used, and relevant identity claims. OIDC ID tokens also require the provider’s documented validation rules, including the nonce check.

Use an allowlist for algorithms and obtain signing keys through the provider’s documented discovery and key-set mechanism. Handle key rotation and key-fetch failures deliberately. Never let a token header choose an unsafe verification algorithm, and never treat an unverified claim such as email or role as sufficient authorization.

For hands-on token review, use the JWT Token Decoder Guide without pasting production secrets into an online tool.

3. Scopes, consent, and provider configuration

• Request the smallest scopes needed for the feature. Separate sign-in scopes from scopes that grant access to APIs, files, mail, billing, or administration.
• Explain why each requested permission is needed and show a useful consent screen. Do not hide broad access behind an unrelated “Continue” action.
• Configure allowed origins, redirect URIs, logout URLs, client types, token endpoints, and discovery endpoints explicitly for each environment.
• Keep development, staging, and production clients separate. Review who can change provider configuration and require an auditable approval path.
• Confirm provider-specific limits and behavior, including refresh-token rules, consent prompts, logout support, key rotation, claim formats, and rate limits. Record these as configuration assumptions rather than relying on memory.

4. Refresh tokens, logout, and account linking

Protect refresh tokens as high-value credentials. Store them in a protected server-side store where possible, encrypt them at rest, limit access, and avoid exposing them to browser scripts. If the provider supports refresh-token rotation, replace the stored token after use and detect reuse according to the provider’s model. Revoke or invalidate stored credentials when a user disconnects an account, an administrator disables access, or suspicious activity is confirmed.

Design logout at two levels: terminate the local SaaS session and, where supported and appropriate, initiate provider logout. Make the post-logout redirect exact and prevent it from becoming an open redirect. A user who signs out should not be silently restored to the same local session through an unexamined cached callback or session cookie.

Account linking deserves its own review. Do not link a new provider identity solely because an email address matches. Require the user to prove control of the existing account or an active session, explain the link, and log the event. Be especially cautious with mutable, unverified, or provider-specific email claims.

Threat-to-control checklist

Cadence and checkpoints

Make OAuth and OIDC review part of the application’s operating rhythm, not a one-time launch task. A monthly or quarterly review can be lightweight if configuration, incidents, and test results are already recorded.

Before every release

• Run successful-login, denied-consent, cancelled-login, expired-code, reused-code, and invalid-state tests.
• Confirm that tokens are not written to logs, browser history, URLs, screenshots, or client-side error reports.
• Check tenant selection and role assignment after login. A valid identity must not bypass SaaS authorization boundaries.
• Review changes to callback routes, session cookies, scopes, SDK versions, and provider settings.

Monthly or quarterly

• Review provider applications, redirect URIs, logout destinations, scopes, owners, and environment separation.
• Examine failed exchanges, unusual callback errors, refresh-token failures, account-link events, and administrative changes.
• Confirm that signing-key discovery, key rotation handling, clock synchronization, and dependency updates work as intended.
• Re-run a small set of negative tests and document any accepted deviations from the standard flow.

After a provider or browser change

Repeat the review when an identity provider changes its SDK defaults, endpoints, claim behavior, consent experience, token policy, or browser integration. Also revisit it after changes to cookie behavior, browser storage, redirect handling, or embedded-login patterns. Provider documentation and application assumptions should be reviewed together.

Deployment review template

1. Flow: Authorization code with PKCE; client type and token exchange location recorded.
2. Redirects: Exact production, staging, and development URIs checked against provider configuration.
3. Binding: State and nonce generated, stored, compared, expired, and single-use.
4. Validation: Issuer, audience, signature, algorithm, time claims, nonce, and required claims verified.
5. Permissions: Scopes documented, minimized, and shown in an understandable consent experience.
6. Credentials: Refresh-token storage, rotation, revocation, and reuse handling tested.
7. Sessions: Local logout, provider logout where applicable, cookie settings, expiration, and reauthentication reviewed.
8. Identity mapping: Stable provider identifiers used; account linking requires an authenticated action.
9. Operations: Logs exclude secrets and capture enough context to investigate failures without exposing tokens.

How to interpret changes

Not every increase in login errors indicates an attack, and not every successful login indicates a healthy integration. Interpret changes by grouping them with deployment, provider, browser, and user-context data.

• More invalid-state errors: investigate lost transaction state, multiple tabs, callback replay, cookie behavior, or a state-storage regression. Do not simply disable state validation.
• More invalid-nonce or claim failures: check issuer selection, clock differences, discovery configuration, provider changes, and whether the correct token is being validated.
• More token-exchange failures: check redirect URI drift, expired codes, PKCE mismatches, client credentials, provider limits, and whether retries are reusing a one-time code.
• More account-link requests: review the user journey and fraud signals. A rise may reflect clearer product design, but it can also indicate attempted takeover or ambiguous identity mapping.
• More refresh-token reuse or revocation events: treat the pattern as a credential-handling signal. Review storage, rotation, device behavior, session invalidation, and incident-response procedures.

Track both security and usability measures: successful completion, cancellation, denial, callback failure, time to completion, support contacts, linking outcomes, and manual investigations. Segment results by provider, application version, environment, and browser where that data can be collected responsibly. Avoid retaining raw tokens or unnecessary personal data in these records. For broader identity testing, use the Identity Verification Quality Assurance checklist.

When to revisit

Schedule a documented OAuth and OpenID Connect review at least monthly or quarterly, depending on the application’s change rate and risk. Revisit immediately after an identity-provider configuration change, SDK or authentication-library update, browser behavior change, new redirect route, scope expansion, account-linking change, token-storage redesign, security incident, or penetration test.

Use the following short action plan:

1. Assign an owner for provider configuration and a separate reviewer for security-sensitive changes.
2. Export or record the current redirect URIs, scopes, logout routes, client types, issuer, audience, and token-storage design.
3. Run the negative test cases: missing or mismatched state, missing or mismatched nonce, altered code, wrong audience, expired token, unapproved redirect, reused code, and unauthorized account link.
4. Compare results with the previous review and investigate material changes rather than normalizing them.
5. Update the deployment checklist, provider notes, runbooks, and user-facing consent language when behavior changes.

OAuth 2.0 and OIDC security is a continuing control system. Keeping a small, current record of configuration, tests, failures, and decisions makes the next release review faster and helps the team detect account-takeover risks before they become confusing login incidents.