Presenters

Source

🚀 Bridging the Gap: How SPIFFE and Transaction Tokens Secure the Modern Cloud

In the fast-evolving world of cloud-native architecture, we face a persistent, nagging problem: how do we connect human identity (the user clicking a button) with workload identity (the microservices talking to each other)?

At a recent industry talk, Arndt Schwenkschuster (SPIFFE Maintainer and Standards Architect) and Dmitry Telegin (Keycloak contributor) unveiled a powerful solution. They demonstrated how to use SPIFFE and the emerging OAuth Transaction Tokens specification to create a secure, cryptographically verifiable chain of identity from the frontend all the way to the database.

🌐 The Two Worlds of Identity

Identity typically lives in two separate silos:

  1. User Identity: This is the realm of passwords, passkeys, and multi-factor authentication. It identifies Alice, the human user.
  2. Workload Identity: This is the realm of TPMs, Kubernetes service accounts, and SPIFFE. It identifies Service A, the software component.

The challenge arises when Alice triggers a request that must pass through a chain of services. How does the final service in the chain—say, a database—know that the request originally came from Alice and not an attacker impersonating her?

⚠️ The “Blast Radius” Problem

Arndt highlighted the common, yet dangerous, ways developers currently handle this:

  • Header Swapping: Services validate the token at the edge and then pass user details in plain JSON headers. The risk? If any service in the chain is compromised, an attacker can swap “Alice” for “Admin,” creating a massive global blast radius.
  • Token Forwarding: Passing Alice’s original access token from service to service. The risk? This breaks Sender Constraining (DPoP) and allows any service in the chain to impersonate the user elsewhere.
  • Token Exchange Ping-Pong: Every service exchanges the incoming token for a new one. While secure, this puts X times the stress on your authorization server and creates architectural “creep” where frontend choices infect the entire backend.

🛡️ The Savior: Transaction Tokens

Enter Transaction Tokens, a new format currently in the last call phase at OAuth. Unlike a standard access token, a transaction token is designed specifically to be forwarded.

Key Features:

  • Cryptographic Binding: It binds the transaction details (e.g., “Alice wants to buy 100 stocks”) so they cannot be altered mid-flight.
  • Not a Bearer Token: You cannot simply “use” a transaction token by holding it. You must also prove your workload identity.
  • TXN Claim: It replaces the standard JTI with a TXN (Transaction Identifier) to track the flow across services.

🦾 SPIFFE: The Foundation of Workload Trust

To make transaction tokens work, you need a way to identify the workloads. This is where SPIFFE shines. SPIFFE provides:

  • SPIFFE ID: A standardized URI format (e.g., spiffe://example.org/ns/prod/svc/billing) to identify workloads.
  • Workload API: A local API that workloads call to get credentials (X.509 or JWT) without needing pre-shared secrets.
  • Workload Attestation: SPIFFE doesn’t just believe a workload; it verifies it by checking Kubernetes pod metadata, Linux kernel info, or cloud provider labels.

Keycloak is currently the first and only identity provider to implement the upcoming standard for SPIFFE Client Authentication, allowing workloads to authenticate using their SPIFFE identities instead of fragile client secrets. 🛠️

👨‍💻 Real-World Demo: Keycloak + Tilt

Dmitry showcased a practical implementation of these concepts using a sophisticated local environment:

  • Tools Used: Keycloak (as the Authorization Server), Kubernetes (via Kind), Tilt (for rapid development), Quarkus (backend services), and React (frontend).
  • The Flow:
    1. A user authenticates via a vanilla Keycloak instance.
    2. The Edge Gateway receives the access token and performs a Token Exchange with a specialized Transaction Token Service (TTS).
    3. The gateway authenticates to the TTS using a SPIFFE JWT.
    4. The TTS returns a Transaction Token containing both the user context and the workload context.
    5. This token travels through the microservice chain via a dedicated TXN-Token header.

Dmitry praised Tilt as an eye-opening tool that allows for semi-declarative Python-based management of Kubernetes environments, making it perfect for testing complex identity flows. 🚀

❓ Audience Q&A: Clearing the Confusion

Q: Why is a transaction token not considered a bearer token? Arndt: Great question. We deliberately designed it this way so it wouldn’t just become “the next access token” that people forward recklessly. To use a transaction token, a service must authenticate itself. It is the combination of the Workload Identity (who you are) and the Transaction Token (what you are doing for the user) that grants access.

Q: When will this be natively in Keycloak? Dmitry: Currently, it exists as a powerful extension using Keycloak’s SPI (Service Provider Interface). While there is no official timeline for core integration, the project leads are enthusiastic. The more the community asks for it, the faster it will arrive!

✨ Final Thoughts

Bridging the gap between humans and workloads is no longer a luxury—it is a necessity for Zero Trust architectures. By combining the attestation power of SPIFFE with the purpose-built design of Transaction Tokens, developers can finally eliminate the “impersonation” risks that have plagued microservices for years.

If you are building in the cloud-native space, it is time to stop forwarding access tokens and start treating your transaction context with the cryptographic respect it deserves. 🔐🌐

Appendix