Microsoft Entra ID を使った Azure Container Apps での認証と認可を有効にする

  • [アーティクル]

この記事では、アプリで Microsoft ID プラットフォームを認証プロバイダーとして使用してユーザーがサインインするように、Azure Container Apps の認証を構成する方法について説明します。

Contairner Apps 認証機能により、Microsoft ID プラットフォームを使用してアプリの登録を自動的に作成できます。 また、ユーザーまたはディレクトリ管理者が個別に作成した登録を使用することもできます。

オプション 1: 新しいアプリ登録を自動作成する

このオプションでは、認証を簡単にするように設計されており、数回の手順のみで実行できます。

  1. Azure portal にサインインし、アプリに移動します。

  2. 左側のメニューで [認証] を選択します。 [ID プロバイダーの追加] を選択します。

  3. [ID プロバイダー] ドロップダウンで [Microsoft] を選択します。 既定では、新しい登録を作成するオプションが選択されています。 登録の名前またはサポートされているアカウントの種類を変更できます。

    クライアント シークレットが作成され、シークレットとしてコンテナー アプリに格納されます。

  4. このアプリケーションの最初の ID プロバイダーを構成する場合は、[Container Apps authentication settings]\(Container Apps の認証設定\) セクションも表示されます。 それ以外の場合は、次の手順に進むことができます。

    これらのオプションは、アプリケーションが認証されていない要求にどのように応答するかを決定し、既定の選択によって、この新しいプロバイダーにサインインするためのすべての要求がリダイレクトされます。 [認証設定] の横にある [編集] を選択して、この動作を今すぐカスタマイズするか、後でメインの [認証] 画面からこれらの設定を調整することができます。 これらのオプションの詳細については、「認証フロー」を参照してください。

  5. (オプション) [次へ: アクセス許可] を選択し、アプリケーションで必要なスコープを追加します。 これらはアプリの登録に追加されますが、後で変更することもできます。

  6. [追加] を選択します。

これで、アプリケーションで認証に Microsoft ID プラットフォームを使う準備ができました。 [認証] 画面にプロバイダーが一覧表示されます。 そこから、このプロバイダーの構成を編集または削除できます。

オプション 2: 個別に作成された既存の登録を使用する

また、アプリケーションを Microsoft ID プラットフォームに手動で登録し、登録をカスタマイズして、登録の詳細を使用して Container Apps 認証を構成することもできます。 このアプローチは、アプリケーションが定義されているものとは異なる Microsoft Entra テナントからアプリケーションの登録を使用する場合に便利です。

コンテナー アプリ用に Microsoft Entra ID でアプリ登録を作成する

まず、アプリの登録を作成します。 この場合は、後でコンテナー アプリで認証を構成するときに必要になる次の情報を収集します。

  • クライアント ID
  • テナント ID
  • クライアント シークレット (オプショナル)
  • アプリケーション ID URI

アプリを登録するには、次の手順に従います。

  1. Azure portal にサインインし、[Container Apps] を探して選択してから、アプリを選択します。 アプリの URL をメモしておきます。 それを使用して、Microsoft Entra アプリ登録を構成します。

  2. ポータル メニューから [Microsoft Entra ID] を選択し、[アプリの登録] タブに移動して、[新規登録] を選択します。

  3. [アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。

  4. [リダイレクト URI] で、[Web] を選択し、「<app-url>/.auth/login/aad/callback」と入力します。 たとえば、https://<hostname>.azurecontainerapps.io/.auth/login/aad/callback のようにします。

  5. [登録] を選択します。

  6. アプリの登録が作成されたら、後のために [アプリケーション (クライアント) ID] と [ディレクトリ (テナント) ID] をコピーします。

  7. [認証] を選択します。 [Implicit grant and hybrid flows]\(暗黙的な許可とハイブリッド フロー\) で [ID トークン] を有効にして、Container Apps からの OpenID Connect ユーザーのサインインを許可します。 [保存] を選択します。

  8. (省略可能) [ブランド] を選択します。 [ホーム ページ URL] にコンテナー アプリの URL を入力し、[保存] を選択します。

  9. [API の公開] を選択し、"アプリケーション ID URI" の横にある [設定] をクリックします。 この値によって、リソースとして使用される際にアプリケーションを一意に識別し、アクセスを許可するトークンを要求することが可能になります。 この値は、作成するスコープのプレフィックスとしても使用されます。

    シングルテナント アプリの場合、api://<application-client-id> 形式である既定値を使用できます。 テナントの検証済みドメインの 1 つに基づき、https://contoso.com/api のような、もっと読みやすい URI を指定することもできます。 マルチテナントのアプリの場合は、カスタム URI を指定する必要があります。 アプリ ID URI で使用できる形式の詳細については、アプリ登録のベスト プラクティス リファレンス ページを参照してください。

    値は自動的に保存されます。

  10. スコープの追加 を選択します。

    1. [Scope の追加] の [アプリケーション ID の URI] は前の手順で設定した値です。 保存して続行するを選択します。
    2. [スコープ名] に、「user_impersonation」と入力します。
    3. 同意ページでユーザーに表示する同意スコープの名前と説明をテキスト ボックスに入力します。 たとえば、「 <アプリケーション名> にアクセスする」と入力します。
    4. [スコープの追加] を選択します。

  11. (省略可能) クライアント シークレットを作成するには、[証明書とシークレット]>[Client secrets]\(クライアント シークレット\)>[New client secret]\(新しいクライアント シークレット) を選びます。 説明と有効期限を入力し、 [追加] を選びます ページに表示されるクライアント シークレットの値をコピーします。 二度と表示されることはありません。

  12. (オプショナル) 複数の応答 URL を追加するには、 [認証] を選択します。

コンテナー アプリで Microsoft Entra ID を有効にする

  1. Azure portal にサインインし、アプリに移動します。

  2. 左側のメニューで [認証] を選択します。 [ID プロバイダーの追加] を選択します。

  3. [ID プロバイダー] ドロップダウンで [Microsoft] を選択します。

  4. [アプリの登録の種類] では、 [このディレクトリ内の既存アプリの登録を選択] を選択して、必要なアプリ情報を自動的に収集することができます。 別のテナントからの登録の場合、または登録オブジェクトを表示する権限がない場合は、[既存アプリの登録の詳細を提供します] を選択します。 このオプションを選択した場合は、次の構成の詳細を入力する必要があります。

    フィールド 説明
    アプリケーション (クライアント) ID アプリの登録のアプリケーション (クライアント) ID を使用します。
    クライアント シークレット アプリの登録で生成したクライアント シークレットを使用します。 クライアント シークレットを使用すると、ハイブリッド フローが使用され、Container Apps によってアクセス トークンと更新トークンが返されます。 クライアント シークレットが設定されていない場合は、暗黙的なフローが使用され、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 をここに追加します。

    クライアント シークレットは、コンテナー アプリにシークレットとして保存されます。

  5. これがアプリケーション用に構成された最初の ID プロバイダーである場合は、Container Apps の認証設定のセクションも表示されます。 それ以外の場合は、次の手順に進むことができます。

    これらのオプションは、アプリケーションが認証されていない要求にどのように応答するかを決定し、既定の選択によって、この新しいプロバイダーにサインインするためのすべての要求がリダイレクトされます。 [認証設定] の横にある [編集] を選択すると、この動作をメインの [認証] 画面からカスタマイズすることができます。 これらのオプションの詳細については、「認証フロー」を参照してください。

  6. [追加] を選択します。

これで、アプリケーションで認証に Microsoft ID プラットフォームを使う準備ができました。 [認証] 画面にプロバイダーが一覧表示されます。 そこから、このプロバイダーの構成を編集または削除できます。

コンテナー アプリにアクセスするようにクライアント アプリを構成する

前のセクションでは、ユーザーを認証するためにコンテナー アプリを登録しました。 このセクションでは、ネイティブ クライアントまたはデーモン アプリを登録して、ユーザーまたはユーザーの代わりにコンテナー アプリによって公開される API へのアクセスを要求できるようにする方法について説明します。 ユーザーを認証するだけの場合は、このセクションの手順を完了する必要はありません。

ネイティブ クライアント アプリケーション

サインインしているユーザーの代わりにコンテナー アプリの API へのアクセスを要求するようにネイティブ クライアントを登録できます。

  1. Azure portal で、[Active Directory]、[アプリの登録]、[新規登録] の順に選択します。

  2. [アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。

  3. [リダイレクト URI] で、[パブリック クライアント (モバイルとデスクトップ)] を選択し、URL「<app-url>/.auth/login/aad/callback」を入力します。 たとえば、https://<hostname>.azurecontainerapps.io/.auth/login/aad/callback のようにします。

    Note

    Microsoft Store アプリケーションの場合は、代わりにパッケージ SID を URI として使用します。

  4. [作成] を選択します。

  5. アプリの登録が作成されたら、 [アプリケーション (クライアント) ID] の値をコピーします。

  6. [API のアクセス許可] 、 [アクセス許可の追加] 、 [自分の API] の順に選択します。

  7. コンテナー アプリ用に以前に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、「コンテナー アプリ用に Microsoft Entra ID でアプリ登録を作成する」で user_impersonation スコープを追加したことを確認してください。

  8. [委任されたアクセス許可] で、 [user_impersonation] を選択し、 [アクセス許可の追加] を選択します。

これで、ユーザーに代わってコンテナー アプリにアクセスを要求できるネイティブ クライアント アプリケーションが構成されました。

デーモン クライアント アプリケーション (サービス ツー サービスのコール)

アプリケーションは、(ユーザーの代わりではなく) それ自体の代わりにコンテナー アプリでホストされる Web API を呼び出すトークンを取得できます。 このシナリオは、ログイン ユーザーなしでタスクを実行する非対話型デーモン アプリケーションに役立ちます。 これには標準の OAuth 2.0 クライアント資格情報の付与が使用されます。

  1. Azure portal で、[Active Directory]、[アプリの登録]、[新規登録] の順に選択します。
  2. [アプリケーションの登録] ページで、デーモン アプリの登録の [名前] を入力します。
  3. デーモン アプリケーションの場合、リダイレクト URI は不要であるため、空のままでかまいません。
  4. [作成] を選択します。
  5. アプリの登録が作成されたら、 [アプリケーション (クライアント) ID] の値をコピーします。
  6. [証明書とシークレット]>[新しいクライアント シークレット]>[追加] を選択します。 ページに表示されるクライアント シークレットの値をコピーします。 二度と表示されることはありません。

これで、resource パラメーターをターゲット アプリのアプリケーション ID URI に設定することで、クライアント ID とクライアント シークレットを使用してアクセス トークンを要求できます。 その後、標準の OAuth 2.0 Authorization ヘッダーを使用して、結果として得られたアクセス トークンをターゲット アプリに提示できます。また、Container Apps の認証/承認によって、通常どおりトークンが検証および使用され、呼び出し元 (この場合はユーザーではなくアプリケーション) が認証されたことが示されます。

このプロセスによって Microsoft Entra テナント内の "すべて" のクライアント アプリケーションがアクセス トークンを要求し、ターゲット アプリに対して認証を行うことができます。 また、"承認" を実施して特定のクライアント アプリケーションのみを許可する場合は、構成を調整する必要があります。

  1. 保護するコンテナー アプリを表すアプリ登録のマニフェストで、アプリ ロールを定義します。
  2. 承認する必要があるクライアントを表すアプリの登録で、 [API のアクセス許可]>[アクセス許可の追加]>[自分の API] を選択します。
  3. 前に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、アプリ ロールを追加したことを確認してください。
  4. [アプリケーションのアクセス許可] で、前に作成したアプリ ロールを選択し、 [アクセス許可の追加] を選択します。
  5. クライアント アプリケーションがアクセス許可を要求することを承認するために、必ず [管理者の同意を与える] を選択してください。
  6. (ロールを追加する前の) 前述のシナリオと同様に、これで、同じターゲット resource のアクセス トークンを要求できます。アクセス トークンには、クライアント アプリケーションのために承認されたアプリ ロールを含む roles 要求が含まれます。
  7. これで、ターゲットの Container Apps のコード内で、必要なロールがトークンに存在しているかを検証できるようになりました。 この検証手順は、Container Apps 認証レイヤーでは実行されません。 詳しくは、「ユーザー要求へのアクセス」をご覧ください。

これで、独自の ID を使用してコンテナー アプリにアクセスできるデーモン クライアント アプリケーションの構成が完了しました。

認証済みユーザーの操作

認証済みユーザーの操作の詳細については、次のガイドを使用してください。

次のステップ

認証と許可の概要