Airflow Session and Secret Revocation Limits

When enforcing least privilege in Airflow, we need active web sessions and worker-resolved secrets to reflect credential changes promptly—for example, after rotating a connection password in an external secrets backend or disabling a user account. The goal is to understand the documented boundaries of this behavior so we can decide whether Airflow alone can enforce timely revocation or whether we must rely on external identity providers, reverse proxies, and secret-manager TTLs.

The uncertainty is that Airflow's FAB-based auth manager and secrets backends do not expose a single, uniform core hook for propagating these changes. Session invalidation after a password change or user deactivation depends on the configured auth manager and session storage, while workers and schedulers may cache secrets or require restarts depending on the backend. Because revocation semantics differ by deployment, it is unclear which guarantees are supported natively versus which require external controls.

Which documented behaviors govern session invalidation when a user is deactivated or their password is rotated? Does Airflow provide any native mechanism to force workers to drop cached secret references immediately after a backend rotation, or is refresh timing backend-specific? Where does the supported boundary lie between Airflow's auth manager and an external identity provider for enforcing credential expiration and lockout policies?