No More Secrets With Keycloak's Federated Client Authentication
summary
Keycloak 26.6 adds federated client authentication so OIDC clients use Kubernetes service account tokens or SPIFFE SVIDs instead of stored secrets. The demo shows mounting the token in the pod, setting audience to the Keycloak issuer URL, and switching the client from client secret to a client assertion JWT, yielding zero secret management with automatic rotation. Keycloak validates via JWKS signature, audience match and service‑account→client subject mapping.
AI-written summary · about
chapters (10)
- 0:00Keycloak and federated auth intro
- 3:34Client auth scenarios
- 5:19Managing client secrets
- 6:43Federated auth in Keycloak 26.6
- 9:13Setting up federated client authentication with Kubernetes
- 12:24Auth flow with federated tokens
- 14:10Live demo: federated auth
- 18:32Config walkthrough
- 19:14Benefits and use cases
- 22:25Q&A
related talks
30mAdvancing Machine to Machine Workflows with the SPIFFE Identity Provider
36mSecuring Agentic Platforms with Zero-Trust Workload Identities
25mIdentities and Authentication for Your Agents With Keycloak
01h 03mSingle Sign On with Keycloak: why and how
27mMCPIdentity: Keyless MCP Agent Authentication Patterns on Kubernetes With Keycloak…
20mOpenID Federation Trust Chain on Keycloak for Highly Assured Use Cases of Digital I...
31mKubernetes OIDC That Works in Practice: Keycloak + RBAC + Kubelogin Without Day‑2 Pain
25mBridging the Gap Between Human and Workload Identity: SPIFFE Support in Keycloak