Azure Container Apps での認証と認可

[アーティクル]
03/24/2023

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

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

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

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

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

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

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

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
Twitter	`/.auth/login/twitter`	Twitter
OpenID Connect プロバイダー	`/.auth/login/<providerName>`	OpenID Connect

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

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

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

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

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

機能のアーキテクチャ

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

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

指定された 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 と Twitter の両方など) のサインインプロバイダーを表示するターンキー手法は提供されません。ただし、この機能をアプリに追加することは難しくありません。手順の概要は次のとおりです。

最初に、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/twitter">Log in with Twitter</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_token`、`refresh_token`、`expires_in` プロパティは省略可能です。
`microsoftaccount`	`{"access_token":"<ACCESS_TOKEN>"}` または `{"authentication_token": "<TOKEN>"`	`authentication_token` は `access_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

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

次のステップ

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

Azure Container Apps での認証と認可

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

ID プロバイダー

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

機能のアーキテクチャ

Authentication flow

認可の動作

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

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

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

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

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

次のステップ

その他のリソース

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

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