OpenID Connect
OpenID Connect (OIDC) is the identity layer on top of OAuth 2.0. Where OAuth alone answers “can this client access this API?”, OIDC also answers “who is the user?” — by returning a signed ID token alongside the access token and standardizing how to fetch profile claims.
Faable Auth implements OpenID Connect Core 1.0 . Every tenant domain is a fully self-describing OIDC issuer, so any standard OIDC client library works out of the box.
Discovery
Each tenant publishes its configuration at the standard well-known URL:
GET https://your-tenant.faable.app/.well-known/openid-configurationThe document lists the issuer, the authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, end_session_endpoint, and the supported scopes, response types, and signing algorithms. Point your OIDC library at your tenant domain and it configures itself from here.
ID tokens and signing keys
ID tokens (and access tokens) are JWTs signed with RS256. The public keys are published at:
GET https://your-tenant.faable.app/.well-known/jwks.jsonKeys rotate automatically; each token’s kid header identifies the key that signed it, so libraries that cache the JWKS pick up rotations transparently. See Validate Access Tokens for how to verify tokens in your own API.
What’s supported
| Capability | Notes |
|---|---|
| Authorization Code Flow + PKCE (S256) | The recommended login flow — see OAuth 2.0 Flows |
| Discovery | /.well-known/openid-configuration per tenant |
| JWKS with key rotation | /.well-known/jwks.json, RS256 |
nonce | Replay protection for ID tokens |
prompt | none (silent check: login_required when nobody is signed in, interaction_required when the user still has a step to do), login (fresh sign-in). select_account shows the hosted account chooser (continue as the signed-in user, or use another account). consent is treated as login. |
max_age + auth_time | Force or measure re-authentication |
acr_values | urn:faable:loa:2 asks for a second factor on this login (step-up); the id token says which level was reached in acr. |
login_hint | Pre-fills the hosted login screen and is forwarded to social providers |
id_token_hint | A previously issued id token naming the user; a session for someone else is login_required under prompt=none, a fresh sign-in otherwise |
ui_locales | Forwarded to social providers |
| UserInfo endpoint | Claims gated by scopes (§5.4) |
| RP-Initiated Logout | id_token_hint, post_logout_redirect_uri |
| Dynamic Client Registration | RFC 7591 , POST /oidc/register |
Standard claims
Which claims end up in the ID token and the UserInfo response is controlled by the scopes you request at /authorize time — openid is required, and profile, email, phone, address unlock their claim groups. The full scope-to-claim mapping is documented on the UserInfo page.
Next steps
- OAuth 2.0 Flows — pick the right grant and obtain your first tokens.
- UserInfo Endpoint — fetch end-user profile claims with the access token.
- RP-Initiated Logout — sign users out and propagate it to relying parties.
- Validate Access Tokens — verify RS256 signatures against your tenant’s JWKS in your API.
Last updated on