One login for every product your company runs.

Standard OIDC, with discovery

The platform publishes a discovery document at /.well-known/openid-configuration and a public key set at /.well-known/jwks.json, and exposes a userinfo endpoint.

Publishing JWKS is what lets your other systems verify a token independently. They fetch the public key and check the signature themselves, which means they never hold a shared secret of ours and a compromise on their side does not become a compromise on ours.

Authorization code flow with PKCE

Login uses the authorization code flow with PKCE, accepting a code challenge and method on the authorize request and requiring the verifier at the token exchange.

PKCE closes the interception window on the authorization code, which is the attack that made the implicit flow obsolete. It is the current recommendation for every client type rather than only for mobile.

Tokens are RS256 and short-lived

Access and ID tokens are signed RS256 against the published key set, carrying a key id so a key can be rotated without invalidating every token in flight. Access tokens are typed at+jwt.

Asymmetric signing is the reason a delegating product can verify a token offline. Symmetric signing would require distributing the signing secret to every relying party, which turns each of them into a place your identity system can be forged from.

Refresh rotation with reuse detection

Refresh tokens rotate on every use, and reuse is treated as theft. Presenting a refresh token that has already been redeemed revokes the entire token family rather than just the token presented.

That is the behaviour that makes a stolen refresh token containable. Without rotation, a leaked refresh token is a durable credential. With rotation and reuse detection, the attacker and the real user cannot both keep using the session, and the second attempt ends it for everyone holding that lineage.

Passwords and stored secrets

argon2id

Password hashing uses argon2id, the winner of the Password Hashing Competition. Legacy hashes from an earlier system are detected and transparently upgraded on the user's next successful login.

AES-256-GCM

Provider keys are sealed at rest with authenticated encryption and support key rotation, so the encryption key can change without re-encrypting every stored secret up front. API responses expose only the last four characters of a key.

Closed by default

Authentication is a global guard, and a route is public only when explicitly marked. A forgotten guard therefore fails closed instead of quietly exposing an endpoint.

Roles and per-product access

Access is role-based, and entitlements control which products a member may use. Removing someone once removes them from everything downstream, which is the operational reason to centralise identity in the first place.