Modern AI platforms are no longer a single application behind one login screen. A user may start in a central portal, open a governed dataset, launch a notebook where that data resides, and invoke an assistant that calls services in another cluster. The workflow feels unified, but identity crosses control-plane and data-plane boundaries at every step. That is where conventional single sign-on (SSO) stops being enough.
SSO proves the user at the front door. Platform teams who manage a federated data or AI platform across multiple clusters still need a reliable way to carry that user context into distributed execution environments without handing raw tokens to every application, weakening revocation, or forcing each cluster to reimplement identity-provider logic.
This challenge is especially important for AI and data platforms, where data and compute often stay close to where they are produced, stored, or governed. Workloads may run in regional clusters, separate cloud accounts, on-premises environments, or specialized execution planes. Users still expect one platform experience across notebooks, catalogs, query tools, dashboards, and AI assistants.
This post describes a central identity gateway pattern for propagating user identity across those federated data planes. A central gateway owns the platform session. Data-plane gateways validate that session through a shared API and convert it into trusted local identity context for downstream applications. The pattern uses standard OpenID Connect (OIDC), a shared session store, stateless data-plane gateways, and a small identity-validation API that services can trust.
At NVIDIA, this approach reduced repeated login events by 55% across internal developer platforms spanning Kubernetes clusters in AWS and OCI. More importantly, it created a reusable foundation for unified platform shells, consistent logout, lower upstream identity-provider load, and AI assistants that can act with delegated user identity across data planes.
Where SSO ends and data-plane identity begins
The implementation details will vary by organization, but the core design is broadly applicable to platform teams running federated Kubernetes environments, multi-cloud data platforms, machine learning workbenches, internal developer portals, or AI application stacks with multiple authenticated tools. SSO gives users one entry point.
Federated data platforms still need a way to carry identity into the planes where work executes. A notebook in one cluster, a catalog API in another, and an assistant calling a query engine in a third all need the same answer: Who is the user, and what are they allowed to do here?
Without a shared identity propagation model, several problems appear:
- Control-plane authentication doesn’t automatically become trusted data-plane identity
- Raw token forwarding expands credential exposure and makes it harder to reason about who can use which token where
- Each data-plane gateway may integrate with the identity provider differently, creating inconsistent claims, refresh behavior, and audit records
- Logout and revocation may not propagate quickly across every cluster or execution plane
- New applications inherit identity plumbing instead of consuming a standard platform contract
For users, the symptom may look like repeated login prompts. For platform engineers, the deeper issue is distributed token propagation: identity created at the control plane must be transformed into trusted, scoped, auditable context at each data plane.
That model works for a small number of applications, but it creates structural problems as the platform expands:
- Sessions are scoped to where they were created. A token issued by one gateway is unknown to another, so users authenticate per service instead of per platform
- Logout is local. Signing out of one tool can leave active sessions elsewhere, creating both user confusion and security risk
- Token refresh is uncoordinated. Every gateway independently negotiates refresh cycles with the upstream identity provider, increasing load and creating divergent session states
- Identity context is inconsistent. Downstream services often parse tokens differently or duplicate authentication logic
- New services inherit old complexity. Adding another tool usually means rebuilding the same auth integration again
For platform users, the symptoms are repeated login prompts and inconsistent behavior. For platform engineers, the deeper issue is that session ownership is distributed across components that should only be enforcing access, not owning identity state.
Comparing two identity patterns
There are two common ways to structure identity in a federated platform.
The first pattern is distributed session ownership. Each service gateway owns its own login flow, session store, token refresh logic, and logout behavior. This keeps each cluster independent, but it also means the identity state does not move cleanly across the platform.
The second pattern is centralized session ownership. A dedicated identity gateway owns login, session state, refresh, and logout. Regional gateways remain in place, but they delegate session validation to the central identity gateway and focus on request enforcement.
| Design choice | Distributed session ownership | Centralized session ownership |
|---|---|---|
| Login experience | Users may log in once per tool or gateway | Users log in once per platform session |
| Logout behavior | Local to a service or cluster | Platform-wide through one session record |
| Token refresh | Repeated independently by each gateway | Coordinated by the central gateway |
| Upstream IdP load | Scales with users, tools, and clusters | Scales primarily with active users |
| Downstream identity | Often duplicated or inconsistent | Standardized through trusted headers or claims |
| Operational model | Simple at first, harder at scale | Requires central service, simpler for new tools |
Table 1. Comparison of distributed and centralized session ownership across login, logout, token refresh, identity propagation, and operational scaling.
Centralized session ownership is not required for every application. It becomes valuable when users move across multiple tools, clusters, or regions as part of one workflow and expect those tools to behave like a single platform.
The central identity gateway pattern
The central identity gateway owns three responsibilities:
- Session creation: handling the OIDC authorization code flow and creating a platform-wide session
- Per-request identity validation: answering “who is this user?” for any gateway or trusted service
- Session lifecycle management: coordinating token refresh and logout across the platform
Regional authentication gateways remain in place. They still enforce per-cluster policy, protect local services, and inject identity into requests. What changes is where sessions live.
Instead of storing sessions inside each regional gateway, the central identity gateway writes every authenticated session to a shared store such as Redis. The session is keyed by an opaque session ID and associated with a secure, HTTP-only browser cookie scoped to the platform domain.
On each request, a regional gateway calls an identity-validation endpoint such as /gateway/userinfo. The central identity gateway checks the session store and returns trusted identity claims. The regional gateway then injects a standardized set of identity headers before forwarding the request to the application.
Applications no longer need to parse tokens, refresh credentials, or integrate directly with the identity provider. They consume identity from a consistent interface.
Request flow
The pattern has three primary flows: login, validation, and logout.
Login
When a user arrives without a valid platform session, the regional gateway redirects the browser to the central identity gateway. The central gateway runs the OIDC authorization code flow against the organization’s identity provider, exchanges the authorization code server-side, stores the resulting session in Redis with a defined time-to-live, and sets an HTTP-only session cookie.
That session cookie becomes the user’s platform credential for the rest of the session.
Per-request validation
On subsequent requests, the regional gateway sends the session cookie to /gateway/userinfo. The central identity gateway performs a session lookup and returns identity claims such as user ID, email, groups, roles, and session metadata.
The regional gateway uses those claims to inject trusted identity headers. Downstream services read the headers and apply local authorization logic where needed.
This keeps the request path lightweight. A normal request does not require an OIDC exchange or a direct call to the identity provider. It requires a session lookup and a trusted gateway-to-gateway validation call.
Token refresh and logout
When an access token nears expiry, the central identity gateway refreshes it using the stored refresh token and updates the session record. Because the refreshed state is written to the shared store, every regional gateway observes the same session state.
For logout, the central identity gateway deletes the session record. On the next request, every regional gateway sees an invalid session and denies access or redirects the user to login. Logout becomes immediate and platform-wide.
What developers can reuse
The specific infrastructure behind the NVIDIA implementation is internal, but the architecture pattern is portable. External platform teams can reuse the following pieces:
- A single session owner for the platform
- A minimal validation endpoint, such as /gateway/userinfo
- Stateless regional gateways that delegate validation
- A shared session store with explicit TTLs
- Standardized identity claims or headers for downstream services
- A single logout path that invalidates the shared session
- A migration model that moves one gateway or service at a time
The pattern doesn’t require proprietary middleware. It can be implemented with standard OIDC libraries, Redis or another low-latency session store, and gateway integrations available in common Kubernetes ingress or service-mesh environments.
Security and reliability guardrails
Centralizing session ownership simplifies the platform, but it also makes the identity gateway a critical service. Teams adopting this pattern should design for failure, trust boundaries, and auditability from the beginning.
Use secure service-to-service authentication between regional gateways and the central identity gateway. Mutual TLS, workload identity, or signed internal tokens can prevent untrusted callers from using the validation endpoint.
Strip inbound identity headers before injecting trusted ones. Applications should only trust headers added by the gateway layer, not headers provided by a client request.
Store only what the platform needs in the session record. Apply short access-token lifetimes, explicit session TTLs, refresh-token protection, encryption in transit, and appropriate access controls around the session store.
Define failure behavior deliberately. Some platforms should fail closed, denying all requests if the identity gateway or session store is unavailable. Others may need short-lived cached validation for resilience. That decision should be explicit and aligned with the platform’s risk model.
Log validation, refresh, and logout events. Centralization makes it easier to produce a reliable audit trail showing who accessed which services and when their session changed.
Reducing load on upstream identity systems
One less obvious benefit of centralized session ownership is reduced load on upstream identity infrastructure.
In a distributed model, each regional gateway can call the identity provider, token secret store, and authorization policy engine independently. When a user moves across three tools, the platform may perform three separate token exchanges, three independent refresh paths, and three policy evaluations.
With a central identity gateway, the identity provider is called once per login. Regional gateways validate against the shared session instead of repeating the OIDC flow. Token refresh is coordinated by one service, and cached authorization context can be reused until it expires.
As the number of clusters and tools grows, upstream identity load scales closer to the number of active users rather than the number of user-tool-cluster combinations. This distinction becomes important in platforms that embed many tools into one workflow.
Enabling unified AI and data workflows
Centralized identity also enables higher-level platform capabilities.
A unified platform shell can embed multiple tools, and assistants behind one login. Each embedded application still validates requests through the gateway layer, but the user experiences a single authenticated platform.
AI assistants benefit from the same model. A platform assistant often needs to query data, retrieve metadata, call tools, and summarize results on behalf of the user. With centralized session validation, the assistant can resolve the user’s identity through the platform session and pass trusted identity context to backend tools.
That means the assistant does not need broad service credentials or separate per-tool login flows. Its actions can inherit the user’s RBAC scope, making the system easier to reason about and easier to audit.
Applying the pattern
To apply this architecture in your own platform, start by inventorying where sessions are created today. Identify which gateways run OIDC flows, which services parse tokens directly, which headers downstream applications trust, and how logout currently works.
Then define the central contract:
- Which service owns session creation?
- What claims will /gateway/userinfo return?
- Which gateway layer is allowed to inject identity headers?
- How long should platform sessions live?
- How will refresh and logout be audited?
- What happens if the session store is unavailable?
After the contract is clear, migrate incrementally. Start with one regional gateway or one group of related services. Replace local session validation with a call to the central identity gateway. Keep the application-facing identity interface stable so downstream services do not need large rewrites.
Once the first migration is working, add more gateways and tools. The goal is not to remove every regional enforcement point. The goal is to make every enforcement point read from the same source of session truth.
One question
Distributed session state is an architectural debt that accumulates quietly. It often appears first as repeated login prompts, but the larger cost is duplicated auth logic, inconsistent logout, unnecessary identity-provider load, and fragmented user context.
A central identity gateway addresses the root cause by separating session ownership from request enforcement. One service owns login, refresh, validation, and logout. Regional gateways enforce access locally while reading from a shared session record.
At NVIDIA, this pattern reduced repeated login events by 55% and created a foundation for unified developer portals and AI assistants with delegated user identity. The same approach can help other platform teams building federated Kubernetes, data, and AI environments.
To evaluate whether this pattern fits your platform, start with one question: Where does session state live today, and how many services are making identity decisions they should not need to make? If the answer reveals more distributed session state than you’d like, the migration path is straightforward: pick one gateway, replace local session validation with a central validation call, and keep the rest of the platform stable while you expand from there.
Getting started
Ready to implement a similar identity-aware gateway architecture? Begin with the OAuth2 Proxy local environment to explore OIDC login, cookie handling, and Redis-backed sessions. Next, follow the Istio external authorization sample to define the Auth Gateway interface, and add Rego policy evaluation with the OPA Envoy Istio example. For an integrated reference covering JWT and API-key validation, metadata enrichment, policy decisions, and trusted upstream headers, explore Authorino.
Together, these projects provide practical starting points for implementing the identity, gateway, and policy layers described in this post.
