OIDC login
On top of OAuth2, the server exposes an OpenID Connect layer (src/Domain/OAuth/Oidc/) so apps get a
standard identity protocol: discovery, JWKS, and signed id_tokens. The base is MIT (steverhoades) —
never AGPL.
Motivation
OAuth2 issues access tokens (authorization). OIDC adds an identity token (id_token) and a standard
discovery document, so any OIDC-compliant client can log in against your server without bespoke wiring.
Discovery & JWKS
The provider publishes the standard endpoints at the application root:
curl https://iam.example.com/.well-known/openid-configuration
curl https://iam.example.com/.well-known/jwks.json
The discovery document advertises the authorization, token and JWKS URLs; clients fetch JWKS to verify
id_token and access-token signatures (ES256) offline.
The login flow
In a consuming app you do not implement this by hand — install
laravel-iam-client, which handles the redirect, the PKCE
exchange, JWKS verification and claim mapping, then exposes the authenticated user to your app.
Federated identities
A user can authenticate through an upstream provider; the link is stored in iam_federated_identities
(src/Domain/Identity/Federation/). Configure social/federated login by adding
Socialite (a suggest dependency) as the backend — the IdP records
which provider proved the identity and at what assurance level.
What’s in the id_token
The id_token carries standard OIDC claims plus the subject and the assurance level reached at
authentication, which the PDP can require step-up against. It is signed with the
same rotating ES256 keys as access tokens.
Next
- Sessions & step-up — revocable server-side sessions and AAL.
- OAuth2 clients & PKCE — the grant flows beneath OIDC.
- Assurance levels — how authentication strength feeds decisions.