@@ -8,7 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
...
@@ -8,7 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
## List all deploy keys
## List all deploy keys
Get a list of all deploy keys across all projects of the GitLab instance. This endpoint requires administrator access and is not available on GitLab.com.
Get a list of all deploy keys across all projects of the GitLab instance. This
endpoint requires an administrator role and is not available on GitLab.com.
```plaintext
```plaintext
GET /deploy_keys
GET /deploy_keys
...
@@ -74,7 +75,7 @@ Example response:
...
@@ -74,7 +75,7 @@ Example response:
]
]
```
```
## Single deploy key
## Get a single deploy key
Get a single key.
Get a single key.
...
@@ -213,10 +214,10 @@ Example response:
...
@@ -213,10 +214,10 @@ Example response:
}
}
```
```
## Adding deploy keys to multiple projects
## Add deploy keys to multiple projects
If you want to easily add the same deploy key to multiple projects in the same
If you want to add the same deploy key to multiple projects in the same
group, this can be achieved quite easily with the API.
group, this can be achieved with the API.
First, find the ID of the projects you're interested in, by either listing all
First, find the ID of the projects you're interested in, by either listing all
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/#designated-technical-writers
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/#designated-technical-writers
---
---
# GitLab as an OAuth2 provider
# GitLab as an OAuth 2.0 provider
This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow
This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow
other services to access GitLab resources on user's behalf.
other services to access GitLab resources on user's behalf.
...
@@ -15,9 +15,9 @@ other services, see the [OAuth2 authentication service provider](../integration/
...
@@ -15,9 +15,9 @@ other services, see the [OAuth2 authentication service provider](../integration/
GitLab currently supports the following authorization flows:
GitLab supports the following authorization flows:
-**Authorization code with [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636):**
-**Authorization code with [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636):**
Most secure. Without PKCE, you'd have to include client secrets on mobile clients,
Most secure. Without PKCE, you'd have to include client secrets on mobile clients,
...
@@ -26,14 +26,13 @@ GitLab currently supports the following authorization flows:
...
@@ -26,14 +26,13 @@ GitLab currently supports the following authorization flows:
server-side apps.
server-side apps.
-**Implicit grant:** Originally designed for user-agent only apps, such as
-**Implicit grant:** Originally designed for user-agent only apps, such as
single page web apps running on GitLab Pages).
single page web apps running on GitLab Pages).
The [IETF](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2)
The [Internet Engineering Task Force (IETF)](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2)
recommends against Implicit grant flow.
recommends against Implicit grant flow.
-**Resource owner password credentials:** To be used **only** for securely
-**Resource owner password credentials:** To be used **only** for securely
hosted, first-party services. GitLab recommends against use of this flow.
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
The draft specification for [OAuth 2.1](https://oauth.net/2.1/) specifically omits both the
Implicit grant and Resource Owner Password Credentials flows.
Implicit grant and Resource Owner Password Credentials flows. It will be deprecated in the next OAuth specification version.
it will be deprecated in the next OAuth specification version.
Refer to the [OAuth RFC](https://tools.ietf.org/html/rfc6749) to find out
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.
how all those flows work and pick the right one for your use case.
...
@@ -57,7 +56,7 @@ parameter, which are securely bound to the user agent", with each request to the
...
@@ -57,7 +56,7 @@ parameter, which are securely bound to the user agent", with each request to the
For production, please use HTTPS for your `redirect_uri`.
For production, please use HTTPS for your `redirect_uri`.
For development, GitLab allows insecure HTTP redirect URIs.
For development, GitLab allows insecure HTTP redirect URIs.
As OAuth2 bases its security entirely on the transport layer, you should not use unprotected
As OAuth 2.0 bases its security entirely on the transport layer, you should not use unprotected
URIs. For more information, see the [OAuth 2.0 RFC](https://tools.ietf.org/html/rfc6749#section-3.1.2.1)
URIs. For more information, see the [OAuth 2.0 RFC](https://tools.ietf.org/html/rfc6749#section-3.1.2.1)
and the [OAuth 2.0 Threat Model RFC](https://tools.ietf.org/html/rfc6819#section-4.4.2.1).
and the [OAuth 2.0 Threat Model RFC](https://tools.ietf.org/html/rfc6819#section-4.4.2.1).
These factors are particularly important when using the
These factors are particularly important when using the
...
@@ -245,12 +244,13 @@ scheduled to be removed for existing applications.
...
@@ -245,12 +244,13 @@ scheduled to be removed for existing applications.
We recommend that you use [Authorization code with PKCE](#authorization-code-with-proof-key-for-code-exchange-pkce) instead. If you choose to use Implicit flow, be sure to verify the
We recommend that you use [Authorization code with PKCE](#authorization-code-with-proof-key-for-code-exchange-pkce) instead. If you choose to use Implicit flow, be sure to verify the
`application id` (or `client_id`) associated with the access token before granting
`application id` (or `client_id`) associated with the access token before granting
access to the data, as described in [Retrieving the token information](#retrieving-the-token-information)).
access to the data. To learn more, read
[Retrieving the token information](#retrieve-the-token-information)).
Unlike the authorization code flow, the client receives an `access token`
Unlike the authorization code flow, the client receives an `access token`
immediately as a result of the authorization request. The flow does not use
immediately as a result of the authorization request. The flow does not use the
the client secret or the authorization code because all of the application code
client secret or the authorization code, as the application
and storage is easily accessible on client browsers and mobile devices.
code and storage is accessible on client browsers and mobile devices.
To request the access token, you should redirect the user to the
To request the access token, you should redirect the user to the
`/oauth/authorize` endpoint using `token` response type:
`/oauth/authorize` endpoint using `token` response type:
...
@@ -367,10 +367,11 @@ or you can put the token to the Authorization header:
...
@@ -367,10 +367,11 @@ or you can put the token to the Authorization header:
To verify the details of a token, use the `token/info` endpoint provided by the Doorkeeper gem.
To verify the details of a token, use the `token/info` endpoint provided by the
For more information, see [`/oauth/token/info`](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo).
