Digital Sovereignty and the Case for Self-Hosted Identity

▶ Watch (1:00)

Digital sovereignty means owning your identity stack. When another provider can pull the plug on your identity system, you are not sovereign. Keycloak runs as a container connected to a database. Users authenticate with username, password, or passkeys. Keycloak issues short-lived tokens. Services verify those tokens directly or via introspection. Because Keycloak is open source, operators can steer its roadmap, not just consume what a vendor ships.

What Keycloak Added in the Last Year

▶ Watch (3:18)

Standard token exchange ensures every token carries the correct audience and a narrow scope. JWT authorization grants let a user authenticated in one IdP access applications in another, crossing trust boundaries without re-entering credentials. Two-factor recovery codes and passkeys are fully supported. FAPI 2.0 best practices are built in. OpenTelemetry traces now cover LDAP calls, so operators can see exactly where latency hides. Grafana dashboards ship with Keycloak and track login performance against service-level objectives.

Three Authentication Patterns: From Secrets to Service Account Tokens

▶ Watch (9:15)

The demo compared three patterns. First: client ID and secret. The app fetches the secret from config and exchanges it along with the authorization code for tokens. Second: client assertions. The pod presents the Kubernetes service account token that Kubernetes mounts automatically. No secret required. The app sends that token to Keycloak, which trusts it via a pre-configured Kubernetes identity provider. Third: machine-to-machine with grant type client_credentials. Same mounted token, no user in the picture.

Configuring Keycloak to Trust Kubernetes Service Accounts

▶ Watch (15:50)

Setting up federated client authentication requires two steps in the Keycloak admin console. First, add a Kubernetes identity provider with the cluster’s issuer URL and assign it an alias. Second, open the client’s credentials tab, select signed JWT federated, and enter that alias. Then bind the client to the specific application service account. Keycloak trusts tokens from that cluster only when the subject claim matches that account. Kubernetes rotates these tokens every ten minutes, which is the minimum interval the platform allows.

Keycloak 26.6: GA Features and What Comes Next

▶ Watch (21:29)

Keycloak 26.6, due end of March, promotes JWT authorization grants and federated client authentication from preview to fully supported. Workflows for user lifecycle management (deactivate accounts idle 30 or 90 days, automate onboarding) also go GA, with custom Java extensions for bespoke actions. Organization groups land for multi-tenant setups. Rolling updates get graceful restarts and better database failover timeouts. Envoy and Traefik users get correct MTLS header pass-through. Future versions target SCIM support, organization roles, and expanded MCP integration for non-human identities.

Q&A

Is Keycloak planning to issue SPIFFE/SPIRE identities natively? No. Keycloak consumes SPIFFE tokens for client authentication but has no plans to become a SPIRE server or issue SVIDs. ▶ 24:53

Can fine-grained admin permissions restrict access to a single organization? Not yet, but it is on the roadmap, and Schwartz noted multiple attendees are waiting for that feature. ▶ 25:25

Can Keycloak run outside Kubernetes? Yes. A recent user survey found roughly 50%, possibly two-thirds, of Keycloak deployments run outside Kubernetes, with full feature support including service account token login. ▶ 26:04

Can multiple Kubernetes clusters connect to one Keycloak instance? Yes, but each cluster must have a distinct issuer URL so Keycloak can differentiate tokens, and Keycloak must be able to fetch public keys from that URL. ▶ 26:30

Notable Quotes

when someone else can pull the plug to your identity system, you’re probably not as sovereign as you want to be. Alexander Schwartz · ▶ 01:06

It’s a great way of uh doing client authentication if your application is in the same cluster as your keycloak because everything works out of the box. Sebastian Łaskawiec · ▶ 17:42

we might eventually have more non-human users than users human users Alexander Schwartz · ▶ 24:04

Key Takeaways

  • Federated client authentication lets Kubernetes pods authenticate to Keycloak using mounted service account tokens with no static secrets.
  • JWT authorization grants enable cross-IdP user federation, letting a user authenticated in one identity provider access apps in another.
  • Keycloak 26.6 promotes both features from preview to GA, alongside user lifecycle workflows and organization groups.

About the Speaker(s)

Alexander Schwartz is a Principal Software Engineer at IBM and a full-time Keycloak maintainer and technical team lead. He contributes to open source projects at work and in his spare time, and previously worked as a software architect and IT consultant.

Sebastian Łaskawiec is a software engineer and open source advocate at Defense Unicorns, specializing in security, authentication, and authorization. He has deep expertise in Keycloak and the UDS Platform, with a focus on identity management for air-gapped environments.