Device code and client_credentials sign-in

Two additional grant types are now available on the default OIDC provider — the one Single sign-on with OIDC documents in full. This article covers what's specific to each; everything else about token lifetimes, error shapes and registration in that article still applies.

client_credentials

For an application acting as itself, with no person involved. Restricted to confidential clients only — a public client (one with no secret) requesting client_credentials is refused at registration, because there's nothing for it to authenticate the token request with. No id_token and no refresh_token are issued for this grant; you get an access token and nothing else, which matches the fact that there's no person whose identity or refreshable session this grant represents.

The same tenant-lifecycle checks that gate an ordinary sign-in (is the organisation active, and so on) are reused here, so a client_credentials token cannot be minted for a client belonging to a suspended or deleted organisation.

The device authorization flow

This is RFC 8628 — the flow you've used on a smart TV or a CLI tool: the device has no browser of its own (or one you don't want to use), so it displays a short code and asks you to enter it on another device that does have one.

1. The device calls POST /oidc/device_authorize (public — no session) and receives a device code, a short user-facing code, and a verification URL.
2. The device shows the user-facing code and tells the person to visit the verification URL.
3. The person, on their own browser, signs in if needed and calls POST /oidc/device/verify (authenticated — this is the console's verification screen) with the code, confirming the device's request.
4. Meanwhile, the device polls POST /oidc/token with grant_type=urn:ietf:params:oauth:grant-type:device_code. Once the person has confirmed, the next poll returns tokens.

Device codes are stored with the same pre-authentication identity-plane pattern used elsewhere for requests that can't yet carry an organisation-scoped session (the polling device has no session at all until the flow completes) — the same shape the push-authenticator tables and the custom-auth-server slug resolution use.

App-type presets, while you're registering a client

Registration now accepts an optional app_type field — web, spa, native or service — which applies a sensible preset for grant types, PKCE and the token-endpoint auth method for that kind of application, so you don't have to assemble the right combination by hand. This is a convenience on top of the registration form described in Registering an application for sign-in; nothing about the underlying rules changed. One clarification worth noting: plain PKCE (as opposed to S256) was already fully removed from this platform before this wave — only S256 has ever been accepted for some time — so if you've read anything suggesting plain PKCE is still an option here, that's stale.