eastbaycyber

OAuth vs OpenID Connect: What’s the Difference?

FAQs 7 min read
EC
East Bay Cyber Editorial Team Reviewed 2026-05-16
Short answer

OAuth 2.0 is for authorization—letting an app access a resource (like an API) on a user’s behalf. OpenID Connect is for authentication—it adds an identity layer to OAuth 2.0 so apps can verify who the user is using an ID token and standardized claims.

OAuth 2.0 and OpenID Connect (OIDC) are often mentioned together—but they solve different problems. OAuth 2.0 is authorization (scoped access to APIs), while OpenID Connect is authentication (who the user is) built on top of OAuth 2.0. Getting this distinction right prevents common JWT and token-validation mistakes in SSO and “Login with X” implementations.

TL;DR

  • OAuth 2.0 is authorization: grant an app scoped access to an API.
  • OpenID Connect (OIDC) is authentication on top of OAuth: prove who the user is via an ID token.
  • If you’re doing “Login with X,” use OIDC; for API access delegation, use OAuth—often both together.

Detailed Explanation

Security teams keep seeing the same root cause behind “SSO bugs” and token misuse: treating OAuth access tokens as if they were proof of identity. The simplest way to keep the concepts straight:

  • OAuth 2.0 answers: “Is this app allowed to call that API, and what can it do?”
  • OpenID Connect answers: “Who is the user that just signed in?”

If you’re investigating token confusion in an incident or review, it also helps to understand what an indicator looks like in logs—see our glossary entry on IOCs: what is an ioc.

What OAuth 2.0 actually does

OAuth 2.0 is an authorization framework designed for delegated access. It defines roles and interactions among:

  • Resource Owner: typically the end user
  • Client: your application (web, mobile, SPA, server-to-server)
  • Authorization Server: issues tokens after authenticating the user (or client)
  • Resource Server: the API being accessed

The output of OAuth is usually an access token (and optionally a refresh token). The access token represents permission—commonly expressed as scopes like read:invoices or calendar.events:write.

In practice, OAuth is what powers scenarios like:

  • A CRM app accessing a user’s Google Calendar with limited scopes
  • A CI tool calling a Git provider API
  • A mobile app calling your backend API with a short-lived bearer token

Technical Notes: tokens in OAuth

OAuth does not require access tokens to be JWTs; they can be opaque strings. Regardless of format, access tokens are intended for APIs, not for “logging in” to the client app.

Access token (OAuth):
- Audience: the API (resource server)
- Purpose: authorization to call endpoints
- Contents: not standardized (opaque or JWT)

What OpenID Connect adds

OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0. It standardizes how a client:

  1. redirects a user to authenticate, and then
  2. receives proof of authentication plus identity attributes

OIDC introduces the ID token (usually a JWT) and standard identity claims like:

  • sub (stable user identifier)
  • iss (issuer)
  • aud (intended client)
  • exp, iat (token lifetime metadata)
  • Optional profile claims like email, name (depending on scopes and configuration)

OIDC also standardizes key operational details needed for real deployments:

  • Discovery metadata (/.well-known/openid-configuration)
  • JWKS for signature verification (public keys)
  • UserInfo endpoint (optional identity retrieval)
  • Standard scopes like openid, profile, email

If you’re implementing SSO, “Sign in with …”, or need to establish a user session in your app, you want OIDC.

Technical Notes: how OIDC “turns on” identity

OIDC is “OAuth plus identity” triggered by using the openid scope.

GET /authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&
  scope=openid%20profile%20email&
  state=STATE&
  nonce=NONCE
HTTP/1.1
Host: idp.example.com
  • scope=openid ... indicates OIDC (authentication).
  • nonce helps bind the ID token to the authorization request and mitigate replay.

How they’re used together (most common)

In many real systems, you use OIDC for authentication and OAuth for API authorization in the same flow:

  • App uses OIDC to sign the user in and create a session.
  • App also receives an OAuth access token to call APIs (your APIs or third-party APIs) on the user’s behalf.

This is especially common when the same Identity Provider (IdP) issues both:

  • an ID token (for the client app),
  • an access token (for the API),
  • and optionally a refresh token (to renew access).

Practical “which one do I need?” guidance

Use this quick mapping:

  • Need login / SSO / identity assertions? → OpenID Connect
  • Need delegated API access with scopes? → OAuth 2.0
  • Need both user login and API calls? → OIDC + OAuth together
  • Machine-to-machine service access (no user)? → Typically OAuth (e.g., client credentials), not OIDC.

Technical Notes: safe validation expectations

For an ID token (OIDC), the client should validate:

  • signature (JWKS), iss, aud, exp, and nonce (when used)

For an access token (OAuth), the API should validate:

  • signature or introspection result
  • aud (must be the API), scopes, expiry, issuer

Example JWT inspection workflow:

# Decode a JWT locally (no verification). Useful for troubleshooting only.
python - <<'PY'
import jwt, sys
t = sys.stdin.read().strip()
print(jwt.decode(t, options={"verify_signature": False}))
PY <<<'eyJhbGciOi...'

For production, verify signatures and claims using your platform’s JWT/OIDC libraries rather than ad-hoc decoding.

Common Misconceptions

1) “OAuth is for authentication”

OAuth can involve authenticating the user at the authorization server, but the OAuth output (access token) is not a standardized “who is this user” statement. Using access tokens as login artifacts is a classic design mistake that leads to:

  • confusion about token audience (aud)
  • leaking tokens to the wrong component
  • fragile integrations where a token format changes

If you need authentication, use OIDC ID tokens.

2) “If it’s a JWT, it’s an ID token”

A JWT is just a container format. Both access tokens and ID tokens are often JWTs, but they have different semantics and audiences.

Practical check:

  • If aud is your client app and the token contains identity claims (sub, nonce), it’s likely an ID token.
  • If aud is your API and the token carries permissions/scopes, it’s likely an access token.

If you want a deeper look at a related class of JWT implementation pitfalls, see: what is jwt confused deputy.

3) “The client should validate access tokens”

Typically, APIs validate access tokens, not browser-based clients. A SPA should avoid treating access token validation as “proof of login.” Instead:

  • Use OIDC to establish an authenticated session (or to get an ID token you validate).
  • Protect APIs by validating access tokens at the resource server.

4) “OpenID Connect replaces OAuth”

OIDC doesn’t replace OAuth; it builds on it. Most OIDC deployments still use OAuth mechanics (authorization code flow, token endpoint, refresh tokens, scopes). OIDC simply standardizes identity-related pieces that OAuth intentionally leaves out.

5) “Implicit flow is fine for modern web apps”

Modern best practice is Authorization Code Flow with PKCE for SPAs and mobile apps. Implicit flow is largely deprecated in favor of code + PKCE because it reduces token exposure risks.

Technical Notes: log clues that you’re using OIDC vs OAuth

Look for these patterns:

OIDC indicators:
- scope contains "openid"
- /.well-known/openid-configuration fetched
- id_token present in token response
- nonce parameter used

OAuth-only indicators:
- scopes like "read write" without "openid"
- no id_token returned
- API uses introspection endpoint heavily for opaque tokens

Security & Ops Tips (Practical)

  • Don’t store access tokens in places scripts can read (especially in SPAs). Prefer Authorization Code + PKCE and secure storage patterns recommended by your framework/IdP.
  • Enforce correct audiences: access token aud should match the API; ID token aud should match the client.
  • Keep tokens short-lived, and treat refresh tokens as highly sensitive credentials.
  • Instrument and alert on unusual token usage (wrong aud, impossible travel, abnormal refresh patterns). This is where good IOC hygiene pays off.

Tooling Note (Optional)

If you’re hardening developer workflows around sign-in testing (especially on public Wi‑Fi) or securing admin access to IdP dashboards, a reputable VPN can reduce exposure to hostile networks. Options include NordVPN (Check NordVPN pricing →) or Surfshark (Try Proton VPN →). (A VPN doesn’t fix incorrect token validation, but it can help reduce network-layer risk during routine work.)

For teams that need to tighten credential handling alongside SSO, consider a business password manager—see our guide here: password manager for small business 2026. One widely used option is 1Password (Try 1Password →).

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-05-16

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.