diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-04-26 00:09:26 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-04-26 00:09:26 +0300 |
commit | 8b12578ec6fc51494fcd55995472c3208587cd3f (patch) | |
tree | 941b6f06ee5fe4cda05cb7ccf40194c2e6178a4f /doc/api | |
parent | 5220d8d2d6ed8f65056365cea8b0b7225e824a47 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/api')
-rw-r--r-- | doc/api/oauth2.md | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md index 2bcf86a031c..dfb91283b50 100644 --- a/doc/api/oauth2.md +++ b/doc/api/oauth2.md @@ -41,7 +41,7 @@ how all those flows work and pick the right one for your use case. Both **authorization code** (with or without PKCE) 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 +resources which the `application` can access. Upon creation, you obtain the `application` credentials: _Application ID_ and _Client Secret_ - **keep them secure**. ### Prevent CSRF attacks @@ -63,7 +63,7 @@ and the [OAuth 2.0 Threat Model RFC](https://tools.ietf.org/html/rfc6819#section These factors are particularly important when using the [Implicit grant flow](#implicit-grant-flow), where actual credentials are included in the `redirect_uri`. -In the following sections you will find detailed instructions on how to obtain +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) @@ -213,12 +213,12 @@ To request the access token, you should redirect the user to the 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 ``` -This will ask the user to approve the applications access to their account +This prompts 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 include a fragment with `access_token` as well as token details in GET +includes a fragment with `access_token` as well as token details in GET parameters, for example: ```plaintext @@ -285,7 +285,7 @@ echo 'grant_type=password&username=<your_username>&password=<your_password>' > a curl --data "@auth.txt" --user client_id:client_secret --request POST "https://gitlab.example.com/oauth/token" ``` -Then, you'll receive the access token back in the response: +Then, you receive a response containing the access token: ```json { @@ -358,7 +358,7 @@ 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. +Don't rely on these fields as they are slated for removal in a later release. ## OAuth2 tokens and GitLab registries |