Merge pull request #280387 from rwike77/externalidupdates

Updated branding

Author: prmerger-automator[bot]

articles/app-service/configure-authentication-api-version.md

@@ -2,7 +2,7 @@
 title: Manage AuthN/AuthZ API versions
 description: Upgrade your App Service authentication API to V2 or pin it to a specific version, if needed.
 ms.topic: article
-ms.date: 02/17/2023
+ms.date: 07/09/2023
 ms.custom: devx-track-azurecli, AppServiceIdentity
 author: cephalin
 ms.author: cephalin
@@ -19,7 +19,7 @@ There are two versions of the management API for App Service authentication. The
 > [!WARNING]
 > Migration to V2 will disable management of the App Service Authentication/Authorization feature for your application through some clients, such as its existing experience in the Azure portal, Azure CLI, and Azure PowerShell. This cannot be reversed.
 
-The V2 API doesn't support creation or editing of Microsoft Account as a distinct provider as was done in V1. Rather, it uses the converged [Microsoft identity platform](../active-directory/develop/v2-overview.md) to sign-in users with both Microsoft Entra ID and personal Microsoft accounts. When switching to the V2 API, the V1 Microsoft Entra configuration is used to configure the Microsoft identity platform provider. The V1 Microsoft Account provider will be carried forward in the migration process and continue to operate as normal, but you should move to the newer Microsoft identity platform model. See [Support for Microsoft Account provider registrations](#support-for-microsoft-account-provider-registrations) to learn more.
+The V2 API doesn't support creation or editing of Microsoft Account as a distinct provider as was done in V1. Rather, it uses the converged [Microsoft identity platform](../active-directory/develop/v2-overview.md) to sign-in users with both Microsoft Entra and personal Microsoft accounts. When switching to the V2 API, the V1 Microsoft Entra configuration is used to configure the Microsoft identity platform provider. The V1 Microsoft Account provider will be carried forward in the migration process and continue to operate as normal, but you should move to the newer Microsoft identity platform model. See [Support for Microsoft Account provider registrations](#support-for-microsoft-account-provider-registrations) to learn more.
 
 The automated migration process will move provider secrets into application settings and then convert the rest of the configuration into the new format. To use the automatic migration:
 
@@ -41,7 +41,7 @@ The following steps will allow you to manually migrate the application to the V2
 
    In the resulting JSON payload, make note of the secret value used for each provider you've configured:
 
-   * Microsoft Entra ID: `clientSecret`
+   * Microsoft Entra: `clientSecret`
    * Google: `googleClientSecret`
    * Facebook: `facebookAppSecret`
    * Twitter: `twitterConsumerSecret`
@@ -69,7 +69,7 @@ The following steps will allow you to manually migrate the application to the V2
 
 1. Add a property to `authsettings.json` that points to the application setting name you created earlier for each provider:
 
-   * Microsoft Entra ID: `clientSecretSettingName`
+   * Microsoft Entra: `clientSecretSettingName`
    * Google: `googleClientSecretSettingName`
    * Facebook: `facebookAppSecretSettingName`
    * Twitter: `twitterConsumerSecretSettingName`
@@ -146,7 +146,7 @@ If your existing configuration contains a Microsoft Account provider and doesn't
 1. Add a new URI that matches the one you just copied, except instead have it end in `/.auth/login/aad/callback`. This will allow the registration to be used by the App Service Authentication / Authorization configuration.
 1. Navigate to the App Service Authentication / Authorization configuration for your app.
 1. Collect the configuration for the Microsoft Account provider.
-1. Configure the Microsoft Entra provider using the "Advanced" management mode, supplying the client ID and client secret values you collected in the previous step. For the Issuer URL, use `<authentication-endpoint>/<tenant-id>/v2.0`, and replace *\<authentication-endpoint>* with the [authentication endpoint for your cloud environment](../active-directory/develop/authentication-national-cloud.md#azure-ad-authentication-endpoints) (e.g., "https://login.microsoftonline.com" for global Azure), also replacing *\<tenant-id>* with your **Directory (tenant) ID**.
+1. Configure the Microsoft Entra provider using the "Advanced" management mode, supplying the client ID and client secret values you collected in the previous step. For the Issuer URL, use `<authentication-endpoint>/<tenant-id>/v2.0`, and replace *\<authentication-endpoint>* with the [authentication endpoint for your cloud environment](../active-directory/develop/authentication-national-cloud.md#azure-ad-authentication-endpoints) (e.g., "https://login.microsoftonline.com" for global Microsoft Entra ID), also replacing *\<tenant-id>* with your **Directory (tenant) ID**.
 1. Once you've saved the configuration, test the login flow by navigating in your browser to the `/.auth/login/aad` endpoint on your site and complete the sign-in flow.
 1. At this point, you've successfully copied the configuration over, but the existing Microsoft Account provider configuration remains. Before you remove it, make sure that all parts of your app reference the Microsoft Entra provider through login links, etc. Verify that all parts of your app work as expected.
 1. Once you've validated that things work against the Microsoft Entra provider, you may remove the Microsoft Account provider configuration.