Jan Mikoláš
Glossary
OpenID Connect
OAuth can grant access to an API. OpenID Connect also standardises how to verify the identity of a signed-in user through an ID token.
Short definition
User login built on the OAuth authorization foundation.
OpenID Connect (OIDC) extends OAuth 2.0 with authentication and a standard ID token. The client requests the openid scope, the user signs in with an OpenID Provider, and after validating the token the client can establish its own session. This is a common foundation for SSO and a “Sign in with …” button.
A successful OIDC login does not mean that a person can manage everything in the application. OIDC confirms an external identity; local roles, organisations, and permissions for individual data remain the responsibility of the application.
Use cases
Where OIDC solves a real identity problem
It is useful when an application trusts an identity provider instead of maintaining its own password store.
- signing an employee into an internal application through a corporate identity provider
- SSO for administration, a B2B portal, or multiple internal services
- connecting a customer application to an external identity
- obtaining a standardised identity without storing a separate password
- linking an external user through a stable issuer and subject pair
Practical example
Signing an employee into internal administration
The application knows the corporate OIDC provider. It reads the endpoints through Discovery, stores state and nonce, then redirects the employee to login with PKCE. On return, it compares state, exchanges the code, and validates the ID token, including its JWKS signature, issuer, audience, expiration, and nonce.
It looks up the local account by issuer + sub. The email is used for display. Only then does the application check whether the user belongs to the organisation and has an administrative role; the ID token is not sent to the internal API as an access token.
How it works
OIDC Code flow with PKCE
The client must trust a specific issuer and carefully validate both the return and the ID token.
- Discovery The application obtains metadata from a trusted issuer: the authorization endpoint, token endpoint, and jwks_uri.
- Auth request It sends response_type=code, scope openid, state, nonce, and a PKCE challenge to an exactly defined redirect URI.
- Login The OpenID Provider authenticates the user and returns the code and unchanged state to the client.
- Token exchange The client verifies state and exchanges the code together with the verifier for a token response.
- Validation and session It verifies the ID token signature, issuer, audience, expiration, and nonce, then creates its own session and applies local authorization.
Key concepts
Identity, tokens, and trusted keys
A token can be read, but its contents cannot be trusted without complete validation.
OP and RP
The OpenID Provider authenticates the user and issues the ID token. The Relying Party is the client application that trusts the provider and validates the token.
ID token and access token
An ID token is a statement about a login for a particular client. An access token is a credential for a resource server, such as the UserInfo endpoint or another API. They are not interchangeable.
Iss, sub, and aud
The issuer identifies the provider, the subject identifies the user consistently, and the audience identifies the client for which the token was issued. An external account should be linked by issuer + sub, not by email.
State, nonce, and JWKS
State prevents a forged return to a session, nonce binds the ID token to a particular login, and JWKS provides public keys for signature verification and rotation.
Benefits and limitations
Central identity without implementing a password system.
Benefits
- SSO and standardised login without maintaining a separate password store
- the ability to use MFA and identity-provider policies
- a stable identity link through issuer and subject
- Discovery and JWKS simplify integration with a supported provider
Risks
- using an ID token as a bearer token for an API
- trusting a token merely because it can be Base64URL-decoded
- linking a user only by a changeable email address
- accepting any issuer or a key specified by the token
Scope
The identity provider is a security dependency of the application.
OIDC makes sense for internal systems and multiple applications sharing a common identity. The design must account for provider outages, key rotation, and the fact that a user cannot be identified securely by a displayed email address alone.
An application must not accept an issuer, JWKS URL, or algorithm from untrusted input. It works with a pre-trusted issuer and verifies the signature, exact iss and aud, time-based claims, and nonce where one was sent. Neither the ID token nor UserInfo should be logged in full.
What to consider
Complete login only after full validation.
Every step must be bound to the same authentication transaction.
- Authorization Code with PKCE, with state and nonce stored in the original session
- an exactly registered redirect URI and trusted issuer
- verification of the ID token signature, iss, aud, exp, and nonce
- a JWKS cache that supports rotation, not an arbitrary URL from the token header
- local RBAC and organisations kept separate from the external identity
Common questions
What really needs to be verified
Is OpenID Connect the same as OAuth 2.0?
No. OIDC is built on OAuth 2.0 and adds standardised user authentication and an ID token.
Can I use an ID token to call an API?
Usually not. An ID token is intended for the client application; the API expects an access token with the appropriate audience and permissions.
What is the difference between state and nonce?
State binds the browser return to the original session. Nonce binds a specific ID token to the authentication request and limits replay.
Why is reading the email from the token not enough?
Without validation, the token may be forged, intended for another client, or expired. An email address is not a stable primary identity either.
How I approach integrations with external services
I keep identity, API access, and local permissions separate.
For integration applications, I address secure tokens, redirect flows, and the link between an external identity and local access rules.