OAuth and OIDC Security Testing for SaaS

Short answer

OAuth/OIDC testing is more than checking a login screen or JWT signature. Verify identity transitions among the browser, client, authorization server, and SaaS backend; which API accepts each token; and how account linking and deactivation work. The critical failure is a valid token accepted for the wrong API, client, user, or tenant.

OAuth delegates authorization and OIDC defines identity assertions. Using the protocols does not guarantee a safe configuration. Map SPAs, mobile apps, server-side web apps, and enterprise SSO as distinct flows.

Inventory flows and transaction binding

For each client, record client_id, exact redirect URIs, expected issuer, token audience, and permitted grant types. Follow trust from login initiation through callback, code exchange, session creation, refresh, and logout.

Test that redirect URIs match exact registered values. Wildcards, loose subdomain matching, open redirects, and user-controlled callbacks can send authorization codes elsewhere. Try encoding and slash variants, then document what is accepted.

state should bind the callback to the initiated browser transaction; an OIDC nonce binds the identity token to the login request; PKCE binds the code to the verifier from the same client transaction. Capture a valid flow and then exchange state, nonce, and code across sessions. A mismatched callback must not complete.

Does the token belong to this API and user?

A valid signature is not enough. APIs should validate expected issuer, audience, token type, algorithm, lifetime, and scopes or roles. Try an ID token as an access token and present an access token issued for another service. A signed token with the wrong audience or issuer must be rejected.

Review JWKS rotation, kid selection, caching, and unexpected algorithms. Do not choose a key source from an untrusted claim, and bound acceptance of old keys. Error responses must not reveal tokens or verification secrets.

Account linking and tenant membership

Linking a social identity to an existing SaaS account is a high-impact decision. Do not assume equal email values from different issuers represent the same person. Test email changes, aliases, invitations, and unverified accounts for automatic merging. Adding an identity to an existing session should require fresh authentication and clear user intent.

For enterprise SSO, domain matching alone does not establish tenant membership. Test invitations, SCIM provisioning, suspension, and identity-provider removal to determine how tenant roles are updated.

Scenario	Safe result
Same email, different issuer	No automatic account merge
SSO identity outside tenant	No access without explicit membership
Disabled user	New sessions and sensitive refresh are rejected
Token intended for another API	Rejected on audience mismatch
Callback from another browser	Cannot complete without matching state/PKCE

Refresh, logout, and lifecycle

Review refresh-token rotation, reuse detection, and storage per client. Verify expected revocation if an old token is reused. Logout must not only delete a browser cookie while leaving server sessions or refresh active.

Measure access lifetime after password change, MFA reset, employee departure, and tenant removal. A short-lived JWT is not immediate revocation; prove that critical operations check current account state.

Safe test sequence

Diagram every client and login type.
Capture a sandbox flow and redact tokens.
Break redirect, state, nonce, PKCE, and callback-session binding independently.
Present tokens to the wrong issuer, audience, API, tenant, and role.
Test linking, invitations, provisioning, deactivation, and refresh reuse.
Report the protocol defect and the account or tenant access it enabled.

Threat models differ by client type

A public client cannot keep a secret confidential. For SPAs and mobile apps, a secret embedded in the package is not a security boundary; Authorization Code with PKCE and strict redirect registration matter more. A confidential web client needs separate review of client authentication, secret or private-key storage, and access to the token endpoint. Service-to-service flows should use narrowly scoped service identity rather than impersonating a user session.

When multiple identity providers or issuers exist, review how iss and sub are mapped within a tenant. Treating sub alone as a global user key can create collisions across issuers. Disconnecting a tenant’s IdP should clarify not only new logins but also existing sessions and refresh-token lifetime.

Observe failures safely

Do not place authorization codes, access tokens, refresh tokens, or ID tokens in a report as plain text. Preserve redacted request and response evidence; where possible, show only relevant claims such as iss, aud, expiry, and role. User-facing errors should not expose validation internals, while server logs should retain a safe diagnostic code that distinguishes issuer mismatch, audience mismatch, and expiration.

Prioritize findings by the action they enable, not by protocol terminology. A rejected token presented to another API is evidence of a working boundary; acceptance in another tenant’s administrative API is a high-impact authorization failure. Retesting should prove both that the attack path no longer works and that legitimate sign-in for the correct user and tenant still succeeds.

For an assessment connecting OAuth/OIDC with application and API controls, see our application security testing service.