Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ACA] [310298] Update entra auth - do not use implicit flow #125196

Closed
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 52 additions & 23 deletions articles/container-apps/authentication-entra.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
---

Expand Down Expand Up @@ -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 did not 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).
v-jaswel marked this conversation as resolved.
Show resolved Hide resolved

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

Expand All @@ -84,7 +111,9 @@ To register the app, perform the following steps:
|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. 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). |
|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. |

Expand Down