次の方法で共有


Azure Container Apps での認証と認可

Azure Container Apps には、最小限のコードまたはコードなしで外部のイングレス対応コンテナー アプリを安全に保護するための組み込みの認証と認可機能 ("Easy Auth" とも呼ばれます) が用意されています。

認証と認可に関する詳細については、プロバイダーの選択に関する次のガイドを参照してください。

組み込みの認証を使用する理由

認証と認可にこの機能を必ずしも使う必要はありません。 選択した Web フレームワークにバンドルされているセキュリティ機能を使用するか、独自のユーティリティを作成することができます。 ただし、認証 (サインイン ユーザー) と認可 (セキュリティで保護されたデータへのアクセスの提供) に対して、セキュリティで保護されたソリューションを実装するには、かなりの労力が必要になることがあります。 業界のベスト プラクティスと標準に従って、実装を最新の状態に保つ必要があります。

Container Apps 用の組み込みの認証機能では、すぐに使用できる認証をフェデレーション ID プロバイダーに提供することで、時間と労力を節約できます。 これらの機能を使用すると、アプリケーションの開発により多くの時間を集中させることができ、セキュリティ システムを構築する時間を短縮できます。

次のようなメリットがあります。

  • Azure Container Apps は、さまざまな組み込み認証プロバイダーへのアクセスを提供します。
  • 組み込みの認証機能には、特定の言語、SDK、セキュリティの専門知識、または記述する必要があるコードは必要ありません。
  • Microsoft Entra ID、Facebook、Google、X などの複数のプロバイダーと統合できます。

ID プロバイダー

Container Apps が使用するフェデレーション ID では、サード パーティの ID プロバイダーが代わりにユーザー ID と認証フローを管理します。 次の ID プロバイダーを既定で利用できます。

プロバイダー サインイン エンドポイント 使用方法に関するガイダンス
Microsoft ID プラットフォーム /.auth/login/aad Microsoft ID プラットフォーム
Facebook /.auth/login/facebook Facebook
GitHub /.auth/login/github GitHub
Google /.auth/login/google Google
X /.auth/login/x X
OpenID Connect プロバイダー /.auth/login/<providerName> OpenID Connect

これらのプロバイダーのいずれかを使用する場合、サインイン エンドポイントはユーザー認証と、プロバイダーからの認証トークンの検証のために使用できるようになります。 任意の数のプロバイダー オプションを、ユーザーに対して提供できます。

組み込みの認証の使用に関する考慮事項

この機能は HTTPS でのみ使用する必要があります。 コンテナー アプリのイングレス構成で allowInsecure が無効になっていることを確認します。

サイトのコンテンツと API へのアクセス制限の有無にかかわらず、コンテナー アプリを認証に構成できます。 アプリのアクセスを認証済みユーザーのみに制限するには、[アクセスの制限] の設定を [認証を要求する] に設定します。 認証を行うがアクセスを制限しない場合は、[アクセスの制限] 設定を [認証されていないアクセスを許可する] に設定します。

既定では、各コンテナー アプリは認証用に独自の一意の Cookie またはトークンを発行します。 独自の署名キーと暗号化キーを提供することもできます。

機能のアーキテクチャ

認証と認可のミドルウェア コンポーネントは、アプリケーションの各レプリカ上でサイドカーコンテナーとして実行されるプラットフォームの機能です。 これが有効になっている場合、アプリケーションは、各受信 HTTP 要求がセキュリティ レイヤーを通過した後にその要求を処理します。

アプリ コンテナ―へのトラフィックを許可する前に、ID プロバイダーと対話するサイト サイドカー コンテナ―によってインターセプトされる要求を示すアーキテクチャ図

プラットフォーム ミドルウェアは、アプリに対していくつかの処理を行います。

  • 指定された ID プロバイダーを使用してユーザーとクライアントを認証する
  • 認証されたセッションを管理します
  • HTTP 要求ヘッダーに ID 情報を挿入する

認証と承認のモジュールは、アプリケーションのコードから分離された別のコンテナーで実行されます。 セキュリティ コンテナーはインプロセスで実行されないため、特定の言語フレームワークと直接統合することはできません。 ただし、アプリに必要な関連情報は、この記事で説明するように要求ヘッダーで提供されます。

Authentication flow

認証フローは、プロバイダーによる違いはありませんが、プロバイダーの SDK でサインインするかどうかによって異なります。

  • プロバイダー SDK (サーバー向けフロー または サーバー フロー) がない場合: アプリケーションは、フェデレーション サインイン情報を Container Apps に委任します。 デレゲーションはブラウザーレス アプリで通常のケースであり、プロバイダーのサインイン ページをユーザーに表示します。

  • プロバイダー SDKを使用する (client-directed flow or client flow):アプリケーションは、ユーザーを手動でプロバイダーにサインインさせてから、検証のために Container Apps に認証トークンを送信します。 この方法は、プロバイダーのサインイン ページをユーザーに表示しないブラウザーレス アプリの場合に一般的です。 たとえば、プロバイダーの SDK を使用してユーザーをサインインさせるネイティブ モバイル アプリがあります。

Container Apps の信頼されたブラウザー アプリから Container Apps の別の REST API への呼び出しは、サーバー主導のフローを使って認証することができます。 詳細については、「サインインとサインアウトのカスタマイズ」を参照してください。

この表では、認証フローの手順を示します。

手順 プロバイダーの SDK を使わない場合 プロバイダーの SDK を使う場合
1.ユーザーをサインインさせる クライアントを /.auth/login/<PROVIDER> にリダイレクトします。 クライアント コードはプロバイダーの SDK でユーザーを直接サインインさせ、認証トークンを受け取ります。 詳しくは、プロバイダーのドキュメントをご覧ください。
2.認証をポストする プロバイダーはクライアントを /.auth/login/<PROVIDER>/callback にリダイレクトします。 クライアント コードは検証のためにプロバイダーからのトークンを/.auth/login/<PROVIDER> にポストします。
3.認証済みのセッションを確立する Container Apps は認証された Cookie を応答に追加します。 Container Apps は独自の認証トークンをクライアント コードに返します。
4.認証済みのコンテンツを提供する クライアントは以降の要求に認証クッキーを含めます (ブラウザーによって自動的に処理されます)。 クライアントコードは X-ZUMO-AUTH ヘッダで認証トークンを表示します。

クライアント ブラウザーの場合、Container Apps は認証されていないすべてのユーザーを /.auth/login/<PROVIDER> に自動的に送ることができます。 また、ユーザーが選んだプロバイダーを使ってアプリにサインインするための 1 つまたは複数の /.auth/login/<PROVIDER> リンクをユーザーに表示することもできます。

認可の動作

Azure portal では、コンテナー アプリの認証設定を編集して、受信要求が認証されていない場合のさまざまな動作で構成できます。 以下の見出しではそれらのオプションを説明します。

  • 認証されていないアクセスを許可する: このオプションでは、認証されていないトラフィックの認可をアプリケーション コードに委任します。 認証された要求について、Container Apps は HTTP ヘッダーで認証情報も渡します。 アプリでは、ヘッダー内の情報を使用して、要求の認可を決定できます。

    このオプションでは、匿名要求をいっそう柔軟に処理できます。 たとえば、ユーザーに複数のサインイン プロバイダーを提示することができます。 ただし、コードを記述する必要があります。

  • 認証が必要: このオプションでは、認証されていないとき、アプリケーションへのトラフィックを拒否します。 この拒否は、構成されているいずれかの ID プロバイダーへのリダイレクト操作になります。 このような場合は、選択したプロバイダーの /.auth/login/<PROVIDER> にブラウザー クライアントがリダイレクトされます。 匿名要求がネイティブ モバイル アプリからのものである場合、返される応答は HTTP 401 Unauthorized です。 すべての要求に対して HTTP 401 Unauthorized または HTTP 403 Forbidden になるように拒否を構成することもできます。

    このオプションを使用すると、アプリで認証コードを記述する必要はまったくありません。 役割固有の認可などのさらに細かい認可は、ユーザーの要求を調べることで処理できます (「ユーザー要求へのアクセス」をご覧ください)。

    注意事項

    この方法でのアクセスの制限は、アプリへのすべての呼び出しに適用されますが、これは、多くのシングルページ アプリケーションのように、一般公開されているホーム ページを必要とするアプリには適切でない場合があります。

    Note

    既定では、Microsoft Entra テナント内のすべてのユーザーが Microsoft Entra ID にアプリケーションのトークンを要求できます。 定義されている一連のユーザーに対してアプリへのアクセスを制限する場合は、Microsoft Entra ID でアプリケーションを構成できます。

サインインとサインアウトのカスタマイズ

Container Apps 認証には、サインインとサインアウトのための組み込みのエンドポイントが用意されています。この機能が有効になっている場合、これらのエンドポイントはコンテナー アプリの /.auth ルート プレフィックスで使用できます。

複数のサインイン プロバイダーを使用する

ポータル構成では、ユーザーに複数 (Facebook と X の両方など) のサインイン プロバイダーを表示するターンキー手法は提供されません。 ただし、この機能をアプリに追加することは難しくありません。 手順の概要は次のとおりです。

最初に、Azure Portal の [認証/承認] ページで、有効にする各 ID プロバイダーを構成します。

[要求が認証されない場合に実行するアクション] で、 [匿名要求を許可する (操作不要)] を選択します。

サインイン ページ、ナビゲーション バー、またはアプリのその他の任意の場所で、有効にした各プロバイダーへのサインイン リンク (/.auth/login/<provider>) を追加します。 次に例を示します。

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>

ユーザーがいずれかのリンクを選択すると、それぞれのプロバイダーの UI がユーザーに表示されます。

サインイン後のユーザーをカスタム URL にリダイレクトさせるには、post_login_redirect_uri クエリ文字列パラメーターを使用します (ご利用の ID プロバイダーの構成におけるリダイレクト URI と混同しないでください)。 たとえば、サインイン後にユーザーを /Home/Index にリダイレクトさせるには、次の HTML コードを使用します。

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

クライアント主導型サインイン

クライアント主導型サインインでは、アプリケーションでは、プロバイダー固有の SDK を使用して ID プロバイダーにユーザーがサインインします。 その後、結果的に生成された認証トークンが HTTP POST 要求を利用してアプリケーション コードによって Container Apps に検証のために送信されます (「認証フロー」参照)。

プロバイダーのトークンを検証するには、最初に目的のプロバイダーを使用して コンテナー アプリが構成されている必要があります。 実行時に、プロバイダーから認証トークンを取得した後、検証のためにトークンを /.auth/login/<provider> にポストします。 次に例を示します。

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

トークンの形式は、プロバイダーによって若干異なります。 詳しくは、以下の表をご覧ください。

プロバイダーの値 要求本文に必要 説明
aad {"access_token":"<ACCESS_TOKEN>"} id_tokenrefresh_tokenexpires_in プロパティは省略可能です。
microsoftaccount {"access_token":"<ACCESS_TOKEN>"} または {"authentication_token": "<TOKEN>" authentication_tokenaccess_token よりも優先されます。 expires_in プロパティは省略可能です。
ライブ サービスからトークンを要求する場合は、常に wl.basic スコープを要求します。
google {"id_token":"<ID_TOKEN>"} authorization_code プロパティは省略可能です。 authorization_code 値を指定すると、アクセス トークンと更新トークンがトークン ストアに追加されます。 指定した場合、authorization_code には必要に応じて redirect_uri プロパティを指定することもできます。
facebook {"access_token":"<USER_ACCESS_TOKEN>"} Facebook からの有効なユーザー アクセス トークンを使用します。
twitter {"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"}

プロバイダー トークンが正常に検証された場合、API は、セッション トークンである authenticationToken を応答本文に入れて戻ります。

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

このセッション トークンを入手したら、X-ZUMO-AUTH ヘッダーを HTTP 要求に追加することで、保護対象のアプリ リソースにアクセスすることができます。 次に例を示します。

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

セッションからサインアウトする

ユーザーは、アプリの /.auth/logout エンドポイントに GET 要求を送信することでサインアウトできます。 GET 要求では、次のアクションが実行されます。

  • 現在のセッションから認証 Cookie をクリアします。
  • トークン ストアから現在のユーザーのトークンを削除します。
  • Microsoft Entra ID と Google の場合、ID プロバイダーでサーバー側のサインアウトを実行します。

Web ページの簡単なサインアウト リンクを次に示します。

<a href="/.auth/logout">Sign out</a>

既定では、サインアウトに成功すると、クライアントは URL /.auth/logout/done にリダイレクトされます。 post_logout_redirect_uri クエリ パラメーターを追加して、サインアウト後のリダイレクト ページを変更できます。 次に例を示します。

GET /.auth/logout?post_logout_redirect_uri=/index.html

必ず post_logout_redirect_uri の値をエンコードしてください。

完全修飾 URL を使用する場合は、URL を同じドメインでホストする必要があります。

アプリケーション コードでユーザー クレームにアクセスする

すべての言語フレームワークについて、Container Apps は受信トークン内の要求をアプリケーション コードで使用できるようにします。 クレームは要求ヘッダーに挿入されます。要求ヘッダーは、認証されたエンド ユーザーまたはクライアント アプリケーションのどちらからのものかを示します。 外部要求ではこれらのヘッダーの設定が許可されないので、これらのヘッダーは Container Apps によって設定されている場合にのみ存在します。 いくつかのヘッダーの例は次のとおりです。

  • X-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-ID

任意の言語またはフレームワークで記述されたコードで、これらのヘッダーから必要な情報を取得できます。

Note

これらのヘッダーは、さまざまな言語フレームワークによって異なる形式 (小文字や先頭文字が大文字など) でアプリ コードに提供される可能性があります。

次のステップ

コンテナー アプリのセキュリティ保護の詳細については、次の記事を参照してください。