Question
Can OpenShift enforce immediate revocation of all active OAuth tokens for a user when their identity provider credentials are disabled?
Rin Echo
0 reputation · 21 Aug 2026, 14:00 UTC
83K views
Loading…
0 reputation · 21 Aug 2026, 14:00 UTC
To maintain a strict least‑privilege posture, an OpenShift cluster must ensure that once a user’s identity provider credentials are revoked or disabled, no active OAuth session or service‑account token remains usable beyond the configured token lifetime.
OpenShift’s OAuth configuration exposes accessTokenMaxAgeSeconds (default 86400 s) to govern the lifetime of user access tokens. Service‑account tokens created as secrets are long‑lived and do not automatically expire with the OAuth token, while projected TokenRequest API tokens can be bounded to a short lifetime. Revoking a token object invalidates the session it represents, but other active sessions for the same identity remain valid until their own expiry. The current platform does not provide a cluster‑wide, immediate revocation mechanism triggered by an identity provider state change.
Can OpenShift enforce immediate revocation of all active OAuth tokens for a user when their identity provider credentials are disabled, or should the system continue to honor existing tokens until their configured expiration?
29775 reputation · 21 Aug 2026, 21:03 UTC
No, OpenShift does not automatically revoke all active OAuth tokens when a user's identity provider credentials are disabled.
redhat
oauthaccessTokenMaxAgeSeconds (default 86400s).oc delete oaccesstoken.OAuth tokens are bearer tokens; the server has no persistent session state to push revocation notices, so it relies on expiry or explicit revocation calls.
accessTokenMaxAgeSeconds to a short value (e.g., 300s) in the OAuth configuration.oc get oaccesstoken -o json) and deletes them with oc delete oaccesstoken <token> or a POST to /oauth/token/revoke./oauth/token/revoke endpoint; this works only if the IdP supports it and the OAuth server is set to accept logout requests.To decide whether a manual script is necessary, please confirm: which identity provider are you using and does it support front-channel/logout or token introspection that OpenShift can consume?
Use comments to ask for clarification. Post a solution as an answer.
29,775 reputation · 21 Aug 2026, 21:36 UTC
One clarification on the "no persistent session state" point: OpenShift's OAuth server does persist each session as an OAuthAccessToken object in etcd and resolves that object when the token is presented. Deleting the object therefore revokes that session immediately — the delay sits in detecting IdP disablement, not in propagating revocation.
Two practical consequences, worth verifying against your version (described for OpenShift 4.x; confirm against current release notes):
accessTokenMaxAgeSeconds applies to newly issued tokens; already-issued tokens keep the expiry recorded at issuance, so it is not a retroactive revocation lever.oc get oauthaccesstokens --field-selector=userName=<user>) instead of assuming one token per user.Also, TokenReview is not a revocation check — it succeeds for any unexpired, undeleted token regardless of IdP state. Whether deleting a User or Identity cascades to its tokens is worth confirming in a test namespace before relying on it as cleanup.