Incorporated Acrolinx feedback

Author: JimVance

articles/active-directory/develop/active-directory-v2-protocols.md

@@ -18,7 +18,7 @@ ms.custom: aaddev
 
 # OAuth 2.0 and OpenID Connect protocols on Microsoft identity platform
 
-The Microsoft identity platform endpoint for identity-as-a-service with industry standard protocols, OpenID Connect (OIDC) and OAuth 2.0. While the service is standards-compliant, there can be subtle differences between any two implementations of these protocols. The information here will be useful if you choose to write your code by directly sending and handling HTTP requests or use a third party open-source library, rather than using one of our [open-source libraries](reference-v2-libraries.md).
+The Microsoft identity platform endpoint for identity-as-a-service with industry standard protocols, OpenID Connect (OIDC) and OAuth 2.0. While the service is standards-compliant, there can be subtle differences between any two implementations of these protocols. The information here will be useful if you choose to write your code by directly sending and handling HTTP requests or use a third-party open-source library, rather than using one of our [open-source libraries](reference-v2-libraries.md).
 
 ## The basics
 
@@ -72,8 +72,7 @@ Further details of different types of tokens used in the Microsoft identity plat
 
 ## Protocols
 
-If you're ready to see some example requests, get started with one of the below tutorials. Each one corresponds to a particular authentication scenario. If you need help determining which is the right flow for you,
-check out [the types of apps you can build with Microsoft identity platform](v2-app-types.md).
+If you're ready to see some example requests, get started with one of the below tutorials. Each one corresponds to a particular authentication scenario. If you need help with determining which is the right flow for you, check out [the types of apps you can build with Microsoft identity platform](v2-app-types.md).
 
 * [Build mobile and native application with OAuth 2.0](v2-oauth2-auth-code-flow.md)
 * [Build web apps with OpenID Connect](v2-protocols-oidc.md)

articles/active-directory/develop/security-tokens.md

@@ -21,9 +21,9 @@ ms.custom: aaddev, identityplatformtop40, scenarios:getting-started
 
 A centralized identity provider is especially useful for apps that have users located around the globe that don't necessarily sign in from the enterprise's network. Microsoft identity platform authenticates users and provides security tokens, such as [access token](developer-glossary.md#access-token), [refresh token](developer-glossary.md#refresh-token), and [ID token](developer-glossary.md#id-token), that allow a [client application](developer-glossary.md#client-application) to access protected resources on a [resource server](developer-glossary.md#resource-server).
 
-An **access tokens** is a security token that is issued by an [authorization server](developer-glossary.md#authorization-server) as part of an [OAuth 2.0](active-directory-v2-protocols.md) flow. It contains information about the user and the app for which the token is intended; which can be used to access web APIs and other protected resources. To learn more about how Microsoft identity platform issues access tokens, see [Access tokens](access-tokens.md).
+An **access token** is a security token that is issued by an [authorization server](developer-glossary.md#authorization-server) as part of an [OAuth 2.0](active-directory-v2-protocols.md) flow. It contains information about the user and the app for which the token is intended; which can be used to access web APIs and other protected resources. To learn more about how Microsoft identity platform issues access tokens, see [Access tokens](access-tokens.md).
 
-Access tokens are only valid for a short period of time, so authorization servers will sometimes issue a **refresh tokens** at the same time the access token is issued. The client application can then exchange this refresh token for a new access token when needed. To learn more about how Microsoft identity platform uses refresh tokens to revoke permissions, see [Token revocation](access-tokens.md#token-revocation).
+Access tokens are only valid for a short period of time, so authorization servers will sometimes issue a **refresh token** at the same time the access token is issued. The client application can then exchange this refresh token for a new access token when needed. To learn more about how Microsoft identity platform uses refresh tokens to revoke permissions, see [Token revocation](access-tokens.md#token-revocation).
 
 **ID tokens** are sent to the client application as part of an [OpenID Connect](v2-protocols-oidc.md) flow. They can be sent along side or instead of an access token, and are used by the client to authenticate the user. To learn more about how Microsoft identity platform issues ID tokens, see [ID tokens](id-tokens.md).
 

articles/active-directory/develop/v2-oauth2-auth-code-flow.md

@@ -32,7 +32,7 @@ At a high level, the entire OAuth2 authentication flow for a native/mobile appli
 
 ## Request an authorization code
 
-The authorization code flow begins with the client directing the user to the `/authorize` endpoint. In this request, the client requests the `openid`, `offline_access`, and `https://graph.microsoft.com/mail.read ` permissions from from the user.  Some permissions are admin-restricted, for example writing data to an organization's directory by using `Directory.ReadWrite.All`. If your application requests access to one of these permissions from an organizational user, the user receives an error message that says they're not authorized to consent to your app's permissions. To request access to admin-restricted scopes, you should request them directly from a company administrator.  For more information, read [Admin-restricted permissions](v2-permissions-and-consent.md#admin-restricted-permissions).
+The authorization code flow begins with the client directing the user to the `/authorize` endpoint. In this request, the client requests the `openid`, `offline_access`, and `https://graph.microsoft.com/mail.read ` permissions from the user.  Some permissions are admin-restricted, for example writing data to an organization's directory by using `Directory.ReadWrite.All`. If your application requests access to one of these permissions from an organizational user, the user receives an error message that says they're not authorized to consent to your app's permissions. To request access to admin-restricted scopes, you should request them directly from a company administrator.  For more information, read [Admin-restricted permissions](v2-permissions-and-consent.md#admin-restricted-permissions).
 
 ```
 // Line breaks for legibility only
@@ -146,7 +146,7 @@ client_id=6731de76-14a6-49ae-97bc-6eba6914391e
 | `scope`      | required   | A space-separated list of scopes. The scopes requested in this leg must be equivalent to or a subset of the scopes requested in the first leg. The scopes must all be from a single resource, along with OIDC scopes (`profile`, `openid`, `email`). For a more detailed explanation of scopes, refer to [permissions, consent, and scopes](v2-permissions-and-consent.md). |
 | `code`          | required  | The authorization_code that you acquired in the first leg of the flow. |
 | `redirect_uri`  | required  | The same redirect_uri value that was used to acquire the authorization_code. |
-| `client_secret` | required for web apps | The application secret that you created in the app registration portal for your app. You shouldn't use the application secret in a native app because client_secrets can't be reliably stored on devices. It's required for web apps and web APIs, which have the ability to store the client_secret securely on the server side.  The client secret must be URL-encoded before being sent. For more information click [here](https://tools.ietf.org/html/rfc3986#page-12). |
+| `client_secret` | required for web apps | The application secret that you created in the app registration portal for your app. You shouldn't use the application secret in a native app because client_secrets can't be reliably stored on devices. It's required for web apps and web APIs, which have the ability to store the client_secret securely on the server side.  The client secret must be URL-encoded before being sent. For more information, see the [URI Generic Syntax specification](https://tools.ietf.org/html/rfc3986#page-12). |
 | `code_verifier` | optional  | The same code_verifier that was used to obtain the authorization_code. Required if PKCE was used in the authorization code grant request. For more information, see the [PKCE RFC](https://tools.ietf.org/html/rfc7636). |
 
 ### Successful response
@@ -260,7 +260,7 @@ client_id=6731de76-14a6-49ae-97bc-6eba6914391e
 | `grant_type`    | required    | Must be `refresh_token` for this leg of the authorization code flow. |
 | `scope`         | required    | A space-separated list of scopes. The scopes requested in this leg must be equivalent to or a subset of the scopes requested in the original authorization_code request leg. If the scopes specified in this request span multiple resource server, then the Microsoft identity platform endpoint will return a token for the resource specified in the first scope. For a more detailed explanation of scopes, refer to [permissions, consent, and scopes](v2-permissions-and-consent.md). |
 | `refresh_token` | required    | The refresh_token that you acquired in the second leg of the flow. |
-| `client_secret` | required for web apps | The application secret that you created in the app registration portal for your app. It should not be used in a native  app, because client_secrets can't be reliably stored on devices. It's required for web apps and web APIs, which have the ability to store the client_secret securely on the server side. This secret needs to be URL-Encoded, for more information click [here](https://tools.ietf.org/html/rfc3986#page-12). |
+| `client_secret` | required for web apps | The application secret that you created in the app registration portal for your app. It should not be used in a native  app, because client_secrets can't be reliably stored on devices. It's required for web apps and web APIs, which have the ability to store the client_secret securely on the server side. This secret needs to be URL-Encoded. For more information, see the [URI Generic Syntax specification](https://tools.ietf.org/html/rfc3986#page-12). |
 
 #### Successful response