@stianst I think it is a good idea to provide a generic way for expiration tracking and notification for different entities.

The expiration strategy Expire if entity not used for x days should be supported. The following needs to be customizable

Entity: The entity which should be handled if not used (e.g. User)
Not used: the action which marks entity as accessed or used (e.g. last login for a user account)
Expiration time: in the range of hours up to many days. (e.g. 120 days)
Handle expiration: Things which should happen when entity not used for expiration time. Sometimes it means direct deletion, sometimes notification, or also notification and schedule for final deletion.

A complete use case

A user should get a notifcation email if the account wasn't used for login for 120 days. When this email was sent, the account should be deleted after 30 days if there wasn't a login during these days.

Implementation proposal

• On every user a last use tuple is stored: (entity:USER, id:123, action:"login", ts:2022-10-28T13:44:57Z, handled:false). Subsequent login of the same user will overwrite this tuple.
• Expiration listeners (new SPI) can specify after which time they want to be notified. A listener for USER and action "login" will define that it wants to be notified 120 days after last "login" entry.
• After 120 without login the listener implementation gets the last use tuple: (USER, id:123, "login", ts:2022-10-28T13:44:57Z, handled:false). It sends out a notification mail: "Your account will be deleted aster 30 days, if you do not login."
  The listener implementation also creates a tuple to schedule deletion: (USER, id:123, action:"delete_scheduled", ts:2023-02-25T14:01:03Z)
• The listener implementation returns without exception. The original tuple is updated to (USER, id:123, "login", ts:2022-10-28T13:44:57Z, handled:true).
• An additional expiration listener on "delete_scheduled" with 30 days expiration will check if account was really not used in last 30 days and may delete the account. For the check it needs access to load the last use tuple identified by (USER, id:123, "login")

Data model

(entity, id, action, ts, handled) is stored and should also be accessible via Admin API.
The properties (entity, id, action) form a composite primary key. There are no two entries where all three properties are the same.

During Keycloak Dev Days we talked a bit about this. Our discussed use cases are both security and GDPR compliance. A user with some access permission who didn't log in for some time should probably not have these permissions anymore. If they do need them, the notification(s) remind them to log in.

The scenario is quite simiiar to the one @jbman outlined before. To reduce load, it might be a good idea to not store any new login, but only if it's significant enough. That means that it might be interesting to only save a new login date to the database when "now" differs to the stored value by a (small) percentage of the expiration threshold. However this also needs to respect how long a session lives. E.g. when a session lives for 2 months without relogin and the user should be deleted soon after, they might still be quite active.

There seem quite a few people who implemented a simple but poorly performing solution by using user attributes.

Another consideration is that a user should also be markable as "never expired", for example some people use emergency admin or technical (tho not technical enough for a client) accounts