explain use of csrf token in url query string parameter

Author: kengaderdus

articles/active-directory-b2c/tokens-overview.md

@@ -26,17 +26,17 @@ Azure AD B2C supports the [OAuth 2.0 and OpenID Connect protocols](protocols-ove
 
 The following tokens are used in communication with Azure AD B2C:
 
-- **ID token** - A JWT that contains claims that you can use to identify users in your application. This token is securely sent in HTTP requests for communication between two components of the same application or service. You can use the claims in an ID token as you see fit. They are commonly used to display account information or to make access control decisions in an application. ID tokens are signed, but they are not encrypted. When your application or API receives an ID token, it must validate the signature to prove that the token is authentic. Your application or API must also validate a few claims in the token to prove that it's valid. Depending on the scenario requirements, the claims validated by an application can vary, but your application must perform some common claim validations in every scenario.
+- **ID token** - A JWT that contains claims that you can use to identify users in your application. This token is securely sent in HTTP requests for communication between two components of the same application or service. You can use the claims in an ID token as you see fit. They're commonly used to display account information or to make access control decisions in an application. ID tokens are signed, but the're not encrypted. When your application or API receives an ID token, it must validate the signature to prove that the token is authentic. Your application or API must also validate a few claims in the token to prove that it's valid. Depending on the scenario requirements, the claims validated by an application can vary, but your application must perform some common claim validations in every scenario.
 
-- **Access token** -  A JWT that contains claims that you can use to identify the granted permissions to your APIs. Access tokens are signed, but they aren't encrypted. Access tokens are used to provide access to APIs and resource servers.  When your API receives an access token, it must validate the signature to prove that the token is authentic. Your API must also validate a few claims in the token to prove that it is valid. Depending on the scenario requirements, the claims validated by an application can vary, but your application must perform some common claim validations in every scenario.
+- **Access token** -  A JWT that contains claims that you can use to identify the granted permissions to your APIs. Access tokens are signed, but they aren't encrypted. Access tokens are used to provide access to APIs and resource servers.  When your API receives an access token, it must validate the signature to prove that the token is authentic. Your API must also validate a few claims in the token to prove that it's valid. Depending on the scenario requirements, the claims validated by an application can vary, but your application must perform some common claim validations in every scenario.
 
-- **Refresh token** - Refresh tokens are used to acquire new ID tokens and access tokens in an OAuth 2.0 flow. They provide your application with long-term access to resources on behalf of users without requiring interaction with those users. Refresh tokens are opaque to your application. They are issued by Azure AD B2C and can be inspected and interpreted only by Azure AD B2C. They are long-lived, but your application shouldn't be written with the expectation that a refresh token will last for a specific period of time. Refresh tokens can be invalidated at any moment for a variety of reasons. The only way for your application to know if a refresh token is valid is to attempt to redeem it by making a token request to Azure AD B2C. When you redeem a refresh token for a new token, you receive a new refresh token in the token response. Save the new refresh token. It replaces the refresh token that you previously used in the request. This action helps guarantee that your refresh tokens remain valid for as long as possible. Note that single-page applications using the authorization code flow with PKCE always have a refresh token lifetime of 24 hours. [Learn more about the security implications of refresh tokens in the browser](../active-directory/develop/reference-third-party-cookies-spas.md#security-implications-of-refresh-tokens-in-the-browser).
+- **Refresh token** - Refresh tokens are used to acquire new ID tokens and access tokens in an OAuth 2.0 flow. They provide your application with long-term access to resources on behalf of users without requiring interaction with those users. Refresh tokens are opaque to your application. They're issued by Azure AD B2C and can be inspected and interpreted only by Azure AD B2C. They're long-lived, but your application shouldn't be written with the expectation that a refresh token will last for a specific period of time. Refresh tokens can be invalidated at any moment for a variety of reasons. The only way for your application to know if a refresh token is valid is to attempt to redeem it by making a token request to Azure AD B2C. When you redeem a refresh token for a new token, you receive a new refresh token in the token response. Save the new refresh token. It replaces the refresh token that you previously used in the request. This action helps guarantee that your refresh tokens remain valid for as long as possible. Single-page applications using the authorization code flow with PKCE always have a refresh token lifetime of 24 hours. [Learn more about the security implications of refresh tokens in the browser](../active-directory/develop/reference-third-party-cookies-spas.md#security-implications-of-refresh-tokens-in-the-browser).
 
 ### Cross-Site Request Forgery token
 
-Azure AD B2C uses the [Synchronizer Token strategy](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern) to prevent Cross-Site Request Forgery (CSRF) attacks. When Azure AD B2C generates a CSRF token, it puts the token in a cookie as `x-ms-cpim-csrf`, and in the query string parameter of the URL of the page sent to the browser as `csrf_token`. When Azure AD B2C receives an incoming request from the browser, it confirms that both the query string parameter and cookie versions of the token exist, and that they exactly match, as well as verify elements of the contents of the token to confirm against expected values for the in progress authentication.
+Azure AD B2C uses the [Synchronizer Token strategy](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern) to prevent Cross-Site Request Forgery (CSRF) attacks. When Azure AD B2C generates a CSRF token, it puts the token in a cookie as `x-ms-cpim-csrf`, and in the query string parameter of the URL of the page sent to the browser as `csrf_token`. When Azure AD B2C receives an incoming request from the browser, it confirms that both the query string parameter and cookie versions of the token exist, and that they exactly match.It also verifies elements of the contents of the token to confirm against expected values for the in progress authentication.
 
-The client sends a GET request to Azure AD B2C service with the `csrf_token` in the URL query string. It's an expected behavior, and it's required to load the contents of the next page that's displayed to the user. Although the loading of the contents of the next page is not a state changing operation for the user, Azure AD B2C sends and validates the CSRF token as an additional layer of security. It ensures that the request to load the next page is the result of an in progress authentication. 
+The client sends a GET request to Azure AD B2C service with the `csrf_token` in the URL query string. It's an expected behavior, and it's required to load the contents of the next page that's displayed to the user. Although the loading of the contents of the next page isn't a state changing operation for the user, Azure AD B2C sends and validates the CSRF token as an extra layer of security. It ensures that the request to load the next page is the result of an in progress authentication. 
 
 > [!NOTE]
 > Some security scanners can sometimes flag CSRF token in request that are in the encoding format of a token. The scanner may believe it's a user security credential. Rest assured, the `csrf_token` token is solely an added layer of security, and we've our own defenses against exposing user credentials. 
@@ -71,10 +71,10 @@ The following table lists the claims that you can expect in ID tokens and access
 | Code hash | `c_hash` | `SGCPtt01wxwfgnYZy2VJtQ` | A code hash included in an ID token only when the token is issued together with an OAuth 2.0 authorization code. A code hash can be used to validate the authenticity of an authorization code. For more information about how to perform this validation, see the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html).  |
 | Access token hash | `at_hash` | `SGCPtt01wxwfgnYZy2VJtQ` | An access token hash included in an ID token only when the token is issued together with an OAuth 2.0 access token. An access token hash can be used to validate the authenticity of an access token. For more information about how to perform this validation, see the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html)  |
 | Nonce | `nonce` | `12345` | A nonce is a strategy used to mitigate token replay attacks. Your application can specify a nonce in an authorization request by using the `nonce` query parameter. The value you provide in the request is emitted unmodified in the `nonce` claim of an ID token only. This claim allows your application to verify the value against the value specified on the request. Your application should perform this validation during the ID token validation process. |
-| Subject | `sub` | `884408e1-2918-4cz0-b12d-3aa027d7563b` | The principal about which the token asserts information, such as the user of an application. This value is immutable and cannot be reassigned or reused. It can be used to perform authorization checks safely, such as when the token is used to access a resource. By default, the subject claim is populated with the object ID of the user in the directory. |
+| Subject | `sub` | `884408e1-2918-4cz0-b12d-3aa027d7563b` | The principal about which the token asserts information, such as the user of an application. This value is immutable and can't be reassigned or reused. It can be used to perform authorization checks safely, such as when the token is used to access a resource. By default, the subject claim is populated with the object ID of the user in the directory. |
 | Authentication context class reference | `acr` | Not applicable | Used only with older policies. |
 | Trust framework policy | `tfp` | `b2c_1_signupsignin1` | The name of the policy that was used to acquire the ID token. |
-| Authentication time | `auth_time` | `1438535543` | The time at which a user last entered credentials, represented in epoch time. There is no discrimination between that authentication being a fresh sign-in, a single sign-on (SSO) session, or another sign-in type. The `auth_time` is the last time the application (or user) initiated an authentication attempt against Azure AD B2C. The method used to authenticate is not differentiated. |
+| Authentication time | `auth_time` | `1438535543` | The time at which a user last entered credentials, represented in epoch time. There is no discrimination between that authentication being a fresh sign-in, a single sign-on (SSO) session, or another sign-in type. The `auth_time` is the last time the application (or user) initiated an authentication attempt against Azure AD B2C. The method used to authenticate isn't differentiated. |
 | Scope | `scp` | `Read`| The permissions granted to the resource for an access token. Multiple granted permissions are separated by a space. |
 | Authorized Party | `azp` | `975251ed-e4f5-4efd-abcb-5f1a8f566ab7` | The **application ID** of the client application that initiated the request. |
 
@@ -93,15 +93,15 @@ The following use cases are enabled using these properties:
 - Allow a user to stay signed in to a mobile application indefinitely, as long as the user is continually active on the application. You can set **Refresh token sliding window lifetime (days)** to **No expiry** in your sign-in user flow.
 - Meet your industry's security and compliance requirements by setting the appropriate access token lifetimes.
 
-These settings are not available for password reset user flows.
+These settings aren't available for password reset user flows.
 
 ## Compatibility
 
 The following properties are used to [manage token compatibility](configure-tokens.md):
 
 - **Issuer (iss) claim** - This property identifies the Azure AD B2C tenant that issued the token. The default value is `https://<domain>/{B2C tenant GUID}/v2.0/`. The value of `https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/` includes IDs for both the Azure AD B2C tenant and the user flow that was used in the token request. If your application or library needs Azure AD B2C to be compliant with the [OpenID Connect Discovery 1.0 spec](https://openid.net/specs/openid-connect-discovery-1_0.html), use this value.
 
-- **Subject (sub) claim** - This property identifies the entity for which the token asserts information. The default value is **ObjectID**, which populates the `sub` claim in the token with the object ID of the user. The value of **Not supported** is only provided for backward-compatibility. It's recommended that you switch to **ObjectID** as soon as you are able to.
+- **Subject (sub) claim** - This property identifies the entity for which the token asserts information. The default value is **ObjectID**, which populates the `sub` claim in the token with the object ID of the user. The value of **Not supported** is only provided for backward-compatibility. It's recommended that you switch to **ObjectID** as soon as you're able to.
 
 - **Claim representing policy ID** - This property identifies the claim type into which the policy name used in the token request is populated. The default value is `tfp`. The value of `acr` is only provided for backward-compatibility.