Authorization servers
The Authorization Servers area is the tenant administration entry point for hosted and external authorization-server resources. Every resource has a stable UUID. The console carries that UUID into lifecycle, configuration, federation, client, identity, migration, and credential-issuer operations. A slug remains part of the hosted route and runtime configuration namespace, but it is never an administration selector.
The platform tenant's built-in authorization server is isolated from this area. Open the console on a customer-tenant host or select a customer tenant before using these screens.
Concepts and ownership
The resource is the only lifecycle authority. Hosted runtime keys under oauth2.servers.<slug>.* are generated projections. External discovery snapshots describe an upstream server but do not create a second lifecycle. Federation bindings are explicit bilateral relationships from one hosted resource to one validated external OpenID Connect resource.
An external OAuth 2.0 resource can protect OID4VCI when its discovered grants and endpoints satisfy the issuer policy. Only an OpenID Connect capable resource can authenticate users through a hosted broker. External resources and federation bindings do not consume hosted authorization-server quota.
The area does not support manual discovery endpoint overrides, dynamic client registration, OpenID Federation trust chains, public secret locators, or wallet identity reconciliation.
Resource list and creation
The list shows each resource's deployment type, lifecycle, issuer, purpose, usage, revision, and discovery freshness. Choose Create authorization server to create one of two distinct resource types.
- A hosted resource runs on VDX and can use local, federated-only, or hybrid authentication. Creating or reactivating it checks the hosted authorization-server entitlement and quota.
- An external resource is discovered from its issuer. The issuer is its only discovery input. Creation reconciles OAuth and OpenID metadata and commits the resource only after the expected capabilities are proven. Activation remains a separate operation. It does not consume hosted authorization-server quota.
Opening a row uses its UUID. The overview exposes only valid lifecycle actions. A stale revision, invalid external discovery, unresolved dependency, or exhausted hosted quota produces a visible conflict and does not partially update the resource.
See Resource settings for creation, lifecycle, discovery, signing, and hosted configuration details.
Hosted configuration
The Configuration area reads and replaces the hosted configuration as one revision-guarded aggregate. It does not write individual oauth2.servers.<slug>.* keys as independent authorities. Those keys are generated runtime projection values.
Signing selects a tenant-visible KMS resource and key alias. The response contains only typed references. It never exposes private key material.
The existing feature and settings pages describe the hosted sections in detail:
Federation
The Federation area attaches validated external OIDC resources to one hosted resource. A binding owns its order, requested scopes, claims mapping, client-authentication method, and typed secret or KMS reference. Validate a binding before enabling it. Disabling it records DISABLED, so a later enablement requires fresh successful validation.
Upstream clients are provisioned by the operator. The console accepts a write-once secret or an existing typed reference and never returns raw credentials. Dynamic client registration is outside this release.
See Hosted sign-in and federation for the complete operating sequence and callback security model.
Clients and identities
The Clients area manages public and confidential clients on a hosted resource. Confidential creation accepts one write-once secret or a typed secret or KMS reference. Read responses are redacted. See Clients.
The Users area manages identity bindings on a hosted resource. Enabled state, the single assigned role, revision, and session-revocation decision are updated atomically. See Users.
Migration remediation
The Migrations view reads the durable tenant migration ledger. An unchanged failed source uses Resume migration with the observed revision and recorded digest. A changed source uses the separate audited Accept source change action with both ledger digests and an administrator reason. The console never reconstructs migration state locally or edits generated runtime configuration to conceal a failed conversion.
See Migration remediation for the ledger fields, compare-and-set behavior, and recovery sequence.
Credential issuer selection
Credential issuers bind to authorization-server resource UUIDs. Selection follows issuance template, credential configuration, then issuer default. The issuer area also exposes a profile compatibility dry run and an audited, idempotent profile apply. See Authorization-server selection and protocol profiles.
API reference
These screens use the tenant-scoped Platform Config surface under:
/api/platform/config/v1/tenants/{tenantId}/authorization-servers
/api/platform/config/v1/tenants/{tenantId}/authorization-server-migrations
/api/platform/config/v1/tenants/{tenantId}/oid4vci/issuers/{instanceId}
Use the Platform Config REST reference for the exact request schemas, revision fields, and response variants.
For operating failures, use the troubleshooting table in Hosted sign-in and external federation. For upgrade failures, use Migration remediation.