OAuth/OIDC in your tenant

Tenant management

Open OAuth Management in the tenant sidebar. Clients registers applications with a stable client ID, display name, client type, redirect URIs, enabled status, assigned scopes, the restrictScopes setting, and a consent choice. Scopes defines the access names available within the tenant. Access Token Management configures token format, lifetime, claim mapping, issuance policy, client assignment, and confidential client secrets. ID Token Management configures ID token signing, lifetime, and the claims in ID tokens and UserInfo responses. Key Management generates and rotates JWT signing keys. Metadata Management edits endpoint paths and custom discovery fields.

BTL administrators use the same controls under BTL Admin, OAuth Management for BTL's own organization. These pages always apply to BTL and do not offer a tenant selector. BTL access and tenant access are authorized separately.

New clients start disabled and restricted. Client type records whether an application can protect credentials. A confidential client needs a generated secret before it can authenticate to the token endpoint. The saved client name appears on the consent page. Consent can be requested every time, remembered for approved scopes, or skipped for a trusted client. Users still sign in when consent is skipped. When you create a client, Start from can fill in the usual settings for a web application, single-page application, native or desktop application, or machine-to-machine service; every setting stays editable before you save. Flow policy turns each grant, response type and response mode on or off independently, and a client can select only the choices Flow policy allows. A client keeps choices that Flow policy later turns off, but they are not used until Flow policy allows them again. Flow policy also sets the browser session and authorization code lifetimes within supported ranges.

In User Management, an administrator with the credential permission can set a tenant user's password. Share it privately. Setting a new password signs out that tenant user and revokes their existing OAuth tokens and pending codes. Tenant users do not use BTL administrator credentials.

Read the Scopes guide for configuration steps, access rules, and discovery behavior. Open Clients or open Scopes to manage a tenant you are authorized to access.

Token managers and defaults

Every client uses one access token manager and one ID token manager. In each management page, one enabled manager is marked Default. When you create a client, its manager selects start on the defaults, and you can choose another manager before saving. Choosing a manager other than the default, or changing a client's manager later, needs the assign permission for that kind of manager. Changing the default affects clients created afterwards; existing clients keep their manager. The default cannot be disabled or deleted until another manager becomes the default.

Each manager lists the standard claims for its token, such as sub, aud, and exp, filled in with their protocol values. You can set your own value as text, an attribute, or a JavaScript expression, and omit optional claims. aud also accepts a list, and an ID token's audience must still include the client ID. The issuer is always the tenant URL. In ID tokens, nonce, at_hash, c_hash, and azp are set by the protocol and cannot be changed, because they protect client applications against replay and token substitution. Required claims can be changed but not removed. Values are checked when a token is issued, and a value outside its allowed range stops issuance rather than producing a broken token.

Changing a claim changes what a token says, not how this service treats it. Expiry, revocation, granted scopes, introspection, and UserInfo always use the service's stored records.

OpenID Connect

Every tenant includes the built-in openid, profile, and email scopes. Their names are fixed and they cannot be deleted, but their description and common or exclusive access can change. A client granted openid receives an ID token signed by its ID token manager's key and published in the tenant's JWKS. Profile claims appear only when their scope is granted, and each claim can go to the ID token, the UserInfo response, or both.

The UserInfo endpoint, /oidc/userinfo by default, accepts an access token granted openid in the Authorization: Bearer header or a form body. Tokens in the query string are refused. Each successful UserInfo read is recorded in the tenant's protocol Audit.

Tenant users confirm their email address when they register or from their Security page. The default ID token manager does not include email_verified. The amr claim lists how the user signed in, for example pwd for a password, otp for a one-time code, hwk for a passkey, and mfa when more than one step was used.

Authorization requests accept nonce, prompt (none, login, or consent), max_age, and login_hint, which only fills in the email field. Request objects and the claims parameter are not supported. Subject identifiers are public: the same user has the same sub for every client unless a manager sets its own value.

Protocol availability

The token endpoint supports client credentials, authorization code redemption, and refresh when enabled by tenant and client policy. The authorization endpoint signs in tenant users, asks for consent according to the client setting, and returns a code, tokens, or both. Implicit and hybrid response types are off until a Tenant Admin allows the implicit grant and those response types in Flow policy and on a client. Their tokens are returned in the fragment or by form post, never in the query string.

Both /.well-known/openid-configuration and /.well-known/oauth-authorization-server describe the selected tenant's issuer, common scopes, endpoint paths, and available public signing keys. Administrators can move endpoint paths within the tenant URL, but cannot change the issuer or well-known metadata URLs.

Access tokens can be signed JWTs or opaque reference tokens. Authenticated confidential clients can introspect or revoke their own issued tokens. An endpoint URL in metadata is not a promise that every grant is available. Unimplemented protocol endpoints report their status rather than issuing credentials.