What is the difference between OpenID Connect and OAuth?

OAuth 2.0 is an authorization framework; OpenID Connect is an authentication layer built on it. OAuth issues an access token that grants scoped access to resources, such as reading a calendar. OIDC issues an ID token that states who the user is, so the application can log them in. Same core flows, different purpose: OAuth answers "what can this app do," OIDC answers "who just signed in."

The practical tell is the token you care about. If your app needs to call an API, you want an OAuth access token. If your app needs to establish a session for a person, you want the OIDC ID token. Most real products need both at once, which is why they usually adopt OIDC and get the OAuth machinery underneath it as part of the deal.

What is OpenID Connect?

OpenID Connect is a standard identity layer on top of OAuth 2.0 that lets an application verify a user's identity and get basic profile information in a predictable format. It was published by the OpenID Foundation, and the normative definition lives in OpenID Connect Core 1.0. Where OAuth deliberately says nothing about the user, OIDC standardizes exactly how identity is proven and shared.

It does this with a few additions to the OAuth flow. The user authenticates at the provider, and the application receives an ID token alongside the usual access token. The openid scope is what turns an ordinary OAuth request into an OIDC one. A standard UserInfo endpoint returns profile claims, and a discovery document lets clients configure themselves automatically. Because these pieces are standardized, any OIDC-compliant client works with any OIDC-compliant provider.

What does OpenID Connect add to OAuth 2.0?

OIDC adds five things OAuth leaves undefined, and together they turn "access delegation" into "login." Each one exists because raw OAuth left a gap that teams were filling inconsistently and often insecurely.

The additions are the ID token, a signed statement of who the user is; a set of standard identity scopes (openid, profile, email) that request specific profile data; the UserInfo endpoint for fetching that profile; a discovery document and JWKS so clients auto-configure and verify signatures; and the nonce parameter that ties an ID token to a specific login request to block replay. None of this exists in base OAuth; discovery is the one idea useful enough that OAuth later borrowed it back as RFC 8414's authorization server metadata. Using OAuth alone to log people in, sometimes called pseudo-authentication, is a known anti-pattern rather than a shortcut, and the failure is concrete.

Base OAuth defines no way for a client to validate an access token at all; format and validation are out of scope of RFC 6749. Token introspection (RFC 7662) arrived later, in 2015, and can return the client_id a token was issued to, but it is an authenticated server-to-server check that the social providers of the era did not offer, and even where it exists it proves the token is valid, not that a login just happened, so a token replayed within its lifetime still passes. UserInfo does not help either: it returns claims about the user, never the client the token belongs to. So an attacker can run a harmless-looking app of their own, collect valid access tokens from the people who use it, and replay one of those tokens to your app's login endpoint; your app resolves the victim's profile and starts a session for the attacker. This token substitution attack is what broke early social logins built on raw OAuth, and the providers' fixes (Google's tokeninfo with its check-the-aud guidance, Facebook's debug_token) were proprietary patches for exactly this hole before OIDC standardized one. The ID token closes it by design: the client verifies it offline, its audience claim names your client, its signature proves the issuer minted it, and its nonce binds it to the login request your app actually made.

What is inside an OpenID Connect ID token?

An ID token is a JWT that carries claims about the authentication event and the user. The format is not incidental: OAuth never mandated a format for access tokens (opaque strings are fully compliant, and JWT access tokens only became a standardized option with RFC 9068 in 2021), while ID tokens have been JWTs from day one, which is what lets the client verify one on its own. It is meant for the application that requested the login, not for calling APIs, and the app validates it the way it would any JWT (signature, issuer, audience, expiry), plus one OIDC-specific check: the nonce must match the value the app sent.

The claims you will always see are iss (the issuer), sub (a stable unique ID for the user), aud (the client the token was issued for), exp and iat (expiry and issued-at times), and usually nonce (the value that binds the token to the login request). Depending on the scopes requested and how the provider is configured, it may also carry profile claims such as email, email_verified, name, or picture, though in the authorization code flow the spec's default is to return scope-requested claims from the UserInfo endpoint rather than inside the ID token. Because it is a JWT, it is signed by default and only rarely encrypted, so never treat the payload as secret.

OpenID Connect vs OAuth: a side-by-side

The cleanest way to hold the two apart is by what each is for and what it produces.

When should you use OpenID Connect vs OAuth?

Use OpenID Connect when your application needs to know who the user is, and use OAuth on its own only when it needs delegated access to an API without caring about identity. Login, single sign-on, and any session tied to a person all call for OIDC, because they depend on the ID token. Machine-to-machine calls and pure API-access delegation can stay on OAuth alone.

In practice the split is rarely either-or. A typical web app signs the user in with OIDC and, in the same flow, receives an OAuth access token to call its own APIs. The mistake to avoid is reaching for raw OAuth to authenticate, then inferring identity from an access token that was never meant to prove it. For the SaaS-specific view of OAuth flows and scopes, see OAuth for SaaS.

How does MonoCloud support OpenID Connect?

MonoCloud is an OIDC-certified identity platform, so OpenID Connect is the standard it is built on, not a bolt-on. It issues standards-based ID tokens, supports the standard identity scopes (openid, profile, email), and exposes the UserInfo endpoint for profile data, so adding compliant login to your app takes configuration rather than custom protocol code.

Certification matters here because it is verifiable: the implementation passed the OpenID Foundation's conformance suite and sits on their public list of certified providers, which is what lets standard OIDC libraries work against it without special-casing. You can control what a token carries and whether it can be used at the UserInfo endpoint through MonoCloud's API Access Policies, or start building on MonoCloud for free.