BigW Consortium Gitlab

oauth2.md 7.35 KB
Newer Older
1
# GitLab as an OAuth2 provider
2

3
This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow other services access Gitlab resources on user's behalf. 
4

5 6
If you want GitLab to be an OAuth authentication service provider to sign into other services please see the [OAuth2 provider](../integration/oauth_provider.md)
documentation.
7

8
This functionality is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper). 
9

10
## Supported OAuth2 Flows
11

12
Gitlab currently supports following authorization flows: 
13

14 15 16
* *Web Application Flow* - Most secure and common type of flow, designed for the applications with secure server-side.
* *Implicit 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.
17

18
Please refer to [OAuth RFC](https://tools.ietf.org/html/rfc6749) to find out in details how all those flows work and pick the right one for your use case.
19

20 21 22
Both *web application* and *implicit* flows require `application` to be registered first via `/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 `application` credentials: _Application ID_ and _Client Secret_ - **keep them secure**.
23

24 25 26
>**Important:** OAuth specification advises sending `state` parameter with each request to `/oauth/authorize`. We highly recommended to send a unique 
value with each request and validate it against the one in redirect request. This is important to prevent [CSRF attacks]. The `state` param really should 
have been a requirement in the standard!
27

28
In the following sections you will find detailed instructions on how to obtain authorization with each flow. 
29

30
### Web Application Flow 
31

32
Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.1) for a detailed flow description
33

34
#### 1. Requesting authorization code
35

36
To request the authorization code, you should redirect the user to the `/oauth/authorize` endpoint with following GET parameters:
37 38

```
39
https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=code&state=YOUR_UNIQUE_STATE_HASH
40 41
```

42 43
This will ask the user to approve the applications access to their account and then redirect back to the `REDIRECT_URI` you provided. The redirect will
include the GET `code` parameter, for example:
44

45
`http://myapp.com/oauth/redirect?code=1234567890&state=YOUR_UNIQUE_STATE_HASH`
46

47 48
You should then use the `code` to request an access token.

49
#### 2. Requesting access token
50

51 52
Once you have the authorization code you can request an `access_token` using the code, to do that you can use any HTTP client. In the following example, 
we are using Ruby's `rest-client`:
53 54

```
55
parameters = 'client_id=APP_ID&client_secret=APP_SECRET&code=RETURNED_CODE&grant_type=authorization_code&redirect_uri=REDIRECT_URI'
56
RestClient.post 'http://gitlab.example.com/oauth/token', parameters
57 58 59 60

# The response will be
{
 "access_token": "de6780bc506a0446309bd9362820ba8aed28aa506c71eedbe1c5c4f9dd350e54",
61
 "token_type": "bearer",
62 63 64 65
 "expires_in": 7200,
 "refresh_token": "8257e65c97202ed1726cf9571600918f3bffb2544b26e00a61df9897668c33a1"
}
```
66 67
>**Note:**
The `redirect_uri` must match the `redirect_uri` used in the original authorization request.
68 69 70 71

You can now make requests to the API with the access token returned.


72 73 74 75 76 77 78 79 80 81 82 83 84 85 86
### Implicit Grant

Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.2) for a detailed flow description.

Unlike the web flow, the client receives an `access token` immediately as a result of the authorization request. The flow does not use client secret 
or authorization code because all of the application code and storage is easily accessible, therefore __secrets__ can leak easily. 

>**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 access token before granting access to the data 
(see [/oauth/token/info](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo)). 
 

#### 1. Requesting access token

To request the access token, you should redirect the user to the `/oauth/authorize` endpoint using `token` response type:
87 88

```
89
https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=token&state=YOUR_UNIQUE_STATE_HASH
90 91
```

92 93
This will ask the user to approve the applications access to their account and then redirect back to the `REDIRECT_URI` you provided. The redirect 
will include a fragment with `access_token` as well as token details in GET parameters, for example:
94 95

```
96
http://myapp.com/oauth/redirect#access_token=ABCDExyz123&state=YOUR_UNIQUE_STATE_HASH&token_type=bearer&expires_in=3600
97 98
```

99
### Resource Owner Password Credentials
100

101
Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.3) for a detailed flow description.
102

103 104
> **Deprecation notice:** Starting in GitLab 8.11, the Resource Owner Password Credentials has been *disabled* for users with two-factor authentication 
turned on. These users can access the API using [personal access tokens] instead.
105

106
In this flow, a token is requested in exchange for the resource owner credentials (username and password).
107 108 109 110
The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g. the
client is part of the device operating system or a highly privileged application), and when other authorization grant types are not
available (such as an authorization code).

111
>**Important:**
112 113
Never store the users credentials and only use this grant type when your client is deployed to a trusted environment, in 99% of cases [personal access tokens] 
are a better choice.
114

115 116 117
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.
118 119 120 121

#### 1. Requesting access token

POST request to `/oauth/token` with parameters:
122 123 124 125 126

```
{
  "grant_type"    : "password",
  "username"      : "user@example.com",
127
  "password"      : "secret"
128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144
}
```

Then, you'll receive the access token back in the response:

```
{
  "access_token": "1f0af717251950dbd4d73154fdf0a474a5c5119adad999683f5b450c460726aa",
  "token_type": "bearer",
  "expires_in": 7200
}
```

For testing you can use the oauth2 ruby gem:

```
client = OAuth2::Client.new('the_client_id', 'the_client_secret', :site => "http://example.com")
145
access_token = client.password.get_token('user@example.com', 'secret')
146
puts access_token.token
147
```
148

149 150 151 152 153 154 155 156 157 158 159 160 161
##  Access Gitlab API with `access token`

The `access token` allows you to make requests to the API on a behalf of a user. You can pass the token either as GET parameter 
```
GET https://gitlab.example.com/api/v4/user?access_token=OAUTH-TOKEN
```

or you can put the token to the Authorization header:

```
curl --header "Authorization: Bearer OAUTH-TOKEN" https://gitlab.example.com/api/v4/user
```

162
[personal access tokens]: ../user/profile/personal_access_tokens.md
163
[CSRF attacks]: http://www.oauthsecurity.com/#user-content-authorization-code-flow