OAuth 2.0 vs OpenID Connect: what's the difference?

OAuth 2.0 lets an application get permission to call an API on a user's behalf. OpenID Connect (OIDC) is a layer on top of OAuth 2.0 that also tells the application who the user is. If you're adding "Sign in with ..." to an app, you want OIDC; if you're letting an app call an API, you want OAuth 2.0; most real apps use both at once.

At a glance

What OAuth 2.0 does

OAuth 2.0 solves the "give this app access without giving it my password" problem. The user approves a request at an authorization server, and the app gets an access token that an API (the resource server) accepts. The token says what the app may do, through scopes, but OAuth 2.0 itself says nothing about who the user is.

That gap caused a classic mistake: apps that treated "I received an access token" as "the user is signed in". An access token issued to another app can be replayed against yours, so it's not proof of login.

What OpenID Connect adds

OIDC uses the same endpoints and flows, and adds:

• The ID token: a signed JWT, meant for the application, with the user's identifier (sub), the issuer (iss), the client it was issued to (aud), when the user authenticated, and a nonce that ties it to this login.
• Standard claims and the UserInfo endpoint, so every provider describes users the same way.
• Discovery and JWKS: one URL tells the app every endpoint and where to find the signing keys.
• Session and logout specifications, so signing out of the identity provider can sign the user out of apps too.

Which flow to use

For almost every app, use the authorization code flow with PKCE:

1. The app redirects the browser to the authorization endpoint with response_type=code, its client ID, the redirect URI, the scopes (openid profile email for login) and a PKCE code challenge.
2. The user signs in and approves.
3. The app receives a one-time code and exchanges it at the token endpoint, with the PKCE code verifier, for an ID token, an access token and optionally a refresh token.

The IETF's OAuth security best practice (RFC 9700) says not to use the implicit flow or the resource owner password grant. For server-to-server calls with no user, use the client credentials grant; for CLIs and TVs, the device authorization grant.

Common mistakes

• Using the access token as proof of identity. Validate the ID token (signature, iss, aud, exp, nonce) to sign a user in.
• Sending the ID token to APIs. APIs should receive access tokens; the ID token's audience is your app.
• Skipping PKCE in single-page and mobile apps.
• Reading claims without checking the signature against the provider's JWKS.

OAuth 2.0 and OIDC with Casdoor

Casdoor is an open-source OAuth 2.0 authorization server and OpenID Connect provider. It publishes discovery and JWKS, supports the authorization code flow with PKCE, refresh tokens, client credentials, device authorization, token exchange and DPoP, and issues separate access and ID tokens: the access token's tokenType claim is access-token and the ID token's is id-token, so one can't be used in place of the other. Tokens can be introspected and are revoked when the user signs out of a session or changes their password.

The same server also does SAML, CAS, LDAP and RADIUS for apps that don't speak OIDC. Self-host it for free, or run it on Casdoor Cloud from $24/month billed yearly. See also SAML vs OIDC and OAuth for AI agents.

FAQ

Is OIDC a replacement for OAuth 2.0? No. OIDC is built on OAuth 2.0. An OIDC login is an OAuth 2.0 authorization request with the openid scope, and it returns an access token as well as the ID token.

Is a JWT an OAuth token? A JWT is a token format. OIDC ID tokens are always JWTs; OAuth 2.0 access tokens may be JWTs or opaque strings, depending on the server.

What is OAuth 2.1? A draft that consolidates OAuth 2.0 and its security best practices: PKCE for every authorization code flow, and no implicit or password grants. The MCP authorization specification for AI agents is based on it.

Do I need OIDC if I only call APIs? No. Machine-to-machine calls with the client credentials grant need only OAuth 2.0.