AI
Why Modern Platforms Run Multiple Trust Domains
Modern applications span multiple Kubernetes clusters and clouds, often crossing organizational lines. Each environment authenticates and authorizes independently rather than relying on one central authority. AI agents now participate alongside human users as first-class participants. SPIFFE signing authorities issue workload identities; OAuth authorization servers issue tokens with scopes and claims. These two types of identity, workload identity and user authorization, operate as separate concerns across the system.
Token Forwarding Breaks at Domain Boundaries
SPIFFE solves workload-to-workload authentication. Trust bundles let workloads verify each other across domains without shared secrets. User authorization is harder. Forwarding an access token across a trust domain breaks audience constraints and makes it unclear where the authorization decision was made. Token exchange looks like a fix: change the audience, issue a new token. But it leaves the core question unanswered: why should the authorization server in domain B trust a token issued in domain A?
RFC 8693 and RFC 7523 Form the Foundation
The OAuth identity and authorization chaining across domains draft answers this by combining two RFCs. RFC 8693 defines token exchange; RFC 7523 defines JWT-based authorization grants. At a domain boundary, token exchange converts an upstream access token into a JWT intended for the downstream domain. That JWT is a cryptographically verifiable statement from the upstream authorization server. The downstream server verifies it, then issues its own access token. Authorization is reissued in each domain independently.
SPIFFE Authentication Identifies the Delegating Workload
Token exchange and JWT authorization grants cover what is delegated and for whom. One piece remains: which workload performs the delegation. Static client secrets do not scale and add operational risk. The OAuth SPIFFE client authentication draft solves this by letting the authorization server verify a SPIFFE workload identity (a SVID) instead of a shared secret. This makes it cryptographically explicit which workload is acting. Identity chaining covers the first two questions; SPIFFE-based authentication covers the third.
The Full Request Flow: Keycloak, SPIRE, and Two Clusters
The demo runs two Minikube clusters, each a separate trust domain, with Keycloak as the authorization server and SPIRE as the SPIFFE signing authority. A curl command gets an access token from Keycloak A using the authorization code grant. When the corby API in cluster A calls cluster B, an Envoy authorization filter exchanges the token for a JWT authorization grant, then uses that grant to get a new access token for domain B. Every OAuth request uses a SPIFFE JWT-SVID for authentication. No static secrets appear anywhere.
Q&A
Is Hitachi using this approach in production? The implementation is currently in an experimental phase; Tabata confirmed it works but has not yet been deployed to a production environment. ▶ 28:43
With 10 trust domains, do policies need to exist in all 10, and would a centralized OPA be simpler? Tabata acknowledged the point but clarified the demo’s scope: it covers only propagating authorization data and workload identity across domains, not the policy engine layer. Adding OPA or a similar engine is compatible but was intentionally excluded from this demonstration. ▶ 29:24
Notable Quotes
trust domain is strongly discouraged. Yoshiyuki Tabata · ▶ 4:57
What is being delegated? Yoshiyuki Tabata · ▶ 9:19
without manual secret distribution. Yoshiyuki Tabata · ▶ 8:28
Key Takeaways
- Forwarding access tokens across trust domains breaks audience constraints and should be avoided.
- RFC 8693 token exchange combined with RFC 7523 JWT grants lets each domain reissue authorization independently.
- SPIFFE SVIDs replace static OAuth client secrets, making the delegating workload cryptographically identifiable.
- Keycloak and SPIRE together implement the full identity chaining draft with no shared secrets.
About the Speaker(s)
Yoshiyuki Tabata is a senior OSS consultant at Hitachi with over a decade of experience in IAM, API platforms, and cloud-native security. As Tech Lead of CNCF TAG Security and Compliance, he shapes security guidelines and best practices across the cloud-native ecosystem. He is also a long-time contributor to Keycloak.