Merge pull request #292200 from craigshoemaker/aca/jason/entra-auth

[Container Apps] Update: Entra auth -> remove implicit flow (Jason)

Author: v-dirichards

articles/container-apps/authentication-entra.md

@@ -5,7 +5,7 @@ services: container-apps
 author: craigshoemaker
 ms.service: azure-container-apps
 ms.topic: how-to
-ms.date: 04/20/2022
+ms.date: 12/17/2024
 ms.author: cshoe
 ---
 
@@ -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.
@@ -52,27 +52,54 @@ First, you create your app registration. As you do so, collect the following inf
 
 To register the app, perform the following steps:
 
-1. Sign in to the [Azure portal], search for and select **Container Apps**, and then select your app. Note your app's **URL**. You use it to configure your Microsoft Entra app registration.
-1. From the portal menu, select **Microsoft Entra ID**, then go to the **App registrations** tab and select **New registration**.
-1. In the **Register an application** page, enter a **Name** for your app registration.
-1. In **Redirect URI**, select **Web** and type `<app-url>/.auth/login/aad/callback`. For example, `https://<hostname>.azurecontainerapps.io/.auth/login/aad/callback`.
-1. Select **Register**.
-1. After the app registration is created, copy the **Application (client) ID** and the **Directory (tenant) ID** for later.
-1. Select **Authentication**. Under **Implicit grant and hybrid flows**, enable **ID tokens** to allow OpenID Connect user sign-ins from Container Apps. Select **Save**.
-1. (Optional) Select **Branding**. In **Home page URL**, enter the URL of your container app and select **Save**.
-1. Select **Expose an API**, and select **Set** next to *Application ID URI*. The ID value uniquely identifies your application when it's used as a resource, which allows requested tokens to grant access. The value is also used as a prefix for scopes you create.
-
-    For a single-tenant app, you can use the default value, which is in the form `api://<application-client-id>`. You can also specify a more readable URI like `https://contoso.com/api` based on one of the verified domains for your tenant. For a multitenant app, you must provide a custom URI. To learn more about accepted formats for App ID URIs, see the [app registrations best practices reference](../active-directory/develop/security-best-practices-for-app-registration.md#application-id-uri).
-
-    The value is automatically saved.
-
-1. Select **Add a scope**.
-   1. In **Add a scope**, the **Application ID URI** is the value you set in a previous step. Select **Save and continue**.
-   1. In **Scope name**, enter *user_impersonation*.
-   1. In the text boxes, enter the consent scope name and description you want users to see on the consent page. For example, enter *Access &lt;application-name&gt;*.
-   1. Select **Add scope**.
-1. (Optional) To create a client secret, select **Certificates & secrets** > **Client secrets** > **New client secret**. Enter a description and expiration and select **Add**. Copy the client secret value shown on the page as the site won't display it to you again.
-1. (Optional) To add multiple **Reply URLs**, select **Authentication**.
+1. Sign in to the [Azure portal].
+1. Search for and select **Container Apps**, and then select your app. In the *Overview* page, note your app's **Application Url**. You use it to configure your Microsoft Entra app registration.
+1. Select **Home** to return to the portal main menu. Search for and select **Microsoft Entra ID**.
+1. In the *Overview* page, select **Add**, then select **App registration**.
+    1. In the *Register an application* page, enter a **Name** for your app registration.
+    1. In *Redirect URI*, select **Web** and enter the following. Replace `\<APP_URL\>` with the application URL you noted previously.
+
+        `<APP_URL>/.auth/login/aad/callback`.
+    
+        For example: `https://<CONTAINER_APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION_NAME>.azurecontainerapps.io/.auth/login/aad/callback`.
+
+    1. In **Implicit grant and hybrid flows**, enable **ID tokens** to allow OpenID Connect user sign-ins from Container Apps.
+    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 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**.
+        1. In *Configure Web*, in **Redirect URIs**, enter the following. Replace `\<APP_URL\>` with the application URL you noted previously.
+
+            `<APP_URL>/.auth/login/aad/callback`.
+    
+            For example: `https://<CONTAINER_APP_NAME>.<HOSTNAME>.<LOCATION>.azurecontainerapps.io/.auth/login/aad/callback`.
+
+        1. Select **Configure**.
+    1. (Optional) In *Manage*, select **Branding & properties**. In **Home page URL**, enter the URL of your container app and select **Save**.
+    1. In *Manage*, select **Expose an API**.
+        1. Select **Add** next to *Application ID URI*.
+
+            The **Application ID URI** uniquely identifies your application when it's used as a resource, which allows requested tokens to grant access. The value is also used as a prefix for scopes you create.
+
+            For a single-tenant app, you can use the default value, which is in the form `api://<APPLICATION_CLIENT_ID>`. You can also specify a more readable URI like `https://contoso.com/api` based on one of the verified domains for your tenant. For a multitenant app, you must provide a custom URI. To learn more about accepted formats for App ID URIs, see the [app registrations best practices reference](../active-directory/develop/security-best-practices-for-app-registration.md#application-id-uri).
+
+            The value is automatically saved.
+
+        1. Select **Add a scope**.
+        1. In **Add a scope**, the **Application ID URI** is the value you set in a previous step.
+        1. Select **Save and continue**.
+        1. In **Scope name**, enter *user_impersonation*.
+        1. Enter the **Admin consent display name** and **Admin consent description** you want admins to see on the consent page. An example consent display name is *Access &lt;application-name&gt;*.
+        1. Select **Add scope**.
+    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. Select **Add**.
+        1. Copy the client secret value shown on the page as the site won't show it to you again.
 
 ### <a name="entra-id-secrets"> </a>Enable Microsoft Entra ID in your container app
 
@@ -81,10 +108,13 @@ 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.|
+    |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. |
 
@@ -137,19 +167,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