Repository navigation
Automatic deletion and disabling of users #38108
Description
Description
Keycloak does not currently provide any mechanisms to automatically disable or remove users. There are a number of use-cases where this is relevant:
- Automatically disable dormant users
- Automatically delete abandoned users
- Transient/temporary users brokered from identity providers
- Transient/temporary users federated through user federation providers
This is relevant to PIP (for example GDPR) where it is generally a requirement to not store user information when not needed.
This is an alternative proposal to transient users for brokering. Transient users stored in sessions is not a solution to privacy for many reasons; sessions may still be persisted to the database, they may be long lived; and additionally and probably the biggest issue from a privacy perspective there is no mechanism to identity user information stored in transient user sessions, so there may be long-lived and persisted sessions storing information about users. From a privacy perspective users have the right to know what information is stored about them, as well as a right to have their information deleted from a provider; neither of which can be guaranteed with transient user sessions.
Value Proposition
Automatically disabling and/or deletion of user accounts provides increased security (unused and no longer maintained accounts can be abused) and privacy (not storing user information when no longer needed).
Goals
- Ability to automatically disable unused users after a configurable time
- Ability to automatically delete unused users after a configurable time
- Ability to automatically delete users from a identity provider where there are no active sessions
- Ability to automatically delete users from a federation provider where there are no active sessions
- Remove experimental transient user stored in user sessions
Non-Goals
- Not importing users coming from an identity provider into LDAP. Ability to selectively add users to a federation provider is not covered by this issue, and would be a separate RFE.
Activity
oculos commentedon Mar 14, 2025
While the new features are really useful, removing transient users seems like a bad idea to me.
Of course, if people start to use transient users for really long sessions and in other ways where it doesn't make sense, it is understandable that it negatively impact GDPR compliance.
But transient users for short-lived sessions is actually a great way to provide quick access without having to come with (incomplete and prone to failure) policies for cleaning up. With transient users, One can have better separation between "internal" users and "external" users.
If one thing should be changed about transient users it would be better information about their session while they exist. Today, you click on those sessions and there's a spinning ball waiting for you. Not ideal.
That kind of transparency for transient users would make it completely GDPR compliant and make admin lives easier.
Just my .2 here.
maximemercy10 commentedon Jun 3, 2025
I'd like to present our use case. My company uses Okta as our identity provider and for user management, which includes attributes necessary for assigning groups and roles in Keycloak. Our goal is to configure Keycloak so effectively that we rarely need to access the admin panel for role and permission management.
Our risk and security team requires a mechanism to regulate inactive users to approve Keycloak. If Okta deactivates direct authentication due to incidents like hacks or organizational changes, former users might retain access through previously assigned roles and groups in the database. High employee turnover could lead to an accumulation of inactive users, increasing the risk of uncontrolled access.
While Oculus raises valid points, we are not advocating for automatic user removal. Instead, we propose an optional feature that allows actions such as removing users or revoking their roles and groups based on configurable time criteria and possibly specific roles. For example, users inactive for six months could be reviewed, excluding admins.
stianst commentedon Jul 23, 2025
See #39888
oculos commentedon Jun 9, 2026
I just got into a discussion where some government agencies want to offer simple access to citizens to certain services. Transient users is simply perfect for them because there are no needs to persist those users or to manage their lifecycle. They just need to have access.
Having to suddenly persist millions of users, even with a proper lifecycle management, might be overkill for many.
I just wanted to have this registered here in case this can be useful when the eventual removal of transient users is assessed.
eicki commentedon Aug 29, 2026
I am currently working on a bsi-c5 project and just want to share the requirements originating from that perspective.
It requires "user accounts must be automatically locked after 2 months of inactivity and automatically revoked after 6 months". Now depending on how you interpret the second part, it may mean you need some trigger that just unassigns the user from any roles/groups without actually deleting that user.
Probably this issue is best implemented in a flexible way anyway, i.e. it must be tracked somewhere when a user last signed in or had been active. Then depending on that some custom action can be triggered probably offering disable/delete by default but open for any custom extension to implement revoke roles/groups.
dasniko commentedon Aug 30, 2026
@eicki This works pretty well with Workflows, at least the most of it. The rest is, like you already mentioned, "how you interpret it" and can be achieved by a custom workflow step as an extension. All of the workflow stuff is based on SPIs, so it's possible to extend it to your requirements.
More to that, it would be perhaps worth a contribution to extend the existing workflow steps to accept a wildcard
*and thus to unassign all roles and leave all groups. The existing ones can already accept one or multiple role/group name(s).