PageRenderTime 51ms CodeModel.GetById 14ms RepoModel.GetById 0ms app.codeStats 0ms

/doc/user/profile/personal_access_tokens.md

https://gitlab.com/gitlab-r2devops/gitlab-foss
Markdown | 198 lines | 140 code | 58 blank | 0 comment | 0 complexity | a8cb1f5864ff55a5057d12db3c256f18 MD5 | raw file
  1. ---
  2. type: concepts, howto
  3. stage: Manage
  4. group: Authentication and Authorization
  5. info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
  6. ---
  7. # Personal access tokens **(FREE)**
  8. > - Notifications for expiring tokens [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab 12.6.
  9. > - Token lifetime limits [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab 12.6.
  10. > - Additional notifications for expiring tokens [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214721) in GitLab 13.3.
  11. > - Prefill for token name and scopes [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/334664) in GitLab 14.1.
  12. Personal access tokens can be an alternative to [OAuth2](../../api/oauth2.md) and used to:
  13. - Authenticate with the [GitLab API](../../api/index.md#personalprojectgroup-access-tokens).
  14. - Authenticate with Git using HTTP Basic Authentication.
  15. In both cases, you authenticate with a personal access token in place of your password.
  16. Personal access tokens are:
  17. - Required when [two-factor authentication (2FA)](account/two_factor_authentication.md) is enabled.
  18. - Used with a GitLab username to authenticate with GitLab features that require usernames. For example,
  19. [GitLab managed Terraform state backend](../infrastructure/iac/terraform_state.md#using-a-gitlab-managed-terraform-state-backend-as-a-remote-data-source)
  20. and [Docker container registry](../packages/container_registry/index.md#authenticate-with-the-container-registry),
  21. - Similar to [project access tokens](../project/settings/project_access_tokens.md) and [group access tokens](../group/settings/group_access_tokens.md), but are attached
  22. to a user rather than a project or group.
  23. NOTE:
  24. Though required, GitLab usernames are ignored when authenticating with a personal access token.
  25. There is an [issue for tracking](https://gitlab.com/gitlab-org/gitlab/-/issues/212953) to make GitLab
  26. use the username.
  27. For examples of how you can use a personal access token to authenticate with the API, see the [API documentation](../../api/index.md#personalprojectgroup-access-tokens).
  28. Alternately, GitLab administrators can use the API to create [impersonation tokens](../../api/index.md#impersonation-tokens).
  29. Use impersonation tokens to automate authentication as a specific user.
  30. ## Create a personal access token
  31. You can create as many personal access tokens as you like.
  32. 1. In the top-right corner, select your avatar.
  33. 1. Select **Edit profile**.
  34. 1. On the left sidebar, select **Access Tokens**.
  35. 1. Enter a name and optional expiry date for the token.
  36. 1. Select the [desired scopes](#personal-access-token-scopes).
  37. 1. Select **Create personal access token**.
  38. Save the personal access token somewhere safe. After you leave the page,
  39. you no longer have access to the token.
  40. ### Prefill personal access token name and scopes
  41. You can link directly to the Personal Access Token page and have the form prefilled with a name and
  42. list of scopes. To do this, you can append a `name` parameter and a list of comma-separated scopes
  43. to the URL. For example:
  44. ```plaintext
  45. https://gitlab.example.com/-/profile/personal_access_tokens?name=Example+Access+token&scopes=api,read_user,read_registry
  46. ```
  47. WARNING:
  48. Personal access tokens must be treated carefully. Read our [token security considerations](../../security/token_overview.md#security-considerations)
  49. for guidance on managing personal access tokens (for example, setting a short expiry and using minimal scopes).
  50. ## Revoke a personal access token
  51. At any time, you can revoke a personal access token.
  52. 1. In the top-right corner, select your avatar.
  53. 1. Select **Edit profile**.
  54. 1. On the left sidebar, select **Access Tokens**.
  55. 1. In the **Active personal access tokens** area, next to the key, select **Revoke**.
  56. ## View the last time a token was used
  57. Token usage is updated once every 24 hours. It is updated each time the token is used to request
  58. [API resources](../../api/api_resources.md) and the [GraphQL API](../../api/graphql/index.md).
  59. To view the last time a token was used:
  60. 1. In the top-right corner, select your avatar.
  61. 1. Select **Edit profile**.
  62. 1. On the left sidebar, select **Access Tokens**.
  63. 1. In the **Active personal access tokens** area, next to the key, view the **Last Used** date.
  64. ## Personal access token scopes
  65. A personal access token can perform actions based on the assigned scopes.
  66. | Scope | Access |
  67. |--------------------|--------|
  68. | `api` | Read-write for the complete API, including all groups and projects, the Container Registry, and the Package Registry. |
  69. | `read_user` | Read-only for endpoints under `/users`. Essentially, access to any of the `GET` requests in the [Users API](../../api/users.md). |
  70. | `read_api` | Read-only for the complete API, including all groups and projects, the Container Registry, and the Package Registry. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28944) in GitLab 12.10.) |
  71. | `read_repository` | Read-only (pull) for the repository through `git clone`. |
  72. | `write_repository` | Read-write (pull, push) for the repository through `git clone`. |
  73. | `read_registry` | Read-only (pull) for [Container Registry](../packages/container_registry/index.md) images if a project is private and authorization is required. |
  74. | `write_registry` | Read-write (push) for [Container Registry](../packages/container_registry/index.md) images if a project is private and authorization is required. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28958) in GitLab 12.10.) |
  75. | `sudo` | API actions as any user in the system (if the authenticated user is an administrator). |
  76. ## When personal access tokens expire
  77. Personal access tokens expire on the date you define, at midnight UTC.
  78. - GitLab runs a check at 01:00 AM UTC every day to identify personal access tokens that expire in the next seven days. The owners of these tokens are notified by email.
  79. - GitLab runs a check at 02:00 AM UTC every day to identify personal access tokens that expire on the current date. The owners of these tokens are notified by email.
  80. - In GitLab Ultimate, administrators can
  81. [limit the lifetime of personal access tokens](../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens).
  82. - In GitLab Ultimate, administrators can choose whether or not to
  83. [enforce personal access token expiration](../admin_area/settings/account_and_limit_settings.md#allow-expired-personal-access-tokens-to-be-used-deprecated).
  84. ## Create a personal access token programmatically **(FREE SELF)**
  85. You can create a predetermined personal access token
  86. as part of your tests or automation.
  87. Prerequisite:
  88. - You need sufficient access to run a
  89. [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session)
  90. for your GitLab instance.
  91. To create a personal access token programmatically:
  92. 1. Open a Rails console:
  93. ```shell
  94. sudo gitlab-rails console
  95. ```
  96. 1. Run the following commands to reference the username, the token, and the scopes.
  97. The token must be 20 characters long. The scopes must be valid and are visible
  98. [in the source code](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/auth.rb).
  99. For example, to create a token that belongs to a user with username `automation-bot`:
  100. ```ruby
  101. user = User.find_by_username('automation-bot')
  102. token = user.personal_access_tokens.create(scopes: [:read_user, :read_repository], name: 'Automation token')
  103. token.set_token('token-string-here123')
  104. token.save!
  105. ```
  106. This code can be shortened into a single-line shell command by using the
  107. [Rails runner](../../administration/troubleshooting/debug.md#using-the-rails-runner):
  108. ```shell
  109. sudo gitlab-rails runner "token = User.find_by_username('automation-bot').personal_access_tokens.create(scopes: [:read_user, :read_repository], name: 'Automation token'); token.set_token('token-string-here123'); token.save!"
  110. ```
  111. ## Revoke a personal access token programmatically **(FREE SELF)**
  112. You can programmatically revoke a personal access token
  113. as part of your tests or automation.
  114. Prerequisite:
  115. - You need sufficient access to run a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session)
  116. for your GitLab instance.
  117. To revoke a token programmatically:
  118. 1. Open a Rails console:
  119. ```shell
  120. sudo gitlab-rails console
  121. ```
  122. 1. To revoke a token of `token-string-here123`, run the following commands:
  123. ```ruby
  124. token = PersonalAccessToken.find_by_token('token-string-here123')
  125. token.revoke!
  126. ```
  127. This code can be shortened into a single-line shell command using the
  128. [Rails runner](../../administration/troubleshooting/debug.md#using-the-rails-runner):
  129. ```shell
  130. sudo gitlab-rails runner "PersonalAccessToken.find_by_token('token-string-here123').revoke!"
  131. ```
  132. <!-- ## Troubleshooting
  133. Include any troubleshooting steps that you can foresee. If you know beforehand what issues
  134. one might have when setting this up, or when something is changed, or on upgrading, it's
  135. important to describe those, too. Think of things that may go wrong and include them here.
  136. This is important to minimize requests for support, and to avoid doc comments with
  137. questions that you know someone might ask.
  138. Each scenario can be a third-level heading, e.g. `### Getting error message X`.
  139. If you have none to add when creating a doc, leave this section in place
  140. but commented out to help encourage others to add to it in the future. -->