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

/doc/integration/oauth_provider.md

https://gitlab.com/zillemarco/gitlab
Markdown | 131 lines | 96 code | 35 blank | 0 comment | 0 complexity | 4f64827ce76ecd672459589830b0dc73 MD5 | raw file
  1. ---
  2. stage: Manage
  3. group: Authentication and Authorization
  4. 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
  5. ---
  6. # Configure GitLab as an OAuth 2.0 authentication identity provider
  7. This document describes how you can use GitLab as an OAuth 2.0 authentication identity provider.
  8. - OAuth 2 applications can be created and managed using the GitLab UI (described below)
  9. or managed using the [Applications API](../api/applications.md).
  10. - After an application is created, external services can manage access tokens using the
  11. [OAuth 2 API](../api/oauth2.md).
  12. - To allow users to sign in to GitLab using third-party OAuth 2 providers, see
  13. [OmniAuth documentation](omniauth.md).
  14. ## Introduction to OAuth
  15. [OAuth 2](https://oauth.net/2/) provides to client applications a 'secure delegated
  16. access' to server resources on behalf of a resource owner. OAuth 2 allows
  17. authorization servers to issue access tokens to third-party clients with the approval
  18. of the resource owner or the end-user.
  19. OAuth 2 can be used:
  20. - To allow users to sign in to your application with their GitLab.com account.
  21. - To set up GitLab.com for authentication to your GitLab instance. See
  22. [GitLab OmniAuth](gitlab.md).
  23. The 'GitLab Importer' feature also uses OAuth 2 to give access
  24. to repositories without sharing user credentials to your GitLab.com account.
  25. GitLab supports several ways of adding a new OAuth 2 application to an instance:
  26. - [User owned applications](#user-owned-applications)
  27. - [Group owned applications](#group-owned-applications)
  28. - [Instance-wide applications](#instance-wide-applications)
  29. The only difference between these methods is the [permission](../user/permissions.md)
  30. levels. The default callback URL is `http://your-gitlab.example.com/users/auth/gitlab/callback`.
  31. ## User owned applications
  32. To add a new application for your user:
  33. 1. In the top-right corner, select your avatar.
  34. 1. Select **Edit profile**.
  35. 1. On the left sidebar, select **Applications**.
  36. 1. Enter a **Name**, **Redirect URI** and OAuth 2 scopes as defined in [Authorized Applications](#authorized-applications).
  37. The **Redirect URI** is the URL where users are sent after they authorize with GitLab.
  38. 1. Select **Save application**. GitLab provides:
  39. - The OAuth 2 Client ID in the **Application ID** field.
  40. - The OAuth 2 Client Secret, accessible:
  41. - In the **Secret** field in GitLab 14.1 and earlier.
  42. - Using the **Copy** button on the **Secret** field
  43. [in GitLab 14.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/332844).
  44. ## Group owned applications
  45. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16227) in GitLab 13.11.
  46. To add a new application for a group:
  47. 1. Navigate to the desired group.
  48. 1. On the left sidebar, select **Settings > Applications**.
  49. 1. Enter a **Name**, **Redirect URI** and OAuth 2 scopes as defined in [Authorized Applications](#authorized-applications).
  50. The **Redirect URI** is the URL where users are sent after they authorize with GitLab.
  51. 1. Select **Save application**. GitLab provides:
  52. - The OAuth 2 Client ID in the **Application ID** field.
  53. - The OAuth 2 Client Secret, accessible:
  54. - In the **Secret** field in GitLab 14.1 and earlier.
  55. - Using the **Copy** button on the **Secret** field
  56. [in GitLab 14.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/332844).
  57. ## Instance-wide applications
  58. To create an application for your GitLab instance:
  59. 1. On the top bar, select **Menu > Admin**.
  60. 1. On the left sidebar, select **Applications**.
  61. 1. Select **New application**.
  62. When creating application in the **Admin Area** , you can mark it as _trusted_.
  63. The user authorization step is automatically skipped for this application.
  64. ## Expiring access tokens
  65. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/21745) in GitLab 14.3, with the ability to opt out.
  66. > - Ability to opt-out of expiring access token [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/340848) in GitLab 15.0.
  67. WARNING:
  68. The ability to opt-out of expiring access tokens was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/340848)
  69. in GitLab 14.3 and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/340848) in 15.0. All
  70. existing integrations must be updated to support access token refresh.
  71. Access tokens expire in two hours which means that integrations that use them must support generating new access
  72. tokens at least every two hours. Existing:
  73. - Applications can have expiring access tokens:
  74. 1. Edit the application.
  75. 1. Select **Expire access tokens**.
  76. - Tokens must be [revoked](../api/oauth2.md#revoke-a-token) or they don't expire.
  77. When applications are deleted, all grants and tokens associated with the application are also deleted.
  78. ## Authorized applications
  79. Every application you authorize with your GitLab credentials is shown
  80. in the **Authorized applications** section under **Settings > Applications**.
  81. The GitLab OAuth 2 applications support scopes, which allow various actions that any given
  82. application can perform. Available scopes are depicted in the following table.
  83. | Scope | Description |
  84. | ------------------ | ----------- |
  85. | `api` | Grants complete read/write access to the API, including all groups and projects, the container registry, and the package registry. |
  86. | `read_user` | Grants read-only access to the authenticated user's profile through the /user API endpoint, which includes username, public email, and full name. Also grants access to read-only API endpoints under /users. |
  87. | `read_api` | Grants read access to the API, including all groups and projects, the container registry, and the package registry. |
  88. | `read_repository` | Grants read-only access to repositories on private projects using Git-over-HTTP or the Repository Files API. |
  89. | `write_repository` | Grants read-write access to repositories on private projects using Git-over-HTTP (not using the API). |
  90. | `read_registry` | Grants read-only access to container registry images on private projects. |
  91. | `write_registry` | Grants read-only access to container registry images on private projects. |
  92. | `sudo` | Grants permission to perform API actions as any user in the system, when authenticated as an administrator user. |
  93. | `openid` | Grants permission to authenticate with GitLab using [OpenID Connect](openid_connect_provider.md). Also gives read-only access to the user's profile and group memberships. |
  94. | `profile` | Grants read-only access to the user's profile data using [OpenID Connect](openid_connect_provider.md). |
  95. | `email` | Grants read-only access to the user's primary email address using [OpenID Connect](openid_connect_provider.md). |
  96. At any time you can revoke any access by clicking **Revoke**.