401 Unauthorized on Kubeflow dashboard after OIDC token revocation

Question

In a Kubeflow environment utilizing Istio for authentication, the auth-proxy validates OIDC tokens at the request level. While Kubernetes RBAC manages permissions based on OIDC groups, there is a discrepancy between the identity provider's state and the active Istio session.
When a user is deactivated or their credentials are rotated in the OIDC provider, the Kubeflow UI often remains accessible due to local session state. However, subsequent API calls to the dashboard return a 401 Unauthorized error. Because the 'auth' component lacks a native mechanism to force a global invalidation of specific user tokens, these sessions remain active until the JWT naturally reaches its TTL.
Is there a documented method to trigger immediate revocation of active Istio sessions for specific users without implementing custom Envoy filters? Additionally, how can the system be configured to verify the current status of a token against the provider rather than relying solely on JWT expiration dates?

Tasadduq Burney · Answer

To resolve 401 Unauthorized errors occurring after OIDC token revocation, you must address the state mismatch between the Identity Provider (IdP) and the local Istio/Dex session. There is no native 'global command' to trigger immediate invalidation of active Istio sessions without custom-side logic, as Istio relies on the cryptographic validity of the JWT until it expires.

Explanation of the Discrepancy
p>In a standard Kubeflow installation, authentication is handled by Dex and the Istio auth-proxy. When a user authenticates via OIDC, Dex issues a JWT and a local session cookie. If the user is deactivated in the IdP, the existing JWT remains cryptographically valid until its TTL is reached. The 401 Unauthorized error occurs when the dashboard UI attempts an API call using the local session, but the backend service (or a refreshed RBAC check) identifies the identity as no longer valid or the proxy rejects the request.

Immediate Revocation Strategies
Since there is no documented method to revoke sessions without Envoy filters, you can use the following approaches to force invalidation:

Clear Client Side Sessions: The most direct method for a specific user is to clear the session cookies (typically dex-session or similar) in the browser. This forces the client to re-authenticate against Dex, which will then check with the IdP.
  Pod Restart (Global): Restarting the Dex deployment or the Istio-ingressgateway pods can sometimes clear cached sessions, though this is not scoped to a single user.
  Shorten JWT TTL: Reduce the token-lifetime in the Dex configuration. This limits the "window of opportunity" where a revoked token remains active, though it increases the load on your IdP.

Verifying Token Status Against the Provider
To move beyond relying solely on JWT expiration dates, you must configure the system to perform real-time validation. This is typically achieved through:

OIDC Introspection: Configure your authentication proxy to use the OIDC introspection endpoint. This allows the proxy to query the IdP for every request (or at frequent intervals) to verify if the token is still active.
  Back-channel Logout: If your IdP supports it, implement back-channel logout where the IdP sends a request to Dex to invalidate sessions when a user is revoked.

Diagnostic Question: To provide a more specific configuration, is the 401 error returned by the Istio-ingress gateway or by a specific Kubeflow microservice (like the notebook or dashboard API)?

401 Unauthorized on Kubeflow dashboard after OIDC token revocation

1 answer

Explanation of the Discrepancy

Immediate Revocation Strategies

Verifying Token Status Against the Provider

Your perspective belongs here.

1 question comment

Practical Verification