What Is OpenID Connect?

Identity on top of OAuth

OAuth 2.0 grants access but says nothing standard about who the user is, which is a deliberate boundary in its design. OpenID Connect closes that gap by adding a well-defined identity layer that reuses OAuth's existing flows rather than inventing new ones. After a successful sign-in, an OIDC provider returns an ID token in addition to the usual access token, encoded as a JWT that the client can verify and read.

Because Merion's API is OIDC-secured, sign-in interactions follow these published conventions rather than a bespoke, undocumented scheme. The benefit of a shared standard is that well-tested, widely audited libraries can handle most of the heavy lifting for you, from redirects to token verification. You write integration code, not cryptography, and you inherit years of community scrutiny in the process.

The ID token

The ID token is the heart of OIDC and the piece that distinguishes it from plain OAuth. It is a signed JWT containing claims about the authentication event: who the user is (the subject), which provider issued it, the audience it was intended for, and when it expires. Unlike an access token, the ID token is meant for the client to consume and inspect, not to be forwarded to an API.

Standard claims such as subject, issuer, and audience give every OIDC integration a predictable shape, so code written against one provider transfers cleanly to another. Treat the expiry and audience claims as load-bearing security checks rather than optional metadata you can skim past. We unpack token internals in What Is a JWT.

Discovery and endpoints

OIDC providers publish a discovery document at a well-known URL, and this small piece of automation removes a lot of brittle configuration. The JSON file advertises the authorisation, token, and key endpoints, along with the scopes, claims, and signing algorithms the provider supports. Clients read it once at startup, so they never hard-code URLs that might later change.

The same document points to the JWKS endpoint used to verify token signatures, tying discovery and validation together. In practice you rarely parse this yourself — mature libraries fetch and cache it, then locate the right endpoints automatically. Knowing it exists, however, helps you understand where your library's behaviour comes from when you need to debug it. See the full API surface on the Merion API documentation.

When to use OIDC

Reach for OIDC whenever your application needs to authenticate a user — for example, to display their name, personalise a dashboard, or enforce per-user permissions inside your own application. If you only need machine-to-machine access with no human present, the plain OAuth client credentials flow is sufficient and OIDC adds nothing you would use.

A common and surprisingly persistent mistake is inspecting an access token to learn the user's identity. The ID token exists precisely to avoid that anti-pattern, keeping the two token types in their proper lanes: access tokens authorise calls, ID tokens describe the user. When you find yourself reaching into an access token for a name or email, that is the signal you actually wanted an ID token, and therefore OIDC, all along.