granular control on token TTL

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

• Close this issue

Proposal

I would like to have a granular control on token expiry by time, better by Time-To-Live(TTL), instead of tokens being expired at midnight UTC.

• change expire_at field on token to date with time. e.g. 2021-01-01T10.15.000Z (control up to minutes)
• better: we can choose TTL. At the time of generation, being able to set a TTL. e.g. TTL of 1h. if current date is 2021-01-01T10.15.000Z then expire_at will be set at 2021-01-01T11.15.000Z. This logic can be implemented in backend system on our end/automation to programmatically generate project access token. Not necessary to have in Gitlab application but it's still good to have in general.

Scope

• Project Access Token

Personal Access Token can be out of scope for this as it doesn't need to be frequently and programmatically generated/expired/revoked.

Use Case

As GITLAB_CI_TOKEN is limited to scope in API and also tied to user access, it's quite limited. Gitlab added project access token to avoid using personal access token in CI and it works phenomenal for most of organization/use cases.

However, this project access token is static. static token is insecure and imposes operational burden to rotate. It's better to have it ephemeral for more secure access and reducing operational burden. Having token expiry at midnight UTC is far from desired.

It's better to have user to revoke no-longer-needed project access token by themselves, but we most likely cannot force them. In that case, next thing to do is set granular control on expiry so that in case a user forget to revoke, it can be expired in timely manner.