You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal: Outbound federated client authentication for identity brokers
#53617
Federated client authentication (#42634) lets clients authenticate to Keycloak with tokens from a trusted Kubernetes, SPIFFE or OIDC identity provider. The opposite direction still requires a secret. When Keycloak brokers to another OIDC provider, including another Keycloak realm, it authenticates to that provider's token endpoint with client_secret_* or a realm-signed private_key_jwt.
We suggest closing that gap as part of the move towards identity providers as trust relationships with capabilities (#43486).
Proposal
Add a capability to the Kubernetes and SPIFFE identity providers: issue Keycloak's own workload identity. Add a client authentication method to OIDC identity providers: federated assertion, which references such an identity provider. When brokering, Keycloak obtains a token through the referenced trust and sends it as an RFC 7523 client_assertion instead of a secret.
This is the same trust relationship used in both directions. A Kubernetes identity provider already authenticates service accounts to Keycloak, and with this capability it would also give Keycloak a service account token to present to others.
Rules for the token:
Audience = the receiver's issuer identifier, as draft-ietf-oauth-rfc7523bis requires. One token per receiver, exactly one audience, checked before sending.
The token endpoint comes from that issuer's metadata (RFC 8414), so audience and destination are bound together. A realm admin can't send a token minted for receiver A to another host. Without that binding, the token could be replayed at A.
Server-level restrictions only where needed. The service account used for a realm is derived by the server configuration, not chosen by the realm admin, so one realm can't present another realm's identity. Receivers with a non-standard audience (e.g. Entra ID's api://AzureADTokenExchange) need an explicit audience-to-endpoint binding in the server configuration. Everything else needs no extra configuration.
This follows the IETF WIMSE workload identity practices: short-lived, pod-bound tokens, one per receiver, never the Kubernetes API token, and no credential locations derived from realm input. Keycloak's receiving side already enforces the matching rule, since federated client authentication accepts only the realm issuer as the audience.
All token requests from a broker go through AbstractOAuth2IdentityProvider#authenticateTokenRequest, so code exchange, refresh, introspection and the brokering token-exchange paths are covered in one place.
Testing
Keycloak-to-Keycloak brokering on a kind cluster tests everything automatically, with no cloud account: realm A brokers to realm B, the Kubernetes identity provider supplies A's token, and B validates it with the existing federated client authentication. Nothing in the mechanism is vendor-specific.
Milestones
Kubernetes identity provider issues Keycloak's own token (TokenRequest, pod-bound, short-lived). OIDC identity providers get the federated-assertion client authentication, with the audience and endpoint derived from issuer metadata. Keycloak-to-Keycloak test on kind.
Server-level audience-to-endpoint bindings for receivers with non-standard audiences.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Federated client authentication (#42634) lets clients authenticate to Keycloak with tokens from a trusted Kubernetes, SPIFFE or OIDC identity provider. The opposite direction still requires a secret. When Keycloak brokers to another OIDC provider, including another Keycloak realm, it authenticates to that provider's token endpoint with
client_secret_*or a realm-signedprivate_key_jwt.We suggest closing that gap as part of the move towards identity providers as trust relationships with capabilities (#43486).
Proposal
Add a capability to the Kubernetes and SPIFFE identity providers: issue Keycloak's own workload identity. Add a client authentication method to OIDC identity providers: federated assertion, which references such an identity provider. When brokering, Keycloak obtains a token through the referenced trust and sends it as an RFC 7523
client_assertioninstead of a secret.This is the same trust relationship used in both directions. A Kubernetes identity provider already authenticates service accounts to Keycloak, and with this capability it would also give Keycloak a service account token to present to others.
Rules for the token:
api://AzureADTokenExchange) need an explicit audience-to-endpoint binding in the server configuration. Everything else needs no extra configuration.This follows the IETF WIMSE workload identity practices: short-lived, pod-bound tokens, one per receiver, never the Kubernetes API token, and no credential locations derived from realm input. Keycloak's receiving side already enforces the matching rule, since federated client authentication accepts only the realm issuer as the audience.
All token requests from a broker go through
AbstractOAuth2IdentityProvider#authenticateTokenRequest, so code exchange, refresh, introspection and the brokering token-exchange paths are covered in one place.Testing
Keycloak-to-Keycloak brokering on a kind cluster tests everything automatically, with no cloud account: realm A brokers to realm B, the Kubernetes identity provider supplies A's token, and B validates it with the existing federated client authentication. Nothing in the mechanism is vendor-specific.
Milestones
Questions
We could help with this, if it's a direction you'd like to take.
All reactions