Federate wallet sign-in to Keycloak
Use this optional journey when holders must sign in at an existing Keycloak realm before issuance. A separate hosted proxy authorization server federates the authorization-code flow to Keycloak, so the tenant default server stays local only.
Complete first: Configure the authorization server.
Steps and why they come in this order
| Step | Why here |
|---|---|
| 1. Review servers and federation bindings | The proxy must be a separate server. Read the current servers and bindings first so you do not federate the tenant default server by mistake. |
| 2. Create the proxy and the Keycloak resource | A federation binding joins two resources, so the hosted proxy, its wallet client and the external Keycloak resource must exist and be active first. |
| 3. Create, validate and enable the federation binding | The binding only becomes useful once both sides are active, and it is created disabled so nothing routes through it before validation. |
| 4. Bind the proxy to the issuer | The issuer only offers the proxy once it is bound, and a credential-level override decides which configurations route through Keycloak. |
Modes
authenticationMode lives on a hosted server. LOCAL_ONLY stays the default for the tenant server.
The proxy uses FEDERATED_ONLY: with exactly one enabled federation binding, an authorization request
redirects straight to Keycloak. HYBRID shows local and federated choices together.
This is not the Auth Bridge, which lets Keycloak call into an OID4VP verifier. Here Keycloak authenticates the user and the hosted proxy issues the wallet token.
Deeper reference
Keycloak wallet proxy describes the wallet-facing
protocol steps after configuration. Hosted sign-in and external federation
explains the Postman folder 03 / 09 Keycloak wallet proxy.
Next journey
Continue with Use the Developer Console.