Microsoft Entra ID を使った Azure Container Apps での認証と認可を有効にする
この記事では、アプリで Microsoft ID プラットフォームを認証プロバイダーとして使用してユーザーがサインインするように、Azure Container Apps の認証を構成する方法について説明します。
Contairner Apps 認証機能により、Microsoft ID プラットフォームを使用してアプリの登録を自動的に作成できます。 また、ユーザーまたはディレクトリ管理者が個別に作成した登録を使用することもできます。
オプション 1: 新しいアプリ登録を自動作成する
このオプションでは、認証を簡単にするように設計されており、数回の手順のみで実行できます。
Azure portal にサインインし、アプリに移動します。
左側のメニューで [認証] を選択します。 [ID プロバイダーの追加] を選択します。
[ID プロバイダー] ドロップダウンで [Microsoft] を選択します。 既定では、新しい登録を作成するオプションが選択されています。 登録の名前またはサポートされているアカウントの種類を変更できます。
クライアント シークレットが作成され、シークレットとしてコンテナー アプリに格納されます。
このアプリケーションの最初の ID プロバイダーを構成する場合は、Container Apps の認証設定セクションが表示されます。 それ以外の場合は、次の手順に進みます。
これらのオプションは、アプリケーションが認証されていない要求にどのように応答するかを決定し、既定の選択によって、この新しいプロバイダーにサインインするためのすべての要求がリダイレクトされます。 [認証設定] の横にある [編集] を選択して、この動作を今すぐカスタマイズするか、後でメインの [認証] 画面からこれらの設定を調整することができます。 これらのオプションの詳細については、「認証フロー」を参照してください。
(オプション) [次へ: アクセス許可] を選択し、アプリケーションで必要なスコープを追加します。 このスコープはアプリの登録に追加されますが、後で変更することもできます。
[追加] を選択します。
これで、アプリケーションで認証に Microsoft ID プラットフォームを使う準備ができました。 [認証] 画面にプロバイダーが一覧表示されます。 そこから、このプロバイダーの構成を編集または削除できます。
オプション 2: 個別に作成された既存の登録を使用する
また、アプリケーションを Microsoft ID プラットフォームに手動で登録し、登録をカスタマイズして、登録の詳細を使用して Container Apps 認証を構成することもできます。 このアプローチは、アプリケーションが定義されているものとは異なる Microsoft Entra テナントからアプリケーションの登録を使用する場合に便利です。
コンテナー アプリ用に Microsoft Entra ID でアプリ登録を作成する
まず、アプリの登録を作成します。 この場合は、後でコンテナー アプリで認証を構成するときに必要になる次の情報を収集します。
- クライアント ID
- テナント ID
- クライアント シークレット (オプショナル)
- アプリケーション ID URI
アプリを登録するには、次の手順に従います。
- Azure portal にサインインします。
- Container Apps を検索して選択し、アプリを選択します。 [概要] ページで、アプリのアプリケーション URL をメモします。 それを使用して、Microsoft Entra アプリ登録を構成します。
- [ホーム] を選択して、ポータルのメイン メニューに戻ります。 Microsoft Entra ID を検索して選択します。
- [概要] ページで、[追加]、[アプリの登録］ の順に選択します。
[アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。
[リダイレクト URI] で、[Web] を選択し、次を入力します。
\<APP_URL\>を前に説明したアプリケーション URL に置き換えます。<APP_URL>/.auth/login/aad/callback.(例:
https://<CONTAINER_APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION_NAME>.azurecontainerapps.io/.auth/login/aad/callback)。[暗黙的な許可とハイブリッド フロー] で [ID トークン] を有効にして、Container Apps からの OpenID Connect ユーザーのサインインを許可します。
登録 を選択します。
- 新しいアプリの登録を参照します。
- [概要] ページで、後で使用するためにアプリケーション (クライアント) ID とディレクトリ (テナント) ID をコピーします。
- (省略可能) 以前にアプリ登録にリダイレクト URI を追加しなかった場合は、ここで追加できます。
[マネージド] で、[認証] を選択します。
[認証] ページの [プラットフォーム構成] で、[プラットフォームの追加] を選択します。
[プラットフォームの構成] で [Web] を選びます。
[Web の構成] の [リダイレクト URI] に、次のように入力します。
\<APP_URL\>を前に説明したアプリケーション URL に置き換えます。<APP_URL>/.auth/login/aad/callback.(例:
https://<CONTAINER_APP_NAME>.<HOSTNAME>.<LOCATION>.azurecontainerapps.io/.auth/login/aad/callback)。[構成] をクリックします。
- (省略可能) [管理] で、[ブランド化とプロパティ] を選択します。 [ホーム ページ URL] にコンテナー アプリの URL を入力し、[保存] を選択します。
- [管理] で [API の公開] を選択します。
[アプリケーション ID URI] の横にある [追加] を選択します。
アプリケーション ID URI によって、アプリケーションがリソースとして使用される場合にそれが一意に識別され、要求されたトークンがアクセスを許可できるようになります。 この値は、作成するスコープのプレフィックスとしても使用されます。
シングルテナント アプリの場合、
api://<APPLICATION_CLIENT_ID>形式である既定値を使用できます。 テナントの検証済みドメインの 1 つに基づき、https://contoso.com/apiのような、もっと読みやすい URI を指定することもできます。 マルチテナントのアプリの場合は、カスタム URI を指定する必要があります。 アプリ ID URI で使用できる形式の詳細については、アプリ登録のベスト プラクティス リファレンス ページを参照してください。値は自動的に保存されます。
スコープの追加 を選択します。
[Scope の追加] の [アプリケーション ID の URI] は前の手順で設定した値です。
保存して続行するを選択します。
[スコープ名] に、「user_impersonation」と入力します。
管理者に同意ページで表示させたい [管理者の同意の表示名] と [管理者の同意の説明] を入力します。 同意の表示名の例は、Access <application-name> です。
[スコープの追加] を選択します。
- [管理] で、[証明書とシークレット] を選択します。
- [証明書とシークレット] ページで、[クライアント シークレット] を選びます。
- [新しいクライアント シークレット] を選択します。
- [説明] を入力し、シークレットの [有効期限]を選択します。
- [追加] を選択します。
- ページに表示されるクライアント シークレットの値をコピーします。この値はサイトに再表示されないためです。
コンテナー アプリで Microsoft Entra ID を有効にする
Azure portal にサインインし、アプリに移動します。
左側のメニューで [認証] を選択します。 [ID プロバイダーの追加] を選択します。
[ID プロバイダー] ドロップダウンで [Microsoft] を選択します。
[アプリの登録の種類] では、 [このディレクトリ内の既存アプリの登録を選択] を選択して、必要なアプリ情報を自動的に収集することができます。 別のテナントからの登録の場合、または登録オブジェクトを表示する権限がない場合は、[既存アプリの登録の詳細を提供します] を選択します。 このオプションを選択した場合は、次の構成の詳細を入力する必要があります。
警告
可能な限り、暗黙的な許可フローを使用しないでください。 ほとんどのシナリオでは、より安全な代替手段を利用でき、推奨されます。 このフローの構成によっては、アプリケーションで非常に高い信頼度が要求されるため、他のフローには存在しないリスクが伴います。 このフローは、より安全なフローが実行可能ではない場合にのみ使用してください。 詳細については、「暗黙的な許可フローに関するセキュリティの問題」を参照してください。
フィールド 説明 アプリケーション (クライアント) ID アプリの登録のアプリケーション (クライアント) ID を使用します。 クライアント シークレット アプリの登録で生成したクライアント シークレットを使用します。 クライアント シークレットはハイブリッド フローを使用し、アプリはアクセス トークンと更新トークンを返します。 クライアント シークレットが設定されていない場合は、暗黙的なフローが使用され、ID トークンのみが返されます。 これらのトークンはプロバイダーによって送信され、EasyAuth トークン ストアに格納されます。 発行者の URL <authentication-endpoint>/<TENANT-ID>/v2.0を使用し、<authentication-endpoint> をクラウド環境の認証エンドポイント (たとえば、グローバル Azure の場合は "https://login.microsoftonline.com"") に置き換え、さらに <TENANT-ID> をアプリ登録が作成されたディレクトリ (テナント) ID に置き換えます。 この値は、ユーザーを正しい Microsoft Entra テナントにリダイレクトするため、および適切なメタデータをダウンロードして、適切なトークン署名キーやトークン発行者のクレーム値などを特定するために使用されます。 Azure AD v1 を使用するアプリケーションの場合は、URL で/v2.0を省略します。許可されるトークン対象ユーザー 構成された [アプリケーション (クライアント) ID] は、"常に" 許可された対象ユーザーであると暗黙的に見なされます。 この値がクラウドまたはサーバー アプリを示しており、クライアント コンテナー アプリから認証トークンを受け入れる場合 (認証トークンは X-MS-TOKEN-AAD-ID-TOKENヘッダーで取得できます)、クライアント アプリのアプリケーション (クライアント) ID をここに追加します。クライアント シークレットは、コンテナー アプリにシークレットとして格納されます。
これがアプリケーション用に構成された最初の ID プロバイダーである場合は、Container Apps の認証設定のセクションも表示されます。 それ以外の場合は、次の手順に進みます。
これらのオプションは、アプリケーションが認証されていない要求にどのように応答するかを決定し、既定の選択によって、この新しいプロバイダーにサインインするためのすべての要求がリダイレクトされます。 [認証設定] の横にある [編集] を選択すると、この動作をメインの [認証] 画面からカスタマイズすることができます。 これらのオプションの詳細については、「認証フロー」を参照してください。
[追加] を選択します。
これで、アプリケーションで認証に Microsoft ID プラットフォームを使う準備ができました。 [認証] 画面にプロバイダーが一覧表示されます。 そこから、このプロバイダーの構成を編集または削除できます。
コンテナー アプリにアクセスするようにクライアント アプリを構成する
前のセクションでは、ユーザーを認証するためにコンテナー アプリを登録しました。 このセクションでは、ネイティブ クライアント アプリまたはデーモン アプリを登録します。 その後、ユーザーに代わってまたはまたはアプリ自体のために、コンテナー アプリによって公開される API へのアクセスを要求できます。 ユーザーを認証するだけの場合は、このセクションの手順を完了する必要はありません。
ネイティブ クライアント アプリケーション
サインインしているユーザーの代わりにコンテナー アプリの API へのアクセスを要求するようにネイティブ クライアントを登録できます。
Azure portal で [Microsoft Entra ID]>[追加]>[アプリの登録] の順に選択します。
[アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。
[リダイレクト URI] で、[パブリック クライアント (モバイルとデスクトップ)] を選択し、URL「
<app-url>/.auth/login/aad/callback」を入力します。 たとえば、https://<hostname>.azurecontainerapps.io/.auth/login/aad/callbackのようにします。Note
Microsoft Store アプリケーションの場合は、代わりにパッケージ SID を URI として使用します。
[作成] を選択します。
アプリの登録が作成されたら、 [アプリケーション (クライアント) ID] の値をコピーします。
[API のアクセス許可] 、 [アクセス許可の追加] 、 [自分の API] の順に選択します。
コンテナー アプリ用に以前に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、「コンテナー アプリ用に Microsoft Entra ID でアプリ登録を作成する」で user_impersonation スコープを追加したことを確認してください。
[委任されたアクセス許可] で、 [user_impersonation] を選択し、 [アクセス許可の追加] を選択します。
このセクションでは、ユーザーに代わってコンテナー アプリにアクセスを要求できるネイティブ クライアント アプリケーションを構成しました。
デーモン クライアント アプリケーション (サービス ツー サービスのコール)
アプリケーションは、(ユーザーの代わりではなく) それ自体の代わりにコンテナー アプリでホストされる Web API を呼び出すトークンを取得できます。 このシナリオは、ログイン ユーザーなしでタスクを実行する非対話型デーモン アプリケーションに役立ちます。 これには標準の OAuth 2.0 クライアント資格情報の付与が使用されます。
- Azure portal で [Microsoft Entra ID]>[追加]>[アプリの登録] の順に選択します。
- [アプリケーションの登録] ページで、デーモン アプリの登録の [名前] を入力します。
- デーモン アプリケーションの場合、リダイレクト URI は不要であるため、空のままでかまいません。
- [作成] を選択します。
- アプリの登録が作成されたら、 [アプリケーション (クライアント) ID] の値をコピーします。
- [証明書とシークレット]>[新しいクライアント シークレット]>[追加] を選択します。 ページに表示されるクライアント シークレットの値をコピーします。 これは再表示されません。
これで、resource パラメーターをターゲット アプリのアプリケーション ID URI に設定することで、クライアント ID とクライアント シークレットを使用してアクセス トークンを要求できます。 その後、標準の OAuth 2.0 Authorization ヘッダーを使用して、結果として得られたアクセス トークンをターゲット アプリに提示できます。また、Container Apps の認証/承認によって、通常どおりトークンが検証および使用され、呼び出し元 (この場合はユーザーではなくアプリケーション) が認証されたことが示されます。
このプロセスによって Microsoft Entra テナント内の "すべて" のクライアント アプリケーションがアクセス トークンを要求し、ターゲット アプリに対して認証を行うことができます。 また、"承認" を実施して特定のクライアント アプリケーションのみを許可する場合は、構成を調整する必要があります。
- 保護するコンテナー アプリを表すアプリ登録のマニフェストで、アプリ ロールを定義します。
- 承認する必要があるクライアントを表すアプリの登録で、 [API のアクセス許可]>[アクセス許可の追加]>[自分の API] を選択します。
- 前に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、アプリ ロールを追加してください。
- [アプリケーションのアクセス許可] で、前に作成したアプリ ロールを選択し、 [アクセス許可の追加] を選択します。
- クライアント アプリケーションがアクセス許可を要求することを承認するために、必ず [管理者の同意を与える] を選択してください。
- (ロールを追加する前の) 前述のシナリオと同様に、これで、同じターゲット
resourceのアクセス トークンを要求できます。アクセス トークンには、クライアント アプリケーションのために承認されたアプリ ロールを含むroles要求が含まれます。 - ターゲット Container Apps コード内で、予期されるロールがトークンに存在することを確認します。 Container Apps 認証レイヤーでは、この検証手順は実行されません。 詳しくは、「ユーザー要求へのアクセス」をご覧ください。
このセクションでは、独自の ID を使用してコンテナー アプリにアクセスできるデーモン クライアント アプリケーションを構成しました。
認証済みユーザーの操作
認証済みユーザーの操作の詳細については、次のガイドを使用してください。