Teleport IdP group cache TTL vs. certificate TTL: which knob actually bounds stale-access window?

Direct answer

The certificate or session TTL is the effective upper bound on stale IdP group access. Teleport embeds roles at certificate issuance and trusts them until expiry. Removing a user from an IdP group does not revoke an already-issued certificate, so the stale-access window lasts until the current certificate expires, not until the IdP cache TTL elapses.

Confirmed behavior versus likely explanation

Confirmed: the IdP user/group cache TTL controls how long the auth server reuses connector data during new authentication or certificate issuance. It does not retroactively shorten or invalidate live certificates. Confirmed: Community uses an in-memory cache and Enterprise can use Redis; neither backend revokes certificates on IdP group mutation. Likely explanation: auth_service.authentication_cache_ttl is version-specific, undocumented, and not guaranteed stable; do not build a production SLA on it without vendor confirmation.

Steps for this case

1. Check your Teleport version. Exact configuration names differ across releases, and authentication_cache_ttl may not exist in your build.
2. Set max_session_ttl, or your version's equivalent session/certificate TTL, to the maximum staleness window you can tolerate.
3. Rely on IdP SSO or refresh tokens so clients silently obtain new certificates after expiry, avoiding full credential re-entry where the IdP and client support it.
4. Verify with tsh status to inspect certificate expiry, then remove the user from the IdP group and confirm the existing certificate still grants access until it expires.

Safe verification command

tsh status

Community versus Enterprise

The answer does not fundamentally differ by cache backend. Redis persistence may keep stale group entries visible across auth service restarts longer than the in-memory Community cache, but that only affects future authentications. Active certificates remain valid until TTL expiry in both deployments.

Sub-certificate-TTL freshness

There is no supported Teleport setting that refreshes group membership on a live certificate without re-issuance. Manual tctl auth cache clear affects only subsequent authentications. To approach sub-TTL freshness, shorten the certificate TTL and depend on silent re-authentication through the IdP. Confirm your clients and IdP support silent token refresh before lowering TTL in production.

Missing diagnostic detail: What Teleport version are you running? The recommendation changes if authentication_cache_ttl exists in your version, because config names and cache behavior vary by release.