Workload Identity Federation: Token Persistence After External Identity Expiry

Short answer

No. Expiration or revocation of the external IdP token does not immediately invalidate GCP access tokens already issued via Workload Identity Federation. Deleting the Workload Identity Pool provider or its attribute mapping stops new STS exchanges, but existing federated GCP access tokens remain usable until their natural expiry.

Confirmed facts

• Security Token Service validates the external OIDC/OAuth2 token at exchange time only. After validation, STS issues a short-lived GCP access token bound to the target service account.
• The issued GCP access token lifetime is capped by the pool provider configuration, typically up to 1 hour. It is a standard Google access token.
• Subsequent STS token exchanges require a currently valid external token and an active Workload Identity Pool provider and mapping. IAM role grants to the service account are evaluated at API call time.
• IAM policy changes and federation configuration deletions are subject to eventual consistency.

Likely behavior, not guaranteed by public docs

Once issued, the GCP access token is not continuously re-checked against the external IdP session. External token expiry, user disablement in the IdP, or revocation of the external token does not trigger real-time invalidation of the already issued GCP token. Google does not maintain a standard real-time revocation feed from external IdPs into STS.

Deleting the Workload Identity Pool provider or removing the attribute mapping prevents new exchanges. Tokens already in flight continue to be accepted by Google APIs until they expire, unless the service account credential itself is removed or IAM access is revoked.

Reactive revocation for abuse or security incidents may occur on Google's side, but it is not the normal lifecycle coupling.

What to do for this case

Assume token persistence and design for it.

1. Keep federated token lifetimes short. Verify the provider max token lifetime and set it to the minimum acceptable for your workload.
2. For immediate loss of access, remove the IAM grant from the target service account or delete/disable the service account key, not just the federation mapping.
3. Audit: check Cloud Audit Logs for `sts.googleapis.com` TokenExchange and `iam.googleapis.com` SetIamPolicy events to correlate exchange time with mapping deletion.

Verification

Exchange a token, record its exp claim, then disable the external identity or delete the WIP mapping and call a GCP API with the existing token before expiry. A new exchange should fail with an invalid_grant or provider not found error.

One missing detail that changes the recommendation: are you using raw STS access tokens with a fixed lifetime, or are client libraries auto-refreshing via a long-lived external credential? Auto-refresh changes the window of exposure after IdP revocation.