etherscan-io
diff --git a/‎articles/active-directory-b2c/active-directory-b2c-reference-oidc.md
Lines changed: 12 additions & 12 deletions b/‎articles/active-directory-b2c/active-directory-b2c-reference-oidc.md
Lines changed: 12 additions & 12 deletions
diff --git a/‎articles/active-directory/conditional-access/block-legacy-authentication.md
Lines changed: 1 addition & 1 deletion b/‎articles/active-directory/conditional-access/block-legacy-authentication.md
Lines changed: 1 addition & 1 deletion
diff --git a/‎articles/active-directory/conditional-access/howto-baseline-protect-legacy-auth.md
Lines changed: 1 addition & 1 deletion b/‎articles/active-directory/conditional-access/howto-baseline-protect-legacy-auth.md
Lines changed: 1 addition & 1 deletion
diff --git a/‎articles/active-directory/develop/reference-breaking-changes.md
Lines changed: 1 addition & 1 deletion b/‎articles/active-directory/develop/reference-breaking-changes.md
Lines changed: 1 addition & 1 deletion
@@ -72,14 +72,14 @@ client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
 | Parameter | Required | Description |
 | --------- | -------- | ----------- |
 | client_id | Yes | The application ID that the [Azure portal](https://portal.azure.com/) assigned to your application. |
+| nonce | Yes | A value included in the request (generated by the application) that is included in the resulting ID token as a claim. The application can then verify this value to mitigate token replay attacks. The value is typically a randomized unique string that can be used to identify the origin of the request. |
+| p | Yes | The user flow that is run. It is the name of a user flow that's created in your Azure AD B2C tenant. The name of the user flow should begin with `b2c\_1\_`. |
 | response_type | Yes | Must include an ID token for OpenID Connect. If your web application also needs tokens for calling a web API, you can use `code+id_token`. |
-| redirect_uri | No | The `redirect_uri` parameter of your application, where authentication responses can be sent and received by your application. It must exactly match one of the `redirect_uri` parameters that you registered in the Azure portal, except that it must be URL encoded. |
 | scope | Yes | A space-separated list of scopes. The `openid` scope indicates a permission to sign in the user and get data about the user in the form of ID tokens. The `offline_access` scope is optional for web applications. It indicates that your application will need a *refresh token* for extended access to resources. |
+| prompt | No | The type of user interaction that's required. The only valid value at this time is `login`, which forces the user to enter their credentials on that request. |
+| redirect_uri | No | The `redirect_uri` parameter of your application, where authentication responses can be sent and received by your application. It must exactly match one of the `redirect_uri` parameters that you registered in the Azure portal, except that it must be URL encoded. |
 | response_mode | No | The method that is used to send the resulting authorization code back to your application. It can be either `query`, `form_post`, or `fragment`.  The `form_post` response mode is recommended for best security. |
 | state | No | A value included in the request that's also returned in the token response. It can be a string of any content that you want. A randomly generated unique value is typically used for preventing cross-site request forgery attacks. The state is also used to encode information about the user's state in the application before the authentication request occurred, such as the page they were on. |
-| nonce | Yes | A value included in the request (generated by the application) that is included in the resulting ID token as a claim. The application can then verify this value to mitigate token replay attacks. The value is typically a randomized unique string that can be used to identify the origin of the request. |
-| p | Yes | The user flow that is run. It is the name of a user flow that's created in your Azure AD B2C tenant. The name of the user flow should begin with `b2c\_1\_`. |
-| prompt | No | The type of user interaction that's required. The only valid value at this time is `login`, which forces the user to enter their credentials on that request. |
 
 At this point, the user is asked to complete the workflow. The user might have to enter their username and password, sign in with a social identity, or sign up for the directory. There could be any other number of steps depending on how the user flow is defined.
 
@@ -165,13 +165,13 @@ grant_type=authorization_code&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6&sco
 
 | Parameter | Required | Description |
 | --------- | -------- | ----------- |
-| p | Yes | The user flow that was used to acquire the authorization code. You can't use a different user flow in this request. Add this parameter to the query string, not to the POST body. |
 | client_id | Yes | The application ID that the [Azure portal](https://portal.azure.com/) assigned to your application. |
-| grant_type | Yes | The type of grant, which must be `authorization_code` for the authorization code flow. |
-| scope | No | A space-separated list of scopes. The `openid` scope indicates a permission to sign in the user and get data about the user in the form of id_token parameters. It can be used to get tokens to your application's own back-end web API, which is represented by the same application ID as the client. The `offline_access` scope indicates that your application needs a refresh token for extended access to resources. |
+| client_secret | Yes | The application secret that was generated in the [Azure portal](https://portal.azure.com/). This application secret is an important security artifact. You should store it securely on your server. Change this client secret on a periodic basis. |
 | code | Yes | The authorization code that you acquired in the beginning of the user flow. |
+| grant_type | Yes | The type of grant, which must be `authorization_code` for the authorization code flow. |
+| p | Yes | The user flow that was used to acquire the authorization code. You can't use a different user flow in this request. Add this parameter to the query string, not to the POST body. |
 | redirect_uri | Yes | The `redirect_uri` parameter of the application where you received the authorization code. |
-| client_secret | Yes | The application secret that was generated in the [Azure portal](https://portal.azure.com/). This application secret is an important security artifact. You should store it securely on your server. Change this client secret on a periodic basis. |
+| scope | No | A space-separated list of scopes. The `openid` scope indicates a permission to sign in the user and get data about the user in the form of id_token parameters. It can be used to get tokens to your application's own back-end web API, which is represented by the same application ID as the client. The `offline_access` scope indicates that your application needs a refresh token for extended access to resources. |
 
 A successful token response looks like:
 
@@ -232,13 +232,13 @@ grant_type=refresh_token&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6&scope=op
 
 | Parameter | Required | Description |
 | --------- | -------- | ----------- |
-| p | Yes | The user flow that was used to acquire the original refresh token. You can't use a different user flow in this request. Add this parameter to the query string, not to the POST body. |
 | client_id | Yes | The application ID that the [Azure portal](https://portal.azure.com/) assigned to your application. |
+| client_secret | Yes | The application secret that was generated in the [Azure portal](https://portal.azure.com/). This application secret is an important security artifact. You should store it securely on your server. Change this client secret on a periodic basis. |
 | grant_type | Yes | The type of grant, which must be a refresh token for this part of the authorization code flow. |
-| scope | No | A space-separated list of scopes. The `openid` scope indicates a permission to sign in the user and get data about the user in the form of ID tokens. It can be used to send tokens to your application's own back-end web API, which is represented by the same application ID as the client. The `offline_access` scope indicates that your application needs a refresh token for extended access to resources. |
-| redirect_uri | No | The `redirect_uri` parameter of the application where you received the authorization code. |
 | refresh_token | Yes | The original refresh token that was acquired in the second part of the flow. The `offline_access` scope must be used in both the authorization and token requests in order to receive a refresh token. |
-| client_secret | Yes | The application secret that was generated in the [Azure portal](https://portal.azure.com/). This application secret is an important security artifact. You should store it securely on your server. Change this client secret on a periodic basis. |
+| p | Yes | The user flow that was used to acquire the original refresh token. You can't use a different user flow in this request. Add this parameter to the query string, not to the POST body. |
+| redirect_uri | No | The `redirect_uri` parameter of the application where you received the authorization code. |
+| scope | No | A space-separated list of scopes. The `openid` scope indicates a permission to sign in the user and get data about the user in the form of ID tokens. It can be used to send tokens to your application's own back-end web API, which is represented by the same application ID as the client. The `offline_access` scope indicates that your application needs a refresh token for extended access to resources. |
 
 A successful token response looks like:
 
 
@@ -51,7 +51,7 @@ Before you can block legacy authentication in your directory, you need to first
 
 1. Navigate to the **Azure portal** > **Azure Active Directory** > **Sign-ins**.
 1. Add the Client App column if it is not shown by clicking on **Columns** > **Client App**.
-1. Filter by **Client App** > **Other Clients** and click **Apply**.
+1. **Add filters** > **Client App** > select all of the options for **Other clients** and click **Apply**.
 
 Filtering will only show you sign-in attempts that were made by legacy authentication protocols. Clicking on each individual sign-in attempt will show you additional details. The **Client App** field under the **Basic Info** tab will indicate which legacy authentication protocol was used.
 
 
@@ -34,7 +34,7 @@ Before you can block legacy authentication in your directory, you need to first
 
 1. Navigate to the **Azure portal** > **Azure Active Directory** > **Sign-ins**.
 1. Add the Client App column if it is not shown by clicking on **Columns** > **Client App**.
-1. Filter by **Client App** > **Other Clients** and click **Apply**.
+1. **Add filters** > **Client App** > select all of the options for **Other clients** and click **Apply**.
 
 Filtering will only show you sign-in attempts that were made by legacy authentication protocols. Clicking on each individual sign-in attempt will show you additional details. The **Client App** field under the **Basic Info** tab will indicate which legacy authentication protocol was used.
 
 
@@ -45,7 +45,7 @@ August 2019: Enforce POST semantics according to URL parsing rules - duplicate p
 
 **Effective date**: July 26, 2019
 
-**Endpoints impacted**: Both [v1.0](https://docs.microsoft.com/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow) and [v2.0](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow)
+**Endpoints impacted**: Both [v1.0](https://docs.microsoft.com/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow) and [v2.0](https://docs.microsoft.com/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow)
 
 **Protocol impacted**: [Client Credentials (app-only tokens)](https://docs.microsoft.com/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow)