Description

Keycloak currently supports using JWTs for client authentication (client assertions). However, the client assertion has to be self-signed by the client and can not be issued by a 3rd party.

Supporting client assertions issued by a 3rd party would support federated client authentication. This opens up the door for the following use-cases:

• Enabling clients to authenticate with Keycloak using a Kubernetes Service Account
• Enabling clients to authenticate with SPIFFE JWT SVIDs
• Enabling clients to authenticate with Keycloak using credentials associated with a different IdP

A realm admin would first configure a trust relationship (identity provider) between a realm and an 3rd party that can issue client assertion tokens. Once configured clients can be configured to use federated JWT authentication and select the trust relationship (identity provider) and provide the external client id (subject claim value).

Value Proposition

Federated client authentication opens up the door for authenticating clients without credentials, or reducing the amount of credentials a client needs to handle.

Goals

• Support client assertions issued by 3rd party providers for OpenID Connect clients
• Support SPIFFE JWT SVIDs
• Support Kubernetes Service Accounts

Non-Goals

• Support X.509 authentication (SPIFFE X.509 SVIDs, SAML clients, etc.); at some point in the future we may introduce a concept of a certificate authority trust relationship to improve configuration of mTLS authentication for clients
• Support auto-registration or dynamic registration of clients; this will be a follow-up at a later point

Discussion

No response

Notes

Instead of adding a different concept of 3rd party trust in a realm this should be based on identity providers. This allows a single trust relationship to provide one or more aspects, as well as central management of trust relationships within a realm.

Requirements for client assertions:

• Must be a JWS signed with the keys from the identity provider
• iss must match identity provider issuer URL; required unless sub is a URI including the issuer
• sub claim must match the external subject configured for the client; if a URI (for example spiffe://trust-domain/workload-id) and no iss claim is present the scheme and authority is used as the iss value
• aud claim must be a single value equal to the realm issuer URL
• exp claim required; must be in the future
• nbf claim optional; if present must be in the past
• iat claim optional; if present must be a maximum of 300 seconds in the past
• jti required and must be unique if re-use is not permitted by identity provider; if re-use is permitted jti is optional