On this page
What does OIDC do?
OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0. OAuth 2.0 was built to delegate access to resources, and it deliberately says nothing about who the user is. OIDC adds that missing piece in a form every library and gateway can parse.
The practical effect is that your application stops handling credentials. It sends the user to an identity provider, receives a signed statement about the outcome, and gets on with its own job.
Your application never sees the credential
The password, passkey, or face ceremony happens at the identity provider. Your code holds a token, not a secret, which removes a whole class of storage and handling risk.
One integration, many providers
OIDC is a specification, so the same client code works against a different provider after a configuration change. That portability is the main reason to prefer it to a vendor SDK.
Discovery configures the client
A provider publishes its endpoints and signing keys at a well-known URL, so a client finds the JWKS and follows key rotation instead of hard-coding a certificate.
How does OIDC work?
The common shape is the authorization code flow. Your application redirects the user to the identity provider, the user proves who they are, and the provider sends the browser back with a short-lived code. Your application then trades that code for tokens on a back channel.
The code exists so that tokens never travel through a browser address bar. Two extensions harden the exchange further, and both are worth turning on.
PKCE binds the exchange to the client
The client sends a hash of a secret it generated, then proves the secret at the token call. A stolen authorization code is useless without it, which matters most for mobile and single-page applications.
PAR keeps the request off the URL
With pushed authorization requests the client sends the parameters straight to the provider and receives a reference. Nothing sensitive sits in a URL where a log or a referrer header can capture it.
Each token has one job
The ID token describes the sign-in, the access token authorizes API calls, and a refresh token extends the session. Do not use an ID token as an API credential.
What is an ID token?
An ID token is a signed JSON Web Token (JWT) that describes one sign-in event. Your application verifies the signature against the provider's published keys, then reads the claims inside.
Verification is not optional, and it is not only the signature. Check the issuer, the audience, the expiry, and the nonce you sent, because a valid signature on somebody else's token is still a valid signature.
- iss: the issuer that produced the token.
- sub: the stable identifier for the user.
- aud: the client the token was issued for.
- exp and iat: when the token expires and when it was issued.
- nonce: the value your client sent, echoed back to defeat replay.
How does SenseCrypt use OIDC?
SenseCrypt is a passwordless identity provider (IdP) from Seventh Sense, and it is a standard OIDC provider. Your application uses the same library and the same code flow it would use with any other provider, and receives an ordinary signed ID token.
What differs is the ceremony behind the redirect. The user signs in by face, the match runs on the device, and the server stores no face image and no face template.
- OIDC with the authorization code flow, PKCE, and pushed authorization requests.
- CIBA, where a backchannel prompt starts a device-bound face ceremony.
- Discovery and JWKS endpoints for client configuration and key rotation.
- Standard claims release, including the roles and permissions SenseCrypt computes.
Frequently asked questions
Is OIDC the same as OAuth 2.0?
No. OAuth 2.0 handles authorization, or access to resources. OIDC adds authentication, or user identity, on top of OAuth 2.0.
What is the ID token for?
The ID token proves the user identity to your application. It is a signed JSON Web Token (JWT).
Does SenseCrypt support OIDC?
Yes. SenseCrypt is a full identity provider (IdP) with OIDC support. A user signs in by face login.
Related