Authorization server container

nexus.sphereon.com/edk-docker/enterprise-tenant-as:<enterprise-version> runs the tenant-facing OAuth 2.0 and OpenID Connect protocol endpoints. Platform operator sign-in remains isolated in the platform service. Tenant authorization servers are administered as UUID-addressed resources through the platform configuration API.

An authorization-server resource has one deployment model:

• HOSTED is operated by VDX. It can authenticate locally, through validated upstream OpenID Providers, or through both routes. Hosted resources consume the authorization-server entitlement and quota.
• EXTERNAL represents an independently operated OAuth 2.0 or OpenID Connect server. It can protect OID4VCI flows when its validated metadata supports the selected grant. It can authenticate users only when OpenID Connect is validated and an enabled federation binding attaches it to a hosted resource. External resources do not consume hosted-server quota.

The platform tenant's built-in authorization server is not managed through this tenant resource API.

Protocol endpoints

The container serves the OAuth 2.0 and OpenID Connect endpoints published in the resource's metadata, including authorization, token, discovery, JWKS, user-info, device authorization where enabled, and RP-initiated logout. Public URLs come from the tenant's governed endpoint binding. The runtime does not infer an issuer or callback origin from an arbitrary request host.

OID4VCI uses the selected authorization-server resource for authorization-code, pre-authorized-code, or supported machine grants. The issuer resolves UUID bindings to issuer identifiers when it publishes metadata or creates an offer. See OID4VCI authorization-server selection.

Administration API

The canonical collection is:

/api/platform/config/v1/tenants/{tenantId}/authorization-servers

Resource IDs are stable UUIDs. Slugs remain display and routing attributes, but they are never accepted as resource selectors. The removed /oauth2/as/instances, /api/services/v1/oauth2/servers, and platform-admin federation-provider APIs have no aliases, redirects, or compatibility readers.

The resource API covers:

• hosted and external resource CRUD and lifecycle operations;
• external discovery validation and refresh;
• hosted aggregate configuration and typed KMS signing references;
• nested federation bindings, ordering, validation, enablement, disablement, and operator-provisioned typed client credentials;
• public and confidential hosted clients, including write-once secrets and typed secret or KMS references;
• hosted identities and their activation, suspension, role, and password-action flows;
• migration-ledger inspection and the separate resume and audited source-change-acceptance operations.

All replace and lifecycle operations use the resource or aggregate revision required by their request contract. A stale revision returns a conflict and does not partially mutate state.

External discovery

External registration accepts an issuer, expected capabilities, purposes, usages, and an allowed grant subset. Manual endpoint overrides are not accepted.

Validation fetches RFC 8414 authorization-server metadata and OpenID Provider Configuration when available. It reconciles the issuer and shared endpoints, validates the expected capabilities, and records the validated snapshot, source URLs, digest, freshness, supported grants, client-authentication methods, UserInfo endpoint, and registration endpoint when advertised. The callback uses the persisted UserInfo endpoint and rejects a response whose sub differs from the validated ID Token subject. The registration endpoint is retained as discovery evidence; this release does not expose dynamic client registration.

Discovery transport rejects redirects, untrusted TLS, local or private destinations, DNS rebinding, oversized responses, unsupported algorithms, contradictory metadata, and issuer mismatches. A stale, invalid, or unavailable snapshot cannot be used to activate an external resource or enable a federation binding.

Hosted authentication routes

A hosted resource has one authentication mode:

• LOCAL_ONLY renders local authentication.
• FEDERATED_ONLY redirects when exactly one eligible upstream binding exists and presents a chooser when several exist.
• HYBRID presents local authentication and the eligible upstream choices.

The route decision belongs to the downstream authorization transaction. prompt=none never renders login or a chooser. It continues an eligible existing session or returns the correct OAuth protocol error to the registered redirect URI.

An upstream round trip uses independent state, nonce, and PKCE. The callback validates tenant, hosted resource, binding revision, exact upstream issuer, ID Token signature, audience, authorized party, nonce, timestamps, and endpoint origin before it resumes the downstream transaction. Replay, tenant substitution, binding substitution, issuer substitution, and mix-up attempts fail closed.

Successful authentication produces normalized evidence with the hosted resource ID, optional federation-binding ID, upstream issuer and subject, local linked subject, assurance data, authentication time, governed claim provenance, transaction references, and policy revisions. Raw tokens, authorization codes, client secrets, and unrelated upstream claims are not copied into the evidence.

Federation bindings

A federation binding is owned by one hosted resource and points to one validated external OpenID Connect resource. It owns ordering, scopes, claim mapping, client authentication, typed credential references, enablement, validation status, and revision.

Create bindings disabled. Validate a binding against the current discovery snapshot and its credential method, then enable it through the dedicated lifecycle operation. Editing a binding does not enable it. Disabling records DISABLED; re-enabling requires a current successful validation rather than reusing an old result.

Raw upstream client secrets are write-once. The service writes the value through tenant secret management and persists only the opaque typed reference. Private-key JWT stores a typed KMS resource handle and key alias. Configuration reads never return secret material.

Clients and identities

Hosted clients are nested below the authorization-server UUID. Public clients use credential-free authentication methods. Confidential clients use a write-once secret value, an existing typed secret reference, or a typed KMS reference for private-key JWT. Secret replacement and deletion retain the internal secret record version so the previous exact version can be retired through the durable purge outbox. Responses return only approved references.

Hosted identities are also UUID-scoped. Roles and enabled state are authority on the application binding and update together under revision control. Session revocation is recorded durably with the identity mutation so a failed downstream revocation cannot leave an untracked active session.

Signing

Hosted signing configuration stores only typed KMS coordinates. It never stores private key material. Key rotation and JWKS publication follow the tenant KMS lifecycle, allowing current and permitted previous public keys to remain verifiable during an approved rotation window.

Persistence and migration

Authorization-server resources, discovery snapshots, expected capabilities, federation bindings, OID4VCI issuer bindings and profiles, hosted configuration, signing references, clients, identities, migration ledgers, audits, and outboxes are persisted in the service catalog. Fresh schemas and upgrade migrations exist for PostgreSQL and MySQL.

The enterprise migration orchestrator converts previous hosted configuration and tenant IdP records before runtime transports open. It uses a tenant and migration-version lock, deterministic UUIDs, a durable ledger, revision checks, and a completion marker. Previous tenant IdPs become suspended, disabled, unbound external resources and require explicit administrator review.

Resume is allowed only for a failed ledger entry with the same recorded source digest. A changed source uses a separate audited acceptance operation with the recorded digest, observed digest, expected revision, authenticated actor, and reason. Neither operation fabricates missing source data or silently accepts drift.

Runtime and operations

The image runs as a non-root user on port 8080. Deployment configuration supplies tenant resolution, endpoint bindings, database routing, KMS and secret-management providers, service authentication, and license integration. Administrative routes require the deployment's configured operator or tenant-administrator authorization.

Monitor these boundaries:

• discovery freshness and validation failures;
• federation binding revisions and upstream availability;
• KMS signing latency and key health;
• secret purge, session revocation, profile audit, and cache invalidation outboxes;
• migration ledger failures and source-digest changes;
• authorization transaction replay, expiry, and protocol error rates.

Do not treat container health as proof that an authorization route works. Release verification exercises local, single-upstream, multiple-upstream, hybrid, prompt=none, OID4VCI selection, client and identity administration, migration remediation, and profile upgrade flows against distributed Compose, monolith Compose, and Helm deployments.

For the operator workflow, continue with Hosted sign-in and external federation and the onboarding walkthrough.