Skip to content

Draft: Extends self rotate endpoint to all access token (PAT/PrAT/GrAT)

What does this MR do and why?

What does this MR ?

  • Adds a self_rotate scope fort PAT/GrAT/PrAT which purpose is to allow a non api access token to rotate itself using the Access Token self rotate api
  • Extends the Access Token self rotate api (see !142664 (merged)) to PrAT and GrAT

Note: With this MR only access tokens with api or self_rotate scope will be able to rotate themselves

Why ?

In the current Gitlab version, if you want to programmatically rotate an PrAT or a GrAT you need a second access token (specifically an api scoped PAT) and the procedure will be neither simple nor secure:

  • Rotation the PrAT/GrAT (see #426779) requires to
    1. exec a 1st request to obtain the PrAT/GrAT
    2. extract the token id
    3. exec a 2nd request to rotate the PrAT/GrAT
  • Rotation of the api PAT will also have to done periodically

So currently PrAT/GrAT are kind of useless in automation scenarios...

With the proposed MR, you just have to add a self_rotate scope to a PAT/GrAT/PrAT in order to enable it to rotate itself.

So automations scenarios will be simpler (just 1 request to self-rotate the token) and more secure (a 2nd api scoped PAT is not needed anymore).

Require !142664 (merged)
Related issues #426779 #430748 #434416 (closed)
Closes #426779 #430748

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Personnal Access Token

Before After
image image-1

Group Access Token

Before After
image image-1

Project Access Token

Before After
image image-1

How to set up and validate locally

  1. Create a PAT/GrAT/PrAT token with api or self_rotate scope
  2. Run the following command
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/personal_access_tokens/self/rotate"

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Stéphane Talbot

Merge request reports