diff options
Diffstat (limited to 'doc/api/oauth2.md')
| -rw-r--r-- | doc/api/oauth2.md | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md index 0b7e0ba08eb..aca6ee74b15 100644 --- a/doc/api/oauth2.md +++ b/doc/api/oauth2.md @@ -2,7 +2,7 @@ type: reference, howto stage: Manage group: Authentication and Authorization -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 +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 --- # OAuth 2.0 identity provider API **(FREE)** @@ -37,7 +37,7 @@ For example, the `X-Requested-With` header can't be used for preflight requests. 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://www.rfc-editor.org/rfc/rfc7636):** Most secure. Without PKCE, you'd have to include client secrets on mobile clients, and is recommended for both client and server apps. - **Authorization code:** Secure and common flow. Recommended option for secure @@ -48,7 +48,7 @@ GitLab supports the following authorization flows: The draft specification for [OAuth 2.1](https://oauth.net/2.1/) specifically omits both the Implicit grant and Resource Owner Password Credentials flows. -Refer to the [OAuth RFC](https://tools.ietf.org/html/rfc6749) to find out +Refer to the [OAuth RFC](https://www.rfc-editor.org/rfc/rfc6749) to find out how all those flows work and pick the right one for your use case. Authorization code (with or without PKCE) flow requires `application` to be @@ -75,15 +75,15 @@ For production, please use HTTPS for your `redirect_uri`. For development, GitLab allows insecure HTTP redirect URIs. 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) -and the [OAuth 2.0 Threat Model RFC](https://tools.ietf.org/html/rfc6819#section-4.4.2.1). +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). In the following sections you can find detailed instructions on how to obtain authorization with each flow. ### Authorization code with Proof Key for Code Exchange (PKCE) -The [PKCE RFC](https://tools.ietf.org/html/rfc7636#section-1.1) includes a +The [PKCE RFC](https://www.rfc-editor.org/rfc/rfc7636#section-1.1) includes a detailed flow description, from authorization request through access token. The following steps describe our implementation of the flow. @@ -177,7 +177,7 @@ You can now make requests to the API with the access token. ### Authorization code flow NOTE: -Check the [RFC spec](https://tools.ietf.org/html/rfc6749#section-4.1) for a +Check the [RFC spec](https://www.rfc-editor.org/rfc/rfc6749#section-4.1) for a detailed flow description. The authorization code flow is essentially the same as @@ -257,7 +257,7 @@ You can now make requests to the API with the access token returned. ### Resource owner password credentials flow NOTE: -Check the [RFC spec](https://tools.ietf.org/html/rfc6749#section-4.3) for a +Check the [RFC spec](https://www.rfc-editor.org/rfc/rfc6749#section-4.3) for a detailed flow description. NOTE: |