← All articles

OAuth 2.0 and OpenID Connect Security: Common Mistakes and Correct Use

2 September 2026

OAuth 2.0 and OpenID Connect Security: Common Mistakes and Correct Use

OAuth 2.0 and OpenID Connect (OIDC) are the foundation of modern “sign in with” flows. They are powerful but frequently misused, and a mistake in the identity flow can turn directly into account takeover. This article covers the difference between the two and the most common security mistakes.

First, the concept: OAuth ≠ OIDC

Two frequently confused concepts:

  • OAuth 2.0 is an authorization framework: “I allow this application to access a resource on my behalf.” Verifying who logged in is not its core job.
  • OpenID Connect (OIDC) is an authentication layer built on OAuth 2.0: it answers “who is this user?” with an identity token (ID token).

A common mistake is “borrowing” OAuth for authentication. The presence of an access token does not mean “the user logged in”; authentication requires OIDC and a validated ID token.

Common security mistakes

  1. Loose redirect URI: The authorization code/token is sent to the registered redirect address. If that address is loosely matched (open redirect or wildcard), an attacker can redirect the code/token to their own address. Match redirect URIs exactly and strictly.
  2. Not using PKCE: Especially for “public” clients (mobile/SPA), PKCE (Proof Key for Code Exchange) protects against interception of the authorization code. It is the recommended default today.
  3. Skipping the state parameter: state protects against CSRF-like flow forgery; it should be randomly generated and validated on every request.
  4. Storing tokens insecurely: Keeping access/refresh tokens in XSS-exposed places (like localStorage) turns an XSS into account takeover.
  5. Not validating tokens: The ID token’s signature, iss (issuer), aud (audience) and expiry must be validated.
  6. Over-broad scopes: Request only the permissions the app needs.

Summary

OAuth 2.0 is for authorization, OIDC for authentication — confusing them is the first mistake. The most critical controls: strict redirect-URI matching, PKCE for public clients, protecting the flow with state, storing tokens securely, and validating the ID token (signature/iss/aud/expiry). A weakness in this flow can lead directly to account takeover.

Sources: OAuth 2.0 Security Best Current Practice (RFC 9700), OpenID Connect.

Are your identity flows (redirect, tokens) configured securely? CyberTestify’s active verification and full pentest packages assess authenticated flows.