Spring SAML session revocation: closing the browser is not deprovisioning

Login is a point-in-time decision

A contractor signs in through SAML, then loses access at the IdP. Their browser still holds an application session. The service provider does not automatically revalidate every request against the IdP. Choose a session lifetime, idle timeout and emergency invalidation workflow that match the business risk. Local authorities also need a refresh or revocation rule.

Make invalidation work across replicas

A multi-pod deployment cannot rely on one pod's private session map if the user can be routed elsewhere. Use a shared session store or another centralized revocation mechanism, and bind the stored subject to the IdP registration and tenant. Rotate the session ID at login. Fixation protection addresses a different takeover route.

Drill a real account removal

Sign in, remove the user from a privileged group at the IdP, and call the protected endpoint before and after the chosen revocation event. Verify the documented maximum access window. Repeat while the IdP is unavailable and after one application replica restarts.

Implementation sketch

record FederatedSessionKey(String registrationId,
                           String subject, String tenantId) {}
// Index active sessions by this trusted key for targeted revocation.

Cost and verification

A shared session store adds storage and lookup I/O. Shorter lifetimes reduce the maximum stale-access window but cause more authentication exchanges.

Common Mistakes

• Do not assume an IdP group change instantly changes an existing local session.
• Do not key revocation by email alone across multiple IdPs.
• Do not invalidate only one pod's in-memory session in a replicated deployment.

Read next

Spring Security SAML logout: local session versus single logout, Spring Security SAML attributes: map identity to local authority, Spring Security login session: rotate the identifier at authentication.