What is OpenID Connect, and why OAuth alone is not login

OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0. It defines how an application learns who the user is, in a standard and verifiable way: an ID token with the user's identity, a userinfo endpoint, and a discovery document that tells clients where everything lives.

OAuth 2.0 gives you an access token that says "this client may call this API". OIDC adds: "and here is a signed statement that this is Alice, issued for this application, at this time."

The pieces

ID token. A signed JSON Web Token (JWT) issued by the OpenID provider. The client validates it and reads the claims:

Access token. Still an OAuth token, used to call APIs. It is usually not a JWT, and clients should treat it as opaque.

Userinfo endpoint. An API that returns profile claims for the access token, for data you do not want in the ID token.

Discovery document. At /.well-known/openid-configuration, the provider publishes its issuer, authorization endpoint, token endpoint, userinfo endpoint, supported scopes and JWKS URI (where the signing keys live). A client that supports discovery only needs the issuer URL to be configured.

The flow

For web, mobile and single-page apps, the standard flow is authorization code with PKCE:

1. The client redirects to the authorization endpoint with client ID, redirect URI, scopes (openid is required), state and a PKCE code challenge.
2. The user authenticates at the provider.
3. The provider redirects back with a short-lived code.
4. The client exchanges the code (plus the PKCE verifier) at the token endpoint.
5. The response contains an ID token, an access token, and optionally a refresh token.

Native and single-page apps must not ship a client secret; PKCE takes its place.

Validating an ID token

Getting this wrong is how OIDC integrations become insecure. The client must check:

1. Signature — against the provider's JWKS, and the key must match the token's header.
2. Issuer — iss equals the expected provider.
3. Audience — aud contains this client's ID.
4. Expiry — the token is within exp (with a small clock skew).
5. Nonce — matches the value the client sent in the request.
6. Algorithms — reject none and unexpected algorithms.

Only then is sub trustworthy as the user identifier. Treat email as an attribute, not a key: emails change and can be reassigned.

Scopes and claims

• openid — required; requests an ID token.
• profile — name, picture, locale and similar claims.
• email — email and email_verified.
• address, phone — the obvious.

Anything beyond these is provider-specific. Keep the requested scopes minimal: every additional scope is data the user is asked to approve.

OIDC vs OAuth vs SAML

• OAuth 2.0 — authorization for APIs.
• OIDC — authentication on top of OAuth; the default for new applications.
• SAML — XML-based enterprise SSO; still the language of procurement.

A single identity provider usually speaks all three. Casdoor, for example, issues OIDC tokens for your apps and SAML assertions for applications that require SAML, from the same user store.

Read more: OAuth vs OIDC, what OAuth 2.0 is and SAML vs OIDC.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.