Protocols
OpenID Connect (OIDC)
An identity layer on top of OAuth 2.0 that lets an application verify who a user is, not just what it may access.
What OpenID Connect (OIDC) means
OpenID Connect is a thin identity layer built on OAuth 2.0. OAuth 2.0 answers 'may this client perform this action'; OIDC adds 'and here, in a verifiable form, is who the user is' — delivered as an ID token, a signed JWT containing claims about the authenticated user.
Defined in: OpenID Connect Core 1.0, built on OAuth 2.0 (RFC 6749).
How it works
The flow most applications use is the authorization code flow. The application redirects the browser to the identity provider, the user authenticates there, and the provider redirects back with a short-lived code. The application exchanges that code — from its server, not the browser — for an ID token and an access token. The user's credentials never touch the application.
The ID token is a JWT signed by the provider. The application validates the signature against the provider's published keys (its JWKS), then checks the issuer, the audience, the expiry and the nonce. Skipping any of those turns a cryptographically verifiable statement back into an unverified string, which is the single most common OIDC implementation error.
Because OIDC is a specification rather than a product, a compliant client library works against any compliant provider. That portability is the practical argument for it over a vendor's private protocol: switching providers is a configuration change plus a migration, not a rewrite.
The mistake people actually make
Using the access token to identify the user. The ID token is about the user; the access token is about permission to call an API and may be opaque, may be rotated on a different schedule, and is not addressed to your application. Reading user identity out of an access token happens to work until the provider changes its format.
In Authreads
How this applies here
Both integration paths — hosted login and the first-party API — are built on OpenID Connect and OAuth 2.0, with PKCE for the authorization code exchange.
Every capability is listed on /roadmap as Available, In progress or Planned. Nothing is described as available here that is not listed as Available there.
Guides that go deeper
- How to implement the OpenID Connect authorization code flow
- Logout in OpenID Connect: RP-initiated, front-channel and back-channel
- Step-up authentication: asking for more proof only when it matters
- An OAuth 2.0 and OpenID Connect security checklist
- Build vs buy authentication: an honest decision framework
- How to migrate from one identity provider to another
Related terms
OAuth 2.0
An authorization framework that lets an application obtain limited access to a resource without handling the user's credentials.
PKCE
Proof Key for Code Exchange — binds an authorization code to the client that requested it, so a stolen code is useless.
ID token
A signed JWT from an OpenID Connect provider carrying verifiable claims about the authenticated user.
JWKS
A JSON Web Key Set — the public keys an identity provider publishes so anyone can verify its signed tokens.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.