Authorization-server configuration
An authorization server (AS) is the OAuth/OIDC control plane used by a wallet, application, or credential issuer. It is not the credential issuer itself. This guide explains the options that affect an AS resource and the order in which those options become usable.
Audience: tenant administrators and developers automating tenant configuration.
Prerequisites
Complete these guides first:
- Developer journey and authentication boundaries —
obtain a tenant confidential-client token. AS administration uses
tenantAccessToken; it never uses the platform operator token or a wallet token. - Tenant provisioning and confidential-client access — create or select the tenant and record its tenant id, subdomain, and hosted AS URL.
- Credential designs and claims — when the AS will be used by an issuer.
- Issuer configuration — complete this after the AS exists when you need to bind an AS to an issuer. The issuer and AS are separate guides.
Choose the resource type
| Choice | Use it when | Lifecycle |
|---|---|---|
| Hosted | The tenant operates the authorization endpoints and token service | Create, configure metadata, activate, register clients and identities |
| External | The tenant delegates authorization to an existing upstream server | Create from discovery, validate, refresh when it changes, activate |
| Federation binding | A hosted server must trust or consume an external federation provider | Create disabled, validate, enable only after validation succeeds |
A hosted AS is enough for the normal developer journey. Do not create an external resource merely because a credential issuer exists; the issuer selects an AS later through an explicit binding.
Hosted AS options
| Option | Meaning | Guidance |
|---|---|---|
displayName | Human-readable operator label | Keep it stable; it is not an API identifier. |
slug | Hosted route and discovery namespace | Use a DNS-safe stable value. Changing it changes public URLs. |
| public origin | URL in discovery and token claims | Use the tenant public HTTPS origin, never an internal service URL. |
| metadata | Advertised endpoints, scopes, grants, and capabilities | Replace only when the deployment supports the advertised behavior. |
| status | Draft, active, suspended, or decommissioned | Activate only after metadata and signing material validate. |
| default | Whether this is the tenant’s default hosted AS | Keep exactly one default for the normal journey. |
The create response returns the administration UUID. Use that UUID in every later API path; never reconstruct it from the slug or issuer URL.
Client options
| Client type | Typical use | Options that matter |
|---|---|---|
| Public | Browser or native app that cannot protect a secret | Client id, redirect URIs, response/grant types, scopes, and PKCE requirements. |
| Confidential | Backend service or Postman automation | Client id, authentication method, grants, scopes, redirect URIs, and a write-only secret. Store the secret immediately. |
| Operator/platform client | One-time administrative sign-in | Keep it separate from the tenant confidential client and never reuse it for tenant APIs. |
For this journey, register one confidential client on the tenant hosted AS and use its
client_credentials secret to obtain tenantAccessToken. This is the hand-off from bootstrap login
to repeatable API work.
Identity and external-discovery options
Hosted identities choose the account email/name, activation flow, role or group mapping, and enabled state. Activation is temporary bootstrap state; it does not replace the tenant service token.
External resources choose a public HTTPS discovery/issuer URL, client authentication metadata when needed, accepted scopes/grants, refresh policy, and activation state. Inspect the resolved issuer, authorization endpoint, token endpoint, supported grants, algorithms, and JWKS before activation. An HTTP 200 from discovery alone is not validation.
Federation bindings choose the provider, order, enabled state, and validation snapshot. Create them disabled, validate, and enable only if validation names the expected provider. Revalidate after any provider or discovery change.
Admin Console
Open Protocols > Authorization Servers. Work through the resource tabs in this order: Details, Metadata or Discovery, Clients, Identities, Federation, Validation, and Activation. The console should show the same UUID and effective values returned by REST. If a field is not visible, inspect the REST representation before assuming a default.
REST API
Use the tenant-scoped platform configuration API with tenantAccessToken:
POST .../authorization-serverscreates hosted or external resources.GETandPUT .../authorization-servers/{id}read or replace metadata.POST .../{id}/validate,.../{id}/discovery/refresh, and.../{id}/activaterun lifecycle steps.POST .../{id}/clientsregisters public or confidential clients.POST .../{id}/identitiescreates hosted identities, followed by one-time account actions.- Federation endpoints create, validate, enable, reorder, or delete bindings by UUID.
- Issuer binding endpoints select this AS for an issuer; they do not configure the AS.
Carry forward response-derived ids, revisions, client ids, and write-only secrets. Use revision/CAS
fields where provided. Management endpoints require tenantAccessToken; public discovery, metadata,
JWKS, and authorization endpoints do not carry a management bearer token.
Postman correlation
In the canonical EDK Enterprise collection,
run 09 Authorization Server Configuration. It is intentionally separate from
10 Issuer Configuration:
09owns AS resources, clients, identities, federation, activation, and issuer bindings.10owns issuer identity, credential configurations, signing, and status references.04 Tenant Service Tokenmust run first and storestenantAccessToken.
Run 17 Register confidential hosted client with write-only secret to reproduce the bootstrap-to-
service-token hand-off manually. The request descriptions link back to this guide.
Binding an AS to an issuer
Configure and validate the AS first, then bind its UUID from the issuer. The effective selection order is credential-configuration override, issuer override, then issuer default. If a credential uses the wrong token endpoint, inspect those three levels and the published issuer metadata before changing URLs.