Bridging the Gap Between Human and Workload Identity: SPIFFE Support in Keycloak
summary
Keycloak 26.4 adds SPIFFE client authentication so workloads can use runtime SPIFFE identities instead of client secrets; a plugin implements a token-exchange-based transaction token flow that takes an external access token, authenticates the workload via SPIFFE, and returns a signed JWT with a TXN claim containing both workload ID and user context. Demo runs on kind with Tilt, two Keycloaks (external auth + transaction token service), an edge and services A→B, and uses a separate TXN header (not Authorization) so the token is forwardable but not a bearer access token.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:47What is SPIFFY
- 3:14Workload attestation
- 4:39Client auth standard status
- 6:07Transferring user identity
- 8:14Forwarding access tokens
- 9:41Token exchange limits
- 11:03Transaction tokens
- 12:31Demo client authentication
- 16:32Demo setup Tilt Keycloak
- 19:15Bridging identities
- 20:45SPIFFY resources events
- 21:36Q&A
related talks
36mSPIFFE: In Theory and in Practice
37mHow Does a Workload Authenticate an API Request?: Implementing Transaction Token...
36mSecuring Agentic Platforms with Zero-Trust Workload Identities
36mFederated Identity for Distributed Systems: Understanding SPIFFE
36mIntroducing SPIFFE: An Open Standard for Identity in Cloud Native Environments [I]
32mProduction Workload Identity with SPIRE
40mMulti-Cloud Workload Identity With SPIFFE
29mBridging the Great Divide: SPIFFE/SPIRE for Cross-Cluster Authentication