Improve tracking of revoked tokens after lifetime limits are updated

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem

The current process to mass revoke tokens after adjusting the token lifetime leaves a gap in auditing. If tokens are revoked due to changes in the overall token lifetime, an audit event for changing the setting is listed, but there is no information on which tokens were revoked. When an individual token is revoked, this is set as an entry in the audit events.

This affected a GitLab Dedicated customer after they reduced the lifetime from 365 to 180 days. The closest results we were able to find was by querying for tokens that were inactive / revoked and had an expires_at within the 185 day time frame that would have been revoked. For GitLab Dedicated and Dotcom customers, this can be quite taxing since they must query several API endpoints while self-managed customers can query the rails console directly.

Internal Zendesk Ticket: https://gitlab.zendesk.com/agent/tickets/575805

Findings of the behaviour from @dkua1

• Update PAT lifetime calls update lifetime service
• PolicyWorker is executed
• To revoke token if the expires_at is after the expiration date from the token lifetime

Proposal

There are a few changes that could help improve this

• Add an audit event for each token revoked after the lifetime limit change similar to what happens for an individual token
• Add a revoked_at value with the date/time a token was revoked. Would need to be returned via API calls for non self-managed instances to use
• Add logging for each token revoked. This would not help if logs have a set rollover date, such as Dotcom
• Update the updated_at value when a token is revoked, which currently does not happen. This would at least indicate when changes were last made, but couldn't guarantee it was the revocation action