Scopes & claims
Scopes are what your client asks for in the authorization request; claims are the pieces of user data auth.is releases in return. auth.is supports the standard OIDC scopes, and — a deliberate choice — puts the resulting claims directly in the ID token rather than making you round-trip to userinfo for them.
Supported scopes
| Scope | Releases | Claims |
|---|---|---|
openid | The subject | sub |
profile | Basic profile | name, given_name, family_name, preferred_username, picture, updated_at |
email | Email address | email, email_verified |
offline_access | A refresh token | — (see below) |
openid is mandatory for any OIDC request. profile and email release the identity claims above. offline_access is not a data scope — it is the refresh-token gate. These four are the whole catalog in phase 1; there are no delegation or company scopes yet.
sub is the stable per-issuer user id — unique within the issuer, the same in every token you receive for that user. Because each issuer has its own user pool, subjects are naturally scoped per issuer; key your app's user records on (issuer, sub). See Users & identities.
Claims land in the ID token
auth.is includes the granted scope's claims in the ID token itself, instead of the strict OIDC default of stripping the code-flow ID token down to sub and forcing a userinfo call. So after a login most libraries read email, name, and the rest straight off the ID token:
{ "sub": "…", "email": "[email protected]", "email_verified": true, "name": "Ada", "updated_at": 1720000000 }
email_verified reflects whether the account completed email verification; updated_at is always present. Unrequested claims never leave the provider — the claim map is filtered to what the granted scopes (and any claims parameter) allow, and absent optional fields are omitted rather than sent as null.
The userinfo endpoint (/oidc/me) still works and returns the same scope-gated claims for the access token — handy for a backend that holds only an access token. But for a typical login you do not need it. The curl guide shows both: decoding the ID token and calling userinfo.
The claims in an ID token are only trustworthy once you have verified its RS256 signature against the issuer's JWKS and checked iss, aud, exp, and nonce. Reading the payload without verifying tells you what someone claimed, not what auth.is signed. A real OIDC library does this for you; the curl guide walks it by hand. See Signing keys for the JWKS behind the signature.
offline_access and refresh tokens
offline_access requests a refresh token, but it is honored only when both conditions hold: the client is allowed the refresh_token grant, and the authorization request also carries prompt=consent. Ask for offline_access without prompt=consent and you will get no refresh token. See Token lifetimes & refresh for how the refresh token then behaves.
Resource scopes for machine-to-machine
API access is a separate namespace from the OIDC scopes above. A resource server (an API) is defined in the issuer's settings with its own scopes (for example api:read, or mgmt). Those are never part of the global OIDC scope catalog — a plain userinfo token can never carry them.
To get one, a request must target a resource (an RFC 8707 resource indicator) whose issuer-scoped definition lists the scope. auth.is then mints a JWT access token signed with the issuer's keys, with the audience set to the resource URI, valid for that resource's configured TTL (default 1 hour). This is the M2M path — a client_credentials client, no user, calling a specific API.
Which resource scopes a given client may obtain is gated by its resource_scopes allowlist: for a closed resource, the granted scopes are the resource's declared scopes narrowed to what the client is allowed. (An "open" resource bypasses the per-client allowlist and gates on user consent instead.) A request with no resource indicator always yields an opaque userinfo token, never an API JWT.