debian-mirror-gitlab/doc/api/oauth2.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

424 lines
17 KiB
Markdown
Raw Normal View History

2021-01-29 00:20:46 +05:30
---
type: reference, howto
stage: Manage
2022-04-04 11:22:00 +05:30
group: Authentication and Authorization
2022-11-25 23:54:43 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
2021-01-29 00:20:46 +05:30
---
2021-11-18 22:05:49 +05:30
# OAuth 2.0 identity provider API **(FREE)**
2015-04-26 12:48:37 +05:30
2021-11-18 22:05:49 +05:30
GitLab provides an API to allow third-party services to access GitLab resources on a user's behalf
with the [OAuth2](https://oauth.net/2/) protocol.
2015-04-26 12:48:37 +05:30
2021-11-18 22:05:49 +05:30
To configure GitLab for this, see
[Configure GitLab as an OAuth 2.0 authentication identity provider](../integration/oauth_provider.md).
This functionality is based on the [doorkeeper Ruby gem](https://github.com/doorkeeper-gem/doorkeeper).
2015-04-26 12:48:37 +05:30
2022-08-13 15:12:31 +05:30
## Cross-origin resource sharing
2022-07-23 23:45:48 +05:30
2022-08-13 15:12:31 +05:30
> CORS preflight request support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/364680) in GitLab 15.1.
2022-07-23 23:45:48 +05:30
2022-08-13 15:12:31 +05:30
Many `/oauth` endpoints support cross-origin resource sharing (CORS). From GitLab 15.1, the following endpoints also
support [CORS preflight requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS):
2022-07-23 23:45:48 +05:30
- `/oauth/revoke`
- `/oauth/token`
- `/oauth/userinfo`
2022-08-27 11:52:29 +05:30
Only certain headers can be used for preflight requests:
- The headers listed for [simple requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests).
- The `Authorization` header.
For example, the `X-Requested-With` header can't be used for preflight requests.
2022-08-13 15:12:31 +05:30
2021-11-11 11:23:49 +05:30
## Supported OAuth 2.0 flows
2015-04-26 12:48:37 +05:30
2021-11-11 11:23:49 +05:30
GitLab supports the following authorization flows:
2015-04-26 12:48:37 +05:30
2022-11-25 23:54:43 +05:30
- **Authorization code with [Proof Key for Code Exchange (PKCE)](https://www.rfc-editor.org/rfc/rfc7636):**
2021-03-08 18:12:59 +05:30
Most secure. Without PKCE, you'd have to include client secrets on mobile clients,
2021-03-11 19:13:27 +05:30
and is recommended for both client and server apps.
2021-03-08 18:12:59 +05:30
- **Authorization code:** Secure and common flow. Recommended option for secure
server-side apps.
- **Resource owner password credentials:** To be used **only** for securely
hosted, first-party services. GitLab recommends against use of this flow.
The draft specification for [OAuth 2.1](https://oauth.net/2.1/) specifically omits both the
2022-04-04 11:22:00 +05:30
Implicit grant and Resource Owner Password Credentials flows.
2015-04-26 12:48:37 +05:30
2022-11-25 23:54:43 +05:30
Refer to the [OAuth RFC](https://www.rfc-editor.org/rfc/rfc6749) to find out
2019-02-15 15:39:39 +05:30
how all those flows work and pick the right one for your use case.
2016-09-13 17:45:13 +05:30
2022-07-16 23:28:13 +05:30
Authorization code (with or without PKCE) flow requires `application` to be
2019-02-15 15:39:39 +05:30
registered first via the `/profile/applications` page in your user's account.
During registration, by enabling proper scopes, you can limit the range of
2021-06-08 01:23:25 +05:30
resources which the `application` can access. Upon creation, you obtain the
2022-04-04 11:22:00 +05:30
`application` credentials: _Application ID_ and _Client Secret_. The _Client Secret_
**must be kept secure**. It is also advantageous to keep the _Application ID_
secret when your application architecture allows.
2015-04-26 12:48:37 +05:30
2022-03-02 08:16:31 +05:30
For a list of scopes in GitLab, see [the provider documentation](../integration/oauth_provider.md#authorized-applications).
2021-01-29 00:20:46 +05:30
### Prevent CSRF attacks
2023-01-13 00:05:48 +05:30
To [protect redirect-based flows](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13#section-3.1),
2021-01-29 00:20:46 +05:30
the OAuth specification recommends the use of "One-time use CSRF tokens carried in the state
parameter, which are securely bound to the user agent", with each request to the
`/oauth/authorize` endpoint. This can prevent
[CSRF attacks](https://wiki.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)).
### Use HTTPS in production
For production, please use HTTPS for your `redirect_uri`.
For development, GitLab allows insecure HTTP redirect URIs.
2021-11-11 11:23:49 +05:30
As OAuth 2.0 bases its security entirely on the transport layer, you should not use unprotected
2022-11-25 23:54:43 +05:30
URIs. For more information, see the [OAuth 2.0 RFC](https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2.1)
and the [OAuth 2.0 Threat Model RFC](https://www.rfc-editor.org/rfc/rfc6819#section-4.4.2.1).
2016-09-13 17:45:13 +05:30
2021-06-08 01:23:25 +05:30
In the following sections you can find detailed instructions on how to obtain
2019-02-15 15:39:39 +05:30
authorization with each flow.
2015-04-26 12:48:37 +05:30
2021-03-08 18:12:59 +05:30
### Authorization code with Proof Key for Code Exchange (PKCE)
2022-11-25 23:54:43 +05:30
The [PKCE RFC](https://www.rfc-editor.org/rfc/rfc7636#section-1.1) includes a
2021-03-08 18:12:59 +05:30
detailed flow description, from authorization request through access token.
The following steps describe our implementation of the flow.
The Authorization code with PKCE flow, PKCE for short, makes it possible to securely perform
2022-04-04 11:22:00 +05:30
the OAuth exchange of client credentials for access tokens on public clients without
requiring access to the _Client Secret_ at all. This makes the PKCE flow advantageous
for single page JavaScript applications or other client side apps where keeping secrets
2022-05-07 20:08:51 +05:30
from the user is a technical impossibility.
2021-03-08 18:12:59 +05:30
Before starting the flow, generate the `STATE`, the `CODE_VERIFIER` and the `CODE_CHALLENGE`.
- The `STATE` a value that can't be predicted used by the client to maintain
state between the request and callback. It should also be used as a CSRF token.
- The `CODE_VERIFIER` is a random string, between 43 and 128 characters in length,
which use the characters `A-Z`, `a-z`, `0-9`, `-`, `.`, `_`, and `~`.
- The `CODE_CHALLENGE` is an URL-safe base64-encoded string of the SHA256 hash of the
`CODE_VERIFIER`
2021-11-11 11:23:49 +05:30
- The SHA256 hash must be in binary format before encoding.
2021-10-27 15:23:28 +05:30
- In Ruby, you can set that up with `Base64.urlsafe_encode64(Digest::SHA256.digest(CODE_VERIFIER), padding: false)`.
2021-11-11 11:23:49 +05:30
- For reference, a `CODE_VERIFIER` string of `ks02i3jdikdo2k0dkfodf3m39rjfjsdk0wk349rj3jrhf` when hashed
and encoded using the Ruby snippet above produces a `CODE_CHALLENGE` string
of `2i0WFA-0AerkjQm4X4oDEhqA17QIAKNjXpagHBXmO_U`.
2021-03-08 18:12:59 +05:30
1. Request authorization code. To do that, you should redirect the user to the
`/oauth/authorize` page with the following query parameters:
```plaintext
2021-03-11 19:13:27 +05:30
https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=code&state=STATE&scope=REQUESTED_SCOPES&code_challenge=CODE_CHALLENGE&code_challenge_method=S256
2021-03-08 18:12:59 +05:30
```
This page asks the user to approve the request from the app to access their
account based on the scopes specified in `REQUESTED_SCOPES`. The user is then
2022-03-02 08:16:31 +05:30
redirected back to the specified `REDIRECT_URI`. The [scope parameter](../integration/oauth_provider.md#authorized-applications)
2022-01-26 12:08:38 +05:30
is a space-separated list of scopes associated with the user.
2021-03-08 18:12:59 +05:30
For example,`scope=read_user+profile` requests the `read_user` and `profile` scopes.
The redirect includes the authorization `code`, for example:
```plaintext
2021-03-11 19:13:27 +05:30
https://example.com/oauth/redirect?code=1234567890&state=STATE
2021-03-08 18:12:59 +05:30
```
1. With the authorization `code` returned from the previous request (denoted as
`RETURNED_CODE` in the following example), you can request an `access_token`, with
any HTTP client. The following example uses Ruby's `rest-client`:
```ruby
2022-04-04 11:22:00 +05:30
parameters = 'client_id=APP_ID&code=RETURNED_CODE&grant_type=authorization_code&redirect_uri=REDIRECT_URI&code_verifier=CODE_VERIFIER'
2021-03-08 18:12:59 +05:30
RestClient.post 'https://gitlab.example.com/oauth/token', parameters
```
Example response:
```json
{
"access_token": "de6780bc506a0446309bd9362820ba8aed28aa506c71eedbe1c5c4f9dd350e54",
"token_type": "bearer",
"expires_in": 7200,
"refresh_token": "8257e65c97202ed1726cf9571600918f3bffb2544b26e00a61df9897668c33a1",
"created_at": 1607635748
}
```
2022-01-26 12:08:38 +05:30
2021-10-27 15:23:28 +05:30
1. To retrieve a new `access_token`, use the `refresh_token` parameter. Refresh tokens may
be used even after the `access_token` itself expires. This request:
- Invalidates the existing `access_token` and `refresh_token`.
- Sends new tokens in the response.
```ruby
2022-04-04 11:22:00 +05:30
parameters = 'client_id=APP_ID&refresh_token=REFRESH_TOKEN&grant_type=refresh_token&redirect_uri=REDIRECT_URI&code_verifier=CODE_VERIFIER'
2021-10-27 15:23:28 +05:30
RestClient.post 'https://gitlab.example.com/oauth/token', parameters
```
Example response:
2021-11-11 11:23:49 +05:30
2021-10-27 15:23:28 +05:30
```json
{
"access_token": "c97d1fe52119f38c7f67f0a14db68d60caa35ddc86fd12401718b649dcfa9c68",
"token_type": "bearer",
"expires_in": 7200,
"refresh_token": "803c1fd487fec35562c205dac93e9d8e08f9d3652a24079d704df3039df1158f",
"created_at": 1628711391
}
```
2021-03-08 18:12:59 +05:30
NOTE:
The `redirect_uri` must match the `redirect_uri` used in the original
authorization request.
You can now make requests to the API with the access token.
### Authorization code flow
2015-04-26 12:48:37 +05:30
2021-02-22 17:27:13 +05:30
NOTE:
2022-11-25 23:54:43 +05:30
Check the [RFC spec](https://www.rfc-editor.org/rfc/rfc6749#section-4.1) for a
2019-02-15 15:39:39 +05:30
detailed flow description.
2016-09-13 17:45:13 +05:30
2021-03-08 18:12:59 +05:30
The authorization code flow is essentially the same as
[authorization code flow with PKCE](#authorization-code-with-proof-key-for-code-exchange-pkce),
2015-04-26 12:48:37 +05:30
2021-03-11 19:13:27 +05:30
Before starting the flow, generate the `STATE`. It is a value that can't be predicted
used by the client to maintain state between the request and callback. It should also
be used as a CSRF token.
2019-02-15 15:39:39 +05:30
1. Request authorization code. To do that, you should redirect the user to the
2021-03-11 19:13:27 +05:30
`/oauth/authorize` page with the following query parameters:
2015-04-26 12:48:37 +05:30
2020-04-08 14:13:33 +05:30
```plaintext
2021-03-08 18:12:59 +05:30
https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=code&state=STATE&scope=REQUESTED_SCOPES
2019-02-15 15:39:39 +05:30
```
2016-09-13 17:45:13 +05:30
2021-03-11 19:13:27 +05:30
This page asks the user to approve the request from the app to access their
account based on the scopes specified in `REQUESTED_SCOPES`. The user is then
2022-03-02 08:16:31 +05:30
redirected back to the specified `REDIRECT_URI`. The [scope parameter](../integration/oauth_provider.md#authorized-applications)
2022-01-26 12:08:38 +05:30
is a space-separated list of scopes associated with the user.
2021-03-11 19:13:27 +05:30
For example,`scope=read_user+profile` requests the `read_user` and `profile` scopes.
The redirect includes the authorization `code`, for example:
2016-09-13 17:45:13 +05:30
2020-04-08 14:13:33 +05:30
```plaintext
2021-03-08 18:12:59 +05:30
https://example.com/oauth/redirect?code=1234567890&state=STATE
2019-02-15 15:39:39 +05:30
```
2016-09-13 17:45:13 +05:30
2021-03-11 19:13:27 +05:30
1. With the authorization `code` returned from the previous request (shown as
`RETURNED_CODE` in the following example), you can request an `access_token`, with
any HTTP client. The following example uses Ruby's `rest-client`:
2016-09-13 17:45:13 +05:30
2019-02-15 15:39:39 +05:30
```ruby
parameters = 'client_id=APP_ID&client_secret=APP_SECRET&code=RETURNED_CODE&grant_type=authorization_code&redirect_uri=REDIRECT_URI'
2020-11-24 15:15:51 +05:30
RestClient.post 'https://gitlab.example.com/oauth/token', parameters
2019-02-15 15:39:39 +05:30
```
2015-04-26 12:48:37 +05:30
2019-02-15 15:39:39 +05:30
Example response:
2015-04-26 12:48:37 +05:30
2019-02-15 15:39:39 +05:30
```json
{
"access_token": "de6780bc506a0446309bd9362820ba8aed28aa506c71eedbe1c5c4f9dd350e54",
"token_type": "bearer",
"expires_in": 7200,
2021-03-08 18:12:59 +05:30
"refresh_token": "8257e65c97202ed1726cf9571600918f3bffb2544b26e00a61df9897668c33a1",
"created_at": 1607635748
2019-02-15 15:39:39 +05:30
}
```
2022-01-26 12:08:38 +05:30
2021-10-27 15:23:28 +05:30
1. To retrieve a new `access_token`, use the `refresh_token` parameter. Refresh tokens may
be used even after the `access_token` itself expires. This request:
- Invalidates the existing `access_token` and `refresh_token`.
- Sends new tokens in the response.
```ruby
parameters = 'client_id=APP_ID&client_secret=APP_SECRET&refresh_token=REFRESH_TOKEN&grant_type=refresh_token&redirect_uri=REDIRECT_URI'
RestClient.post 'https://gitlab.example.com/oauth/token', parameters
```
Example response:
```json
{
"access_token": "c97d1fe52119f38c7f67f0a14db68d60caa35ddc86fd12401718b649dcfa9c68",
"token_type": "bearer",
"expires_in": 7200,
"refresh_token": "803c1fd487fec35562c205dac93e9d8e08f9d3652a24079d704df3039df1158f",
"created_at": 1628711391
}
```
2015-04-26 12:48:37 +05:30
2021-02-22 17:27:13 +05:30
NOTE:
2019-02-15 15:39:39 +05:30
The `redirect_uri` must match the `redirect_uri` used in the original
authorization request.
2015-04-26 12:48:37 +05:30
You can now make requests to the API with the access token returned.
2019-02-15 15:39:39 +05:30
### Resource owner password credentials flow
2015-04-26 12:48:37 +05:30
2021-02-22 17:27:13 +05:30
NOTE:
2022-11-25 23:54:43 +05:30
Check the [RFC spec](https://www.rfc-editor.org/rfc/rfc6749#section-4.3) for a
2019-02-15 15:39:39 +05:30
detailed flow description.
2016-08-24 12:49:21 +05:30
2021-02-22 17:27:13 +05:30
NOTE:
2022-10-11 01:57:18 +05:30
The Resource Owner Password Credentials is disabled for users with
2022-08-27 11:52:29 +05:30
[two-factor authentication](../user/profile/account/two_factor_authentication.md) turned on.
2019-02-15 15:39:39 +05:30
These users can access the API using [personal access tokens](../user/profile/personal_access_tokens.md)
instead.
2016-08-24 12:49:21 +05:30
2019-02-15 15:39:39 +05:30
In this flow, a token is requested in exchange for the resource owner credentials
(username and password).
2015-04-26 12:48:37 +05:30
2019-02-15 15:39:39 +05:30
The credentials should only be used when:
2016-09-13 17:45:13 +05:30
2019-02-15 15:39:39 +05:30
- There is a high degree of trust between the resource owner and the client. For
example, the client is part of the device operating system or a highly
privileged application.
- Other authorization grant types are not available (such as an authorization code).
2017-09-10 17:25:29 +05:30
2021-02-22 17:27:13 +05:30
WARNING:
2019-02-15 15:39:39 +05:30
Never store the user's credentials and only use this grant type when your client
is deployed to a trusted environment, in 99% of cases
[personal access tokens](../user/profile/personal_access_tokens.md) are a better
choice.
2017-09-10 17:25:29 +05:30
2019-02-15 15:39:39 +05:30
Even though this grant type requires direct client access to the resource owner
credentials, the resource owner credentials are used for a single request and
are exchanged for an access token. This grant type can eliminate the need for
the client to store the resource owner credentials for future use, by exchanging
the credentials with a long-lived access token or refresh token.
2015-04-26 12:48:37 +05:30
2019-02-15 15:39:39 +05:30
To request an access token, you must make a POST request to `/oauth/token` with
the following parameters:
```json
2015-04-26 12:48:37 +05:30
{
"grant_type" : "password",
"username" : "user@example.com",
2016-11-03 12:29:30 +05:30
"password" : "secret"
2015-04-26 12:48:37 +05:30
}
```
2019-02-15 15:39:39 +05:30
Example cURL request:
2021-04-17 20:07:23 +05:30
```shell
echo 'grant_type=password&username=<your_username>&password=<your_password>' > auth.txt
curl --data "@auth.txt" --request POST "https://gitlab.example.com/oauth/token"
```
You can also use this grant flow with registered OAuth applications, by using
HTTP Basic Authentication with the application's `client_id` and `client_secret`:
2020-03-13 15:44:24 +05:30
```shell
2019-02-15 15:39:39 +05:30
echo 'grant_type=password&username=<your_username>&password=<your_password>' > auth.txt
2021-09-04 01:27:46 +05:30
curl --data "@auth.txt" --user client_id:client_secret \
--request POST "https://gitlab.example.com/oauth/token"
2019-02-15 15:39:39 +05:30
```
2021-06-08 01:23:25 +05:30
Then, you receive a response containing the access token:
2015-04-26 12:48:37 +05:30
2020-04-08 14:13:33 +05:30
```json
2015-04-26 12:48:37 +05:30
{
"access_token": "1f0af717251950dbd4d73154fdf0a474a5c5119adad999683f5b450c460726aa",
"token_type": "bearer",
"expires_in": 7200
}
```
2020-06-23 00:09:42 +05:30
By default, the scope of the access token is `api`, which provides complete read/write access.
2019-02-15 15:39:39 +05:30
For testing, you can use the `oauth2` Ruby gem:
2015-04-26 12:48:37 +05:30
2020-04-08 14:13:33 +05:30
```ruby
2020-11-24 15:15:51 +05:30
client = OAuth2::Client.new('the_client_id', 'the_client_secret', :site => "https://example.com")
2016-11-03 12:29:30 +05:30
access_token = client.password.get_token('user@example.com', 'secret')
2015-04-26 12:48:37 +05:30
puts access_token.token
```
2016-08-24 12:49:21 +05:30
2019-09-30 21:07:59 +05:30
## Access GitLab API with `access token`
2017-09-10 17:25:29 +05:30
2019-02-15 15:39:39 +05:30
The `access token` allows you to make requests to the API on behalf of a user.
You can pass the token either as GET parameter:
2020-04-08 14:13:33 +05:30
```plaintext
2017-09-10 17:25:29 +05:30
GET https://gitlab.example.com/api/v4/user?access_token=OAUTH-TOKEN
```
or you can put the token to the Authorization header:
2020-04-08 14:13:33 +05:30
```shell
2020-06-23 00:09:42 +05:30
curl --header "Authorization: Bearer OAUTH-TOKEN" "https://gitlab.example.com/api/v4/user"
2017-09-10 17:25:29 +05:30
```
2020-03-13 15:44:24 +05:30
2022-03-02 08:16:31 +05:30
## Access Git over HTTPS with `access token`
A token with [scope](../integration/oauth_provider.md#authorized-applications)
`read_repository` or `write_repository` can access Git over HTTPS. Use the token as the password.
2022-10-11 01:57:18 +05:30
The username must be `oauth2`, not your username:
```plaintext
https://oauth2:<your_access_token>@gitlab.example.com/project_path/project_name.git
```
2022-03-02 08:16:31 +05:30
2021-11-11 11:23:49 +05:30
## Retrieve the token information
2020-03-13 15:44:24 +05:30
2021-11-11 11:23:49 +05:30
To verify the details of a token, use the `token/info` endpoint provided by the
Doorkeeper gem. For more information, see
[`/oauth/token/info`](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo).
2020-03-13 15:44:24 +05:30
2020-04-08 14:13:33 +05:30
You must supply the access token, either:
2020-03-13 15:44:24 +05:30
2020-04-08 14:13:33 +05:30
- As a parameter:
2020-03-13 15:44:24 +05:30
2020-04-08 14:13:33 +05:30
```plaintext
GET https://gitlab.example.com/oauth/token/info?access_token=<OAUTH-TOKEN>
```
2020-03-13 15:44:24 +05:30
2020-04-08 14:13:33 +05:30
- In the Authorization header:
2020-03-13 15:44:24 +05:30
2020-04-08 14:13:33 +05:30
```shell
2020-06-23 00:09:42 +05:30
curl --header "Authorization: Bearer <OAUTH-TOKEN>" "https://gitlab.example.com/oauth/token/info"
2020-04-08 14:13:33 +05:30
```
The following is an example response:
2020-03-13 15:44:24 +05:30
```json
{
"resource_owner_id": 1,
"scope": ["api"],
"expires_in": null,
"application": {"uid": "1cb242f495280beb4291e64bee2a17f330902e499882fe8e1e2aa875519cab33"},
"created_at": 1575890427
}
```
2020-04-08 14:13:33 +05:30
### Deprecated fields
The fields `scopes` and `expires_in_seconds` are included in the response.
2022-04-04 11:22:00 +05:30
These fields are aliases for `scope` and `expires_in` respectively, and have been included to
2020-04-08 14:13:33 +05:30
prevent breaking changes introduced in [doorkeeper 5.0.2](https://github.com/doorkeeper-gem/doorkeeper/wiki/Migration-from-old-versions#from-4x-to-5x).
2021-06-08 01:23:25 +05:30
Don't rely on these fields as they are slated for removal in a later release.
2021-04-17 20:07:23 +05:30
2021-11-18 22:05:49 +05:30
## Revoke a token
To revoke a token, use the `revoke` endpoint. The API returns a 200 response code and an empty
JSON hash to indicate success.
```ruby
parameters = 'client_id=APP_ID&client_secret=APP_SECRET&token=TOKEN'
RestClient.post 'https://gitlab.example.com/oauth/revoke', parameters
```
2021-11-11 11:23:49 +05:30
## OAuth 2.0 tokens and GitLab registries
2021-04-17 20:07:23 +05:30
2021-11-11 11:23:49 +05:30
Standard OAuth 2.0 tokens support different degrees of access to GitLab
registries, as they:
2021-04-17 20:07:23 +05:30
- Do not allow users to authenticate to:
- The GitLab [Container registry](../user/packages/container_registry/index.md#authenticate-with-the-container-registry).
- Packages listed in the GitLab [Package registry](../user/packages/package_registry/index.md).
- Allow users to get, list, and delete registries through
the [Container registry API](container_registry.md).