Issuers
An issuer is a full OpenID Connect provider on your team's *.auth.is subdomain. It has its own signing keys, its own user pool, its own federation providers, and its own theme. To your applications it is an ordinary, standards-compliant OIDC provider — the same thing you would point any OIDC library at.
Discovery and endpoints
Every issuer publishes an OIDC discovery document. It is the only URL your integration needs to hard-code; every endpoint is derived from it.
https://{slug}.auth.is/.well-known/openid-configuration
The endpoints it advertises:
| Purpose | Path |
|---|---|
| Authorization | /oidc/auth |
| Token | /oidc/token |
| Userinfo | /oidc/me |
| JWKS (public keys) | /oidc/jwks |
| End session (logout) | /oidc/session/end |
| Token introspection | /oidc/token/introspection |
| Token revocation | /oidc/token/revocation |
Supported scopes are openid, profile, email, and offline_access (the refresh-token gate). The response type is code — auth.is is authorization-code only, and PKCE is required for every client. See Scopes & claims in the curl guide for what each scope releases.
Tenant issuers do not advertise a registration_endpoint. Dynamic client registration exists only on the root issuer (login.auth.is) and is used by MCP hosts to self-register. Register your own applications with the MCP tools, not DCR.
Settings
An issuer carries a small settings bag you tune with update_issuer_settings (owner only):
| Setting | Meaning | Bounds |
|---|---|---|
registrationMode | open allows end-user self-signup (when a client also enables it); invite_only blocks self-signup entirely. | open | invite_only |
sessionTtlSeconds | How long a login session stays valid. | 300–2,592,000 (5 min – 30 days) |
passkeysDefaultEnabled | Whether new clients default to offering passkeys. | boolean |
registrationMode and a client's registration_enabled flag work together to allow self-signup — see Clients. Themes and resource servers live in settings too, but each has its own dedicated tool rather than going through this patch.
configVersion and instant invalidation
Every issuer has a configVersion integer. Any change that affects the running OIDC provider — a new client, a redirect-URI edit, a theme, a settings patch, a key rotation — bumps configVersion in the same transaction. The live IDP keeps a cache of provider instances keyed on (issuerId, configVersion); a bump invalidates it, so your change is live on the login pages immediately, with no restart. This is why every mutating tool tells you the change has already taken effect.
You never set configVersion yourself; it is the mechanism, surfaced so you understand why edits are instant.