OpenID Connect (OIDC) Explained

What OIDC adds to OAuth 2.0/2.1

OAuth 2.0, specified in RFC 6749, was built to delegate access to resources. Identity sits outside its scope by design, which is why so many early attempts to use it as a login protocol were subtly broken: an access token establishes that something was authorized, not that a particular person signed in.

OIDC supplies that statement as a signed token with defined claims and a defined verification procedure. The practical effect is that an application stops touching credentials at all. It hands the person to a provider, accepts a signed assertion describing what happened, and returns to the work it exists to do.

The credential never reaches your code

Whatever the ceremony is, password, passkey or face, it runs at the provider. Application code ends up holding a token instead of a secret, which retires an entire class of storage, logging and handling risk.

Standard protocols simplify provider changes

Because the wire format is specified, moving to a different provider is a configuration change rather than a rewrite. That portability is the strongest argument for the protocol over a vendor SDK.

The client configures itself from discovery

Endpoints and signing keys sit at a documented well-known location. A client reads that document, resolves the JWKS for itself, and follows key rotation instead of pinning a certificate that will expire at an inconvenient hour.

How the code flow works

The standard shape is the authorization code flow. An application sends the user to the provider, the ceremony happens there, and the browser returns carrying a short-lived code. The application then trades that code for tokens over a back channel it controls.

That indirection exists so tokens never appear in a browser address bar, where history, referrer headers and access logs would capture them. Two extensions tighten the exchange further, and both belong on every client rather than only the sensitive ones.

PKCE ties the code to the client that asked for it

Under RFC 7636 the client publishes a hash of a value it generated, then reveals that value when it redeems the code. An intercepted code is inert without it. Use the S256 method; plain survives only for legacy reasons.

PAR moves the parameters off the address bar

With pushed authorization requests, RFC 9126, the client sends the parameters directly to the provider and receives a reference to use at the authorization endpoint. Nothing sensitive sits in a URL, and nothing in the request can be tampered with in the browser.

Each token has exactly one job

Identity comes from the ID token, permission to call an API from the access token, and continuity from the refresh token. Presenting an ID token as an API credential is the most common integration mistake, and the hardest to spot from outside.

What an ID token contains, and how to verify it

The ID token is a JSON Web Token, signed by the provider, that describes a single sign-in event. The application fetches the published keys, selects the right one by its key identifier, verifies the signature, and only then reads the claims.

Verification means more than the signature, and this is where implementations fail quietly. Confirm the issuer, confirm that the audience is your own client identifier, confirm the expiry, and confirm the nonce your client generated. A correct signature on a token minted for somebody else is still a correct signature.

iss: the issuer that produced the token, which must match the provider you configured.
sub: a stable, pseudonymous identifier for the user, safe to use as a primary key in your own database.
aud: the client the token was minted for, which must be your client identifier.
exp and iat: the expiry time and the issue time.
nonce: the value the client generated, returned unchanged so a replayed token can be spotted.
auth_time: when the authentication ceremony actually happened, which is not always when the token was issued.

The other tokens, and what they authorize

The ID token is the identity statement, and it is not the only token in play. Access tokens carry authorization to call an API, and refresh tokens carry the ability to obtain new access tokens without another ceremony.

The details that matter in production are the ones that decide what a leaked token can do and for how long. Those answers come from audience targeting, token lifetimes and rotation behavior rather than from the protocol name on the integration page.

Audience decides where a token is valid

An access token is minted for a specific audience, either your client or a resource server representing one of your APIs. An API that ignores the audience claim will accept tokens minted for something else entirely.

Scopes release claims, roles carry permissions

A scope controls which profile attributes are released into a token. A permissions claim is a different axis: it lists effective permissions for a targeted API, and it is emitted only when that resource server has role-based access control turned on.

Refresh tokens rotate, and families are revocable

A refresh token is opaque rather than a JWT and is issued only when offline access is granted. Reusing a spent token outside a short overlap window revokes the entire lineage, which turns token theft into a detectable event rather than a silent one.

How SenseCrypt implements OIDC

SenseCrypt is a passwordless identity provider from Seventh Sense and a standard OIDC provider. The library, the flow and the verification logic are the ones an application would use against any conformant provider, and what comes back is an ordinary signed ID token. Integration is standards-based configuration rather than installed software.

What differs sits behind the redirect. The user signs in with a live face check on their enrolled phone, and in the two mobile-app methods the match runs there. Each tenant is its own issuer with its own signing keys, and a token minted for one tenant never validates against another.

Authorization code flow with PKCE (S256 only) and pushed authorization requests.
FAPI-CIBA / CIBA, where a backchannel request opens a device-bound face ceremony instead of a browser redirect.
Discovery and JWKS endpoints, with in-grace keys published during rotation so clients follow it automatically.
Client credentials for machine-to-machine access to the tenant management and provisioning APIs.
Scope-driven claim release, plus role and permission claims for resource servers that enforce them.

Frequently asked questions

Is OIDC the same as OAuth 2.0/2.1?

No. OAuth 2.0/2.1 handles delegated access to resources. OIDC is an identity layer built on top of it that adds a signed statement about who the user is, along with the rules for verifying that statement.

What is an ID token used for?

It proves the user's identity to your application and carries the claims your scopes released. It is not an API credential: calling your own APIs is what the access token is for, and conflating the two is a common source of authorization bugs.

Do I still need PKCE if my client has a secret?

Yes, and it costs almost nothing to enable. PKCE binds the code exchange to the client instance that started it, which protects against code interception paths a client secret alone does not cover. SenseCrypt supports the S256 method and rejects the plain method.

How do I handle signing key rotation?

Fetch the tenant's JWKS from the discovery document and select the verification key by its key identifier rather than caching a single key indefinitely. During a rotation the previous key remains published in grace, so correctly written clients never see an outage.

Does SenseCrypt work with my existing OIDC library?

Yes. SenseCrypt is a standard OIDC provider, so a conformant client library configured against the tenant's discovery document works without provider-specific code. The face ceremony happens inside the provider's own flow and does not change the client integration.