Expiry criteria for access tokens, rather than only date
Release notes
As an alternative [or in addition] to a date-based expiration of access tokens, it's now possible to set a limit of successful requests.
Problem to solve
Some operations require not some fixed amount of time, but rather a known number of actions/events. Currently, even very short-lived tokens can only be set to expired at minimum on the next calendar day.
For example, when supporting GitLab.com customers, we are sometimes asked to check something in their projects, like CI logs.
Proposal
An expiration criterion like N successful requests would be more suitable to limit the lifetime of access tokens. This could be as an alternative to the Expiration date or an addition.
The latter case would be more complicated to implement, I presume since logic for "whichever limit is reached first triggers the token's revocation" would be needed.
Intended users
Feature Usage Metrics
- Lower median lifetime of tokens
- Higher %age of tokens created with such criteria rather than
Expiration date
Does this feature require an audit event?
No, as various token_created & token_revoked already exist.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.