2016-09-28 08:41:39 +00:00
# GitLab as an OAuth2 provider
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
This document covers using the [OAuth2 ](https://oauth.net/2/ ) protocol to allow
other services to access GitLab resources on user's behalf.
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
If you want GitLab to be an OAuth authentication service provider to sign into
2020-05-04 15:09:38 +00:00
other services, see the [OAuth2 authentication service provider ](../integration/oauth_provider.md )
2019-01-14 03:46:01 +00:00
documentation. This functionality is based on the
[doorkeeper Ruby gem ](https://github.com/doorkeeper-gem/doorkeeper ).
2015-02-19 04:49:19 +00:00
2019-01-14 03:46:01 +00:00
## Supported OAuth2 flows
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
GitLab currently supports the following authorization flows:
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
- **Web application flow:** Most secure and common type of flow, designed for
applications with secure server-side.
- **Implicit grant flow:** This flow is designed for user-agent only apps (e.g., single
page web application running on GitLab Pages).
- **Resource owner password credentials flow:** To be used **only** for securely
hosted, first-party services.
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
Refer to the [OAuth RFC ](https://tools.ietf.org/html/rfc6749 ) to find out
how all those flows work and pick the right one for your use case.
2016-08-04 13:25:37 +00:00
2019-01-14 03:46:01 +00:00
Both **web application** and **implicit grant** flows require `application` to be
registered first via the `/profile/applications` page in your user's account.
During registration, by enabling proper scopes, you can limit the range of
resources which the `application` can access. Upon creation, you'll obtain the
`application` credentials: _Application ID_ and _Client Secret_ - **keep them secure** .
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
CAUTION: **Important:**
OAuth specification advises sending the `state` parameter with each request to
`/oauth/authorize` . We highly recommended sending a unique value with each request
and validate it against the one in the redirect request. This is important in
2020-03-23 03:09:21 +00:00
order to prevent [CSRF attacks ](https://wiki.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF )).
2019-01-14 03:46:01 +00:00
The `state` parameter really should have been a requirement in the standard!
2016-08-04 13:25:37 +00:00
2019-01-14 03:46:01 +00:00
In the following sections you will find detailed instructions on how to obtain
authorization with each flow.
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
### Web application flow
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
NOTE: **Note:**
Check the [RFC spec ](https://tools.ietf.org/html/rfc6749#section-4.1 ) for a
detailed flow description.
2016-08-04 13:25:37 +00:00
2019-01-14 03:46:01 +00:00
The web application flow is:
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
1. Request authorization code. To do that, you should redirect the user to the
`/oauth/authorize` endpoint with the following GET parameters:
2015-01-12 23:30:34 +00:00
2020-03-06 03:08:08 +00:00
```plaintext
2019-07-27 00:28:19 +00:00
https://gitlab.example.com/oauth/authorize?client_id=APP_ID& redirect_uri=REDIRECT_URI& response_type=code& state=YOUR_UNIQUE_STATE_HASH& scope=REQUESTED_SCOPES
2019-01-14 03:46:01 +00:00
```
2016-08-04 13:25:37 +00:00
2019-07-27 00:28:19 +00:00
This will ask the user to approve the applications access to their account
based on the scopes specified in `REQUESTED_SCOPES` and then redirect back to
the `REDIRECT_URI` you provided. The [scope parameter ](https://github.com/doorkeeper-gem/doorkeeper/wiki/Using-Scopes#requesting-particular-scopes )
is a space separated list of scopes you want to have access to (e.g. `scope=read_user+profile`
would request `read_user` and `profile` scopes). The redirect will
2019-01-14 03:46:01 +00:00
include the GET `code` parameter, for example:
2016-08-04 13:25:37 +00:00
2020-03-06 03:08:08 +00:00
```plaintext
2020-08-21 18:10:24 +00:00
https://example.com/oauth/redirect?code=1234567890& state=YOUR_UNIQUE_STATE_HASH
2019-01-14 03:46:01 +00:00
```
2016-08-04 13:25:37 +00:00
2019-01-14 03:46:01 +00:00
You should then use `code` to request an access token.
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
1. Once you have the authorization code you can request an `access_token` using the
code. You can do that by using any HTTP client. In the following example,
we are using Ruby's `rest-client` :
2016-08-04 13:25:37 +00:00
2019-01-14 03:46:01 +00:00
```ruby
parameters = 'client_id=APP_ID& client_secret=APP_SECRET& code=RETURNED_CODE& grant_type=authorization_code& redirect_uri=REDIRECT_URI'
2020-08-21 18:10:24 +00:00
RestClient.post 'https://gitlab.example.com/oauth/token', parameters
2019-01-14 03:46:01 +00:00
```
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
Example response:
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
```json
{
"access_token": "de6780bc506a0446309bd9362820ba8aed28aa506c71eedbe1c5c4f9dd350e54",
"token_type": "bearer",
"expires_in": 7200,
"refresh_token": "8257e65c97202ed1726cf9571600918f3bffb2544b26e00a61df9897668c33a1"
}
```
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
NOTE: **Note:**
The `redirect_uri` must match the `redirect_uri` used in the original
authorization request.
2015-01-12 23:30:34 +00:00
You can now make requests to the API with the access token returned.
2019-01-14 03:46:01 +00:00
### Implicit grant flow
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
NOTE: **Note:**
Check the [RFC spec ](https://tools.ietf.org/html/rfc6749#section-4.2 ) for a
detailed flow description.
2018-11-13 06:07:16 +00:00
2019-01-14 03:46:01 +00:00
CAUTION: **Important:**
Avoid using this flow for applications that store data outside of the GitLab
instance. If you do, make sure to verify `application id` associated with the
access token before granting access to the data
2020-04-08 03:09:31 +00:00
(see [`/oauth/token/info` ](#retrieving-the-token-information )).
2017-07-07 14:52:45 +00:00
2019-01-14 03:46:01 +00:00
Unlike the web flow, the client receives an `access token` immediately as a
result of the authorization request. The flow does not use the client secret
or the authorization code because all of the application code and storage is
easily accessible, therefore secrets can leak easily.
2017-07-07 14:52:45 +00:00
2019-01-14 03:46:01 +00:00
To request the access token, you should redirect the user to the
`/oauth/authorize` endpoint using `token` response type:
2015-01-12 23:30:34 +00:00
2020-02-28 00:09:08 +00:00
```plaintext
2019-07-27 00:28:19 +00:00
https://gitlab.example.com/oauth/authorize?client_id=APP_ID& redirect_uri=REDIRECT_URI& response_type=token& state=YOUR_UNIQUE_STATE_HASH& scope=REQUESTED_SCOPES
2015-01-12 23:30:34 +00:00
```
2019-07-27 00:28:19 +00:00
This will ask the user to approve the applications access to their account
based on the scopes specified in `REQUESTED_SCOPES` and then redirect back to
the `REDIRECT_URI` you provided. The [scope parameter ](https://github.com/doorkeeper-gem/doorkeeper/wiki/Using-Scopes#requesting-particular-scopes )
is a space separated list of scopes you want to have access to (e.g. `scope=read_user+profile`
would request `read_user` and `profile` scopes). The redirect
2019-01-14 03:46:01 +00:00
will include a fragment with `access_token` as well as token details in GET
parameters, for example:
2015-01-12 23:30:34 +00:00
2020-02-28 00:09:08 +00:00
```plaintext
2020-08-21 18:10:24 +00:00
https://example.com/oauth/redirect#access_token=ABCDExyz123& state=YOUR_UNIQUE_STATE_HASH& token_type=bearer& expires_in=3600
2015-01-12 23:30:34 +00:00
```
2019-01-14 03:46:01 +00:00
### Resource owner password credentials flow
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
NOTE: **Note:**
Check the [RFC spec ](https://tools.ietf.org/html/rfc6749#section-4.3 ) for a
detailed flow description.
2016-06-21 05:33:50 +00:00
2019-01-14 03:46:01 +00:00
NOTE: **Note:**
The Resource Owner Password Credentials is disabled for users with [two-factor
authentication](../user/profile/account/two_factor_authentication.md) turned on.
These users can access the API using [personal access tokens ](../user/profile/personal_access_tokens.md )
instead.
2016-06-21 05:33:50 +00:00
2019-01-14 03:46:01 +00:00
In this flow, a token is requested in exchange for the resource owner credentials
(username and password).
2015-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
The credentials should only be used when:
2016-08-04 13:25:37 +00:00
2019-01-14 03:46:01 +00:00
- 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-07-07 14:52:45 +00:00
2019-01-14 03:46:01 +00:00
CAUTION: **Important:**
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-07-07 14:52:45 +00:00
2019-01-14 03:46:01 +00:00
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-01-12 23:30:34 +00:00
2019-01-14 03:46:01 +00:00
To request an access token, you must make a POST request to `/oauth/token` with
the following parameters:
```json
2015-01-12 23:30:34 +00:00
{
"grant_type" : "password",
"username" : "user@example.com",
2016-09-28 08:41:39 +00:00
"password" : "secret"
2015-01-12 23:30:34 +00:00
}
```
2020-05-28 21:08:22 +00:00
Also you must use HTTP Basic authentication using the `client_id` and`client_secret`
values to authenticate the client that performs a request.
2019-01-14 03:46:01 +00:00
Example cURL request:
2020-01-30 15:09:15 +00:00
```shell
2019-01-14 03:46:01 +00:00
echo 'grant_type=password& username=< your_username > & password=< your_password > ' > auth.txt
2020-05-28 21:08:22 +00:00
curl --data "@auth.txt" --user client_id:client_secret --request POST "https://gitlab.example.com/oauth/token"
2019-01-14 03:46:01 +00:00
```
2015-01-12 23:30:34 +00:00
Then, you'll receive the access token back in the response:
2020-02-28 00:09:08 +00:00
```json
2015-01-12 23:30:34 +00:00
{
"access_token": "1f0af717251950dbd4d73154fdf0a474a5c5119adad999683f5b450c460726aa",
"token_type": "bearer",
"expires_in": 7200
}
```
2020-05-28 21:08:22 +00:00
By default, the scope of the access token is `api` , which provides complete read/write access.
2019-01-14 03:46:01 +00:00
For testing, you can use the `oauth2` Ruby gem:
2015-01-12 23:30:34 +00:00
2020-02-28 00:09:08 +00:00
```ruby
2020-08-21 18:10:24 +00:00
client = OAuth2::Client.new('the_client_id', 'the_client_secret', :site => "https://example.com")
2016-09-28 08:41:39 +00:00
access_token = client.password.get_token('user@example.com', 'secret')
2015-01-12 23:30:34 +00:00
puts access_token.token
2015-02-03 23:18:40 +00:00
```
2016-06-21 05:33:50 +00:00
2019-07-09 03:28:41 +00:00
## Access GitLab API with `access token`
2017-07-07 14:52:45 +00:00
2019-01-14 03:46:01 +00:00
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-02-28 00:09:08 +00:00
```plaintext
2017-07-07 14:52:45 +00:00
GET https://gitlab.example.com/api/v4/user?access_token=OAUTH-TOKEN
```
or you can put the token to the Authorization header:
2020-02-28 00:09:08 +00:00
```shell
2020-05-28 00:08:37 +00:00
curl --header "Authorization: Bearer OAUTH-TOKEN" "https://gitlab.example.com/api/v4/user"
2017-07-07 14:52:45 +00:00
```
2020-02-18 03:08:54 +00:00
2020-04-08 03:09:31 +00:00
## Retrieving the token information
2020-02-18 03:08:54 +00:00
2020-02-19 03:08:47 +00:00
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-02-18 03:08:54 +00:00
2020-02-19 03:08:47 +00:00
You must supply the access token, either:
2020-02-18 03:08:54 +00:00
2020-02-19 03:08:47 +00:00
- As a parameter:
2020-02-18 03:08:54 +00:00
2020-02-28 00:09:08 +00:00
```plaintext
2020-02-19 03:08:47 +00:00
GET https://gitlab.example.com/oauth/token/info?access_token=< OAUTH-TOKEN >
```
2020-02-18 03:08:54 +00:00
2020-02-19 03:08:47 +00:00
- In the Authorization header:
2020-02-18 03:08:54 +00:00
2020-02-19 03:08:47 +00:00
```shell
2020-05-28 00:08:37 +00:00
curl --header "Authorization: Bearer < OAUTH-TOKEN > " "https://gitlab.example.com/oauth/token/info"
2020-02-19 03:08:47 +00:00
```
The following is an example response:
2020-02-18 03:08:54 +00:00
```json
{
"resource_owner_id": 1,
"scope": ["api"],
"expires_in": null,
"application": {"uid": "1cb242f495280beb4291e64bee2a17f330902e499882fe8e1e2aa875519cab33"},
"created_at": 1575890427
}
```
2020-02-19 03:08:47 +00:00
### Deprecated fields
The fields `scopes` and `expires_in_seconds` are included in the response.
These are aliases for `scope` and `expires_in` respectively, and have been included to
prevent breaking changes introduced in [doorkeeper 5.0.2 ](https://github.com/doorkeeper-gem/doorkeeper/wiki/Migration-from-old-versions#from-4x-to-5x ).
Don't rely on these fields as they will be removed in a later release.