Feature #43938
open
Track last usage of API access keys
Added by Vincent Robert about 16 hours ago.
Updated about 12 hours ago.
Description
Hello
As a first step toward #43881, this patch records and displays the last time each user's API key was used.
Problem:
There is currently no way to know if an API key has ever been used, or when it was last used.
This makes it impossible to identify stale or potentially compromised keys.
Proposal:
- Add a last_used_on column to the tokens table
- Update it on every successful API authentication (header, query parameter, or HTTP Basic)
- Display "Last used: X ago" / "Never used" in the account sidebar, next to the creation date
Notes:
- The update is a single UPDATE by unique index — negligible overhead per request
- Backward compatible: existing keys get null until first use
Files
- Related to Feature #43881: Strengthen API authentication: API tokens with expiration, scopes, rate limiting and audit logging added
This would write to the database on each and every API request which would cause a lot of write traffic and lock contention on the database table.
This should at least be throttled, similar to #28952 and #29041.
Ok. I have updated the patch, so the value is updated only once per minute.
- File deleted (
0001-track-api-key-last-used-on.patch)
This still issues the update query and thus may issue database locks. I think a better design here would be to use Token.find_token to get a hold of the actual object. From that, we can update the expiration date if required and return the user. That way, there is no update query at all unless actually required.
Alternatively, it may be a good idea to integrate the update of the last_used_on timestamp into the Token query methods directly. That way, the update would be naturally available to other token types too (e.g. the atom keys).
And with that being said, it seems that we already use the updated_on timestamp on session tokens to track when the session was last used. This serves quite a similar similar purpose than what you proposed here with the new last_used_on field. It may be useful to combine both of these features. We could also just bump the updated_on timestamp of the api token on use, similar to what is done for the session tokens min User.verify_session_token. Then, we would not need the separate database field at all.
Also available in: Atom
PDF
Updated by 
Updated by