Eliminate credential rotation with managed workload identity
Stop managing secrets and certificates for machine-to-machine authentication. Use the identity your platform already manages. Keycloak can participate in this model by trusting a federated workload identity and accepting a signed token as the client assertion instead of requiring the Keycloak client to hold a long-lived secret or certificate.
When applications authenticate using a client secret or certificate, the application owns a long-lived credential. That creates a lifecycle that must be managed:
Client secret: Protect and rotate.
Certificate: Protect the private key, monitor expiry, and rotate.
Rotation is necessary, but it adds operational work, risk, and the possibility of failure.
Eliminate the problem rather than process improvement
Modern cloud platforms can provide workloads with an identity that is managed by the platform. Managed workload identity eliminates the need for application-managed credentials and their rotation lifecycle.
With managed workload identity, the application does not store or manage secrets or private keys. The platform establishes the workload's identity and issues a short-lived signed token. The target identity provider or service validates that token and decides whether to issue or accept an access token.
The important architectural difference is that the workload does not possesses any long-lived authentication credential. Trust is based on the workload identity and short-lived tokens issued by trusted identity providers.
Why does this matter
No secrets to store, distribute, or rotate.
No certificate private keys to protect or certificates to renew.
Short-lived tokens reduce the impact of credential compromise.
Simpler operations and fewer credential-rotation failure modes.
Where supported, the architectural objective is simple: Remove the credential. Remove the rotation.
Managed identity across cloud platforms
The terminology differs between cloud providers, but the principle is the same: give the workload a platform-managed identity and use short-lived credentials or tokens instead of application-managed secrets.
Microsoft Entra managed identities
Azure resource obtains Entra tokens without storing application credentials.
IAM roles for workloads
Workloads such as EC2, ECS, Lambda, or Kubernetes use temporary role credentials instead of long-lived access keys.
Service accounts / workload identity federation
Workloads obtain short-lived credentials without maintaining service-account keys.
Service account / workload Identity
Pod identity can be federated with a cloud identity provider instead of embedding cloud credentials in the pod.
The implementation is different in each platform, but the architecture remains the same: the workload proves its identity through the platform rather than by presenting a long-lived credential that the application team must manage.
Keycloak as the target identity provider
Keycloak supports this architecture through federated client authentication. Instead of authenticating a machine-to-machine client with a Keycloak client secret or locally managed certificate, Keycloak can validate a signed assertion issued for the workload by a trusted external identity provider.
The result is the key architectural benefit: the Keycloak client no longer needs an application-managed credential. The workload obtains a short-lived identity token from its platform, presents it to Keycloak, and Keycloak validates the federated identity before issuing its own access token.
Azure example
Microsoft Azure implements this pattern through Microsoft Entra managed identities. Azure workloads can use system-assigned or user-assigned managed identities to obtain short-lived Microsoft Entra tokens without storing application credentials.
For an overview of secretless authentication with Microsoft Entra managed identities, see:
A practical implementation is Microsoft Entra User-Assigned Managed Identity (UAMI) with Keycloak.
The Azure workload obtains an Entra-signed JWT using its UAMI and presents that JWT to Keycloak as a federated client assertion. Keycloak validates the federated identity and issues its normal access token - without requiring a Keycloak client secret or application-managed certificate.
For the implementation steps, including the Entra application role, UAMI authorization, Keycloak Identity Provider configuration, and Signed JWT – Federated client authentication, see:
MS Entra ID managed identity for client credentialsLast updated