Add latest changes from gitlab-org/gitlab@master

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