How OIDC Token Propagation Fails Across Federated AI Clusters

Modern AI platforms have evolved beyond single‑application walled gardens. A user might begin in a central portal, provision a governed dataset, spin up a Jupyter notebook where that data lives, and then invoke an assistant that reaches out to services in a completely different cluster. The experience feels seamless, but every one of those hand‑offs pushes identity across control‑plane and data‑plane boundaries. The result is often silent token expiration, mismatched RBAC decisions, or the dreaded “authentication required” prompt at the worst possible moment.

The core issue isn’t just “single sign‑on” failing—it’s that OAuth 2.0 and OpenID Connect were designed for request‑response web flows, not for long‑running, cross‑cluster AI workflows. When a notebook in federated Kubernetes cluster A needs to call a model serving endpoint in cluster B, the OIDC token issued at login typically has a short lifespan and no built‑in mechanism for transitive trust. The token either gets rejected by the downstream cluster’s auth server, or it must be manually exchanged for a new one, which introduces both latency and a surface area for human error.

One concrete pain point: token introspection endpoints. Many Kubernetes‑based platforms expose a /oauth2/introspect or /oauth2/tokeninfo route, but these are rarely aggregated across federation boundaries. If cluster A issues a JWT signed with key X, cluster B’s API server may not have the public key in its trusted keyset, causing validation to fail. The fix usually involves either a centralized key management service (like HashiCorp Vault or AWS KMS) that all clusters can query, or configuring each cluster to trust a common JWKS URI. Both approaches add operational overhead that many teams underestimate until they’re debugging a 401 at 2 am.

Another detail that catches people off guard is how Kubernetes’ own service‑account tokens interact with external identity providers. When a workload runs as a service account, it relies on the node’s projected service‑account token. If that workload needs to act as a human user—say, to write results to a governed bucket—it must impersonate that user’s OIDC claims. Kubernetes can map the impersonate field in a request, but only if the API server is configured with --authorization-mode=RBAC and the impersonation user exists in the cluster’s password file or via an aggregator layer. Miss one of those prerequisites, and the impersonation silently falls back to the service‑account’s restricted scope.

A practical workaround many teams adopt is to avoid passing user tokens altogether and instead use API keys or short‑lived service‑account tokens with scoped permissions. For user‑centric workflows, though, the pattern that actually scales is