updates

Author: craigshoemaker

articles/container-apps/authentication-entra.md

@@ -32,7 +32,7 @@ This option is designed to make enabling authentication simple and requires just
 
     These options determine how your application responds to unauthenticated requests, and the default selections redirect all requests to sign in with this new provider. You can customize this behavior now or adjust these settings later from the main **Authentication** screen by choosing **Edit** next to **Authentication settings**. To learn more about these options, see [Authentication flow](authentication.md#authentication-flow).
 
-1. (Optional) Select **Next: Permissions** and add any scopes needed by the application. These are added to the app registration, but you can also change them later.
+1. (Optional) Select **Next: Permissions** and add any scopes needed by the application. The scopes are added to the app registration, but you can also change them later.
 1. Select **Add**.
 
 You're now ready to use the Microsoft identity platform for authentication in your app. The provider is listed on the **Authentication** screen. From there, you can edit or delete this provider configuration.
@@ -67,7 +67,7 @@ To register the app, perform the following steps:
     1. Select **Register**.
 1. Browse to the new app registration.
     1. In the *Overview* page, copy the **Application (client) ID** and the **Directory (tenant) ID** for later.
-    1. (Optional) If you did not add the redirect URI to the app registration previously, you can do so now.
+    1. (Optional) If you didn't add the redirect URI to the app registration previously, you can do so now.
         1. In **Managed**, select **Authentication**.
         1. In the *Authentication* page, in *Platform configurations*, select **Add a platform**.
         1. In *Configure platforms*, select **Web**.
@@ -97,7 +97,7 @@ To register the app, perform the following steps:
     1. In *Manage*, select **Certificates & secrets**.
         1. In the *Certificates & secrets* page, select **Client secrets**.
         1. Select **New client secret**.
-        1. Enter a **Description** and select when the secret **Expires**. 
+        1. Enter a **Description** and select when the secret **Expires**.
         1. Select **Add**.
         1. Copy the client secret value shown on the page as the site won't show it to you again.
 
@@ -108,12 +108,12 @@ To register the app, perform the following steps:
 1. Select **Microsoft** in the identity provider dropdown.
 1. For **App registration type**, you can choose to **Pick an existing app registration in this directory** which automatically gathers the necessary app information. If your registration is from another tenant or you don't have permission to view the registration object, choose **Provide the details of an existing app registration**. For this option, you need to fill in the following configuration details:
 
+    > [!WARNING] Whenever possible, avoid using implicit grant flow. In most scenarios, more secure alternatives are available and recommended. Certain configurations of this flow requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows aren't viable. For more information, see the [security concerns with implicit grant flow](/entra/identity-platform/v2-oauth2-implicit-grant-flow#security-concerns-with-implicit-grant-flow).
+
     |Field|Description|
     |-|-|
     |Application (client) ID| Use the **Application (client) ID** of the app registration. |
-    |Client Secret| Use the client secret you generated in the app registration. With a client secret, hybrid flow is used and the app returns access and refresh tokens. When the client secret isn't set, implicit flow is used and only an ID token is returned. The provider sends the tokens and they're stored in the EasyAuth token store.
-
-        > [!WARNING] Microsoft recommends you do not use the implicit grant flow. In most scenarios, more secure alternatives are available and recommended. Certain configurations of this flow requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows aren't viable. For more information, see the [security concerns with implicit grant flow](/entra/identity-platform/v2-oauth2-implicit-grant-flow#security-concerns-with-implicit-grant-flow). |
+    |Client Secret| Use the client secret you generated in the app registration. Client secrets use hybrid flow and the app returns access and refresh tokens. When the client secret isn't set, implicit flow is used to and only an ID token is returned. The provider sends the tokens and they're stored in the EasyAuth token store. |
     |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) (for example, "https://login.microsoftonline.com" for global Azure), also replacing *\<TENANT-ID>* with the **Directory (tenant) ID** in which the app registration was created. This value is used to redirect users to the correct Microsoft Entra tenant, and to download the appropriate metadata to determine the appropriate token signing keys and token issuer claim value for example. For applications that use Azure AD v1, omit `/v2.0` in the URL.|
     |Allowed Token Audiences| The configured **Application (client) ID** is *always* implicitly considered to be an allowed audience. If this value refers to a cloud or server app and you want to accept authentication tokens from a client container app (the authentication token can be retrieved in the `X-MS-TOKEN-AAD-ID-TOKEN` header), add the **Application (client) ID** of the client app here. |
 
@@ -166,19 +166,19 @@ This process allows _any_ client application in your Microsoft Entra tenant to r
 
 1. [Define an App Role](../active-directory/develop/howto-add-app-roles-in-azure-ad-apps.md) in the manifest of the app registration representing the container app you want to protect.
 1. On the app registration representing the client that needs to be authorized, select **API permissions** > **Add a permission** > **My APIs**.
-1. Select the app registration you created earlier. If you don't see the app registration, make sure that you've [added an App Role](../active-directory/develop/howto-add-app-roles-in-azure-ad-apps.md).
+1. Select the app registration you created earlier. If you don't see the app registration, make sure that you [add an App Role](../active-directory/develop/howto-add-app-roles-in-azure-ad-apps.md).
 1. Under **Application permissions**, select the App Role you created earlier, and then select **Add permissions**.
 1. Make sure to select **Grant admin consent** to authorize the client application to request the permission.
 1. Similar to the previous scenario (before any roles were added), you can now [request an access token](../active-directory/develop/v2-oauth2-client-creds-grant-flow.md#first-case-access-token-request-with-a-shared-secret) for the same target `resource`, and the access token includes a `roles` claim containing the App Roles that were authorized for the client application.
-1. Within the target Container Apps code, you can now validate that the expected roles are present in the token. The Container Apps auth layer doesn't perform the validation steps. For more information, see [Access user claims](authentication.md#access-user-claims-in-application-code).
+1. Within the target Container Apps code, validate expected roles are now present in the token. The Container Apps auth layer doesn't perform the validation steps. For more information, see [Access user claims](authentication.md#access-user-claims-in-application-code).
 
 In this section, you configured a daemon client application that can access your container app using its own identity.
 
 ## Working with authenticated users
 
 Use the following guides for details on working with authenticated users.
 
-* [Customize sign-in and sign-out](authentication.md#customize-sign-in-and-sign-out)
+* [Customize sign-in and sign out](authentication.md#customize-sign-in-and-sign-out)
 * [Access user claims in application code](authentication.md#access-user-claims-in-application-code)
 
 ## Next steps