Configure the authorization server

The authorization server grants every token outside the anonymous public surface. This journey reads the servers provisioning created, adds or corrects a hosted server, and registers the confidential client that tenant automation uses.

Complete first: Onboard a tenant.

Steps and why they come in this order

Step	Why here
1. Review the tenant authorization servers	Provisioning already created the default server. Read it before creating another so you know which UUID clients and issuers should use.
2. Create and activate a hosted server	Clients and issuer bindings can only reference an active server, so creation and activation come before both.
3. Register clients	The confidential tenant client is what every later journey authenticates with, and wallet clients need exact redirects and PKCE.
4. Tune token and grant settings	Token lifetimes and grant policy only matter once clients exist, and the issuer relies on them for wallet grants.

What an authorization server is not

An authorization server is not the credential issuer. The issuer later binds an authorization server by UUID through an explicit binding, covered in Set up the credential issuer. Configure and activate the server first, then bind it.

Resource type	Use it when	Lifecycle
Hosted	The tenant operates the authorization and token endpoints	Create, configure, validate, activate, register clients
External	The tenant delegates to an existing upstream server	Create from discovery, validate, activate, refresh when it changes
Federation binding	A hosted server sends user authentication upstream	Create disabled, validate, enable; see the Keycloak journey

Deeper reference

Authorization-server configuration explains every option, the Admin Console screens (surface=as) and the Postman correlation.

Next journey

Continue with Federate wallet sign-in to Keycloak.