OAuth vs OIDC: The Difference and How the OIDC Flow Works

OAuth 2.0 vs OIDC comes down to one question: access or identity. OAuth 2.0 is an authorization framework that gives an application delegated access to an API through access tokens. OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0 that adds authentication through a signed ID token describing who the user is. Use OIDC to log a user in; use OAuth to let an app call an API.

Using the wrong one creates real security holes, which is why the distinction matters more than the acronyms. The same split runs through authentication vs authorization.

OAuth 2.0 vs OIDC side by side

How the OIDC flow works

The authorization code flow with PKCE is the one to use, for every client type:

1. Discovery. The client reads the provider's metadata from /.well-known/openid-configuration: endpoints, supported algorithms and the JWKS URI.
2. Authorization request. The client redirects the browser to the authorization endpoint with response_type=code, scope=openid plus any other scopes, a state, a nonce and a PKCE code_challenge.
3. Authentication. The provider signs the user in, applying its own MFA and policy, and redirects back with a one-time code.
4. Token request. The client sends the code and the PKCE code_verifier to the token endpoint and receives an ID token, usually an access token, and optionally a refresh token.
5. Validation. The client checks the ID token signature against the provider's published keys, that iss matches exactly, aud contains its client_id, exp is in the future and nonce matches.
6. Session. The client creates its own session from the sub claim and sends only the access token to APIs.

Plain OAuth is the same dance without step 5's ID token: the client gets an access token and calls the API, and never learns who the user is in a standard way. See the authorization code flow entry and the OAuth 2.0 and OIDC implementation guide.

Why the confusion causes real bugs

Using an access token as proof of identity. An access token says a client was authorized for some scope. It does not say who the user is, and in many designs it is not audience-restricted to your application. Accepting one as a login credential lets a token minted for a different application authenticate against yours. Use the ID token for authentication and derive your own session from it.

Sending an ID token to an API. The mirror image, and just as common. ID tokens are for the client, validated once at sign-in. Resource servers should receive access tokens. An API that accepts ID tokens is validating the wrong audience, or not validating at all.

Skipping validation entirely. CVE-2026-48558 let attackers forge OIDC tokens against SimpleHelp servers that did not properly validate signatures, giving technician access without credentials or MFA, and it was exploited in 2026 (incident record). CVE-2025-9485 in a WordPress OAuth SSO plugin and CVE-2026-5430 in WSO2 API Manager are the same class: JWT checks that accepted what they should have rejected.

What attackers do with OAuth in practice

The OAuth incidents in SWI's breach database rarely break the protocol. They abuse grants that work as designed:

• Consent phishing. UNC6040 phoned employees and talked them into authorizing a modified Salesforce Data Loader app (OAuth consent phishing). A password reset does not revoke a grant.
• Stolen refresh tokens. In the Salesloft Drift campaign, third-party app tokens gave standing access to many Salesforce tenants until Salesloft and Salesforce revoked them (refresh token abuse).
• Token replay. Bearer tokens work for whoever holds them. In 2026 stolen Microsoft 365 session tokens were replayed into 79 organizations, with device code phishing among the methods (token replay).
• Forged signing keys. Storm-0558 forged tokens with a stolen Microsoft consumer key, and a validation flaw let them open enterprise mailboxes. Strict issuer and audience checks are the client-side defense.

The current best practice

OAuth 2.1 consolidates a decade of security guidance into defaults worth adopting even if you stay on 2.0:

• Authorization code with PKCE for every client, confidential ones included.
• No implicit flow. Returning tokens in the redirect puts them in URLs, browser history, and referrer headers.
• No resource owner password grant. It requires the application to handle credentials, which is the thing OAuth exists to avoid.
• Exact redirect URI matching, not prefix or wildcard.
• No bearer tokens in query strings, and only the S256 PKCE method.
• Rotate refresh tokens on use and detect reuse of a spent token, which is the signal that a copy is circulating.

Where OAuth and OIDC are heading in 2026

Bearer tokens are the last large replay hole, which is why sender-constraining is gaining ground: DPoP binds a token to a key the client proves possession of, and mTLS does the same where you control the transport. AI agents run on the same machinery: the MCP authorization revision of July 28, 2026 builds on the OAuth 2.1 draft and RFC 9728, token exchange narrows scope at each hop, and the ID-JAG draft (draft-06, October 31, 2026) lets an enterprise IdP broker one app's access to another. GNAP (RFC 9635) is the clean-slate IETF alternative, but new deployments still build on OAuth 2.1.

Choosing an OIDC provider

For customer web login, most teams buy an OpenID provider rather than run one. Free tiers checked on October 30, 2026 for the Identity Pricing Transparency Index include Microsoft Entra External ID at 50,000 MAU, Auth0 at 25,000 MAU and Amazon Cognito at 10,000 MAU. Self-hosted options include Keycloak and Zitadel. Compare them in the best CIAM platforms ranking, and read SAML vs OIDC if enterprise customers will federate in.