Microsoft Entra 条件付きアクセスの開発者向けガイダンス

2023-10-31

Microsoft Entra ID の条件付きアクセス機能は、アプリをセキュリティで保護し、サービスを保護するために使用できるいくつかの方法の 1 つを提供します。条件付きアクセスを使用すると、開発者や企業のお客様は、次のようなさまざまな方法でサービスを保護できます。

多要素認証
Intune に登録されているデバイスのみが特定のサービスにアクセスできるようにする
ユーザーの場所と IP 範囲の制限

条件付きアクセスのすべての機能の詳細については、記事「条件付きアクセスとは」を参照してください。

Microsoft Entra のアプリをビルドしている開発者のために、この記事では、条件付きアクセスを使用する方法について示し、条件付きアクセスポリシーが適用される可能性のある制御不能なリソースにアクセスした場合の影響についても学習します。この記事では、On-Behalf-Of フロー、Web アプリ、Microsoft Graph へのアクセス、API の呼び出しに対し条件付きアクセスが与える影響についても説明します。

シングルテナントアプリとマルチテナントアプリと一般的な認証パターンに関する知識が前提です。

注

この機能を使用するには、Microsoft Entra ID P1 ライセンスが必要です。要件に対する適切なライセンスを確認するには、「Free、Basic、および Premium エディションの一般公開されている機能の比較」をご覧ください。 Microsoft 365 Business ライセンスをお持ちのお客様も、条件付きアクセス機能にアクセスできます。

条件付きアクセスはアプリにどのように影響しますか?

アプリの種類が影響を受ける

最も一般的なケースでは、条件付きアクセスはアプリの動作を変更したり、開発者からの変更を必要としたりしません。アプリが間接的、またはサイレントでサービスに対するトークンを要求する特定の場合のみ、アプリで条件付きアクセスチャレンジを処理するためにコードを変更する必要があります。対話型のサインイン要求を実行するのと同じくらい簡単な場合があります。

具体的には、次のシナリオでは、条件付きアクセスの課題を処理するコードが必要です。

On-Behalf-Of フローを実行するアプリ
複数のサービス/リソースにアクセスするアプリ
MSAL.js を使用したシングルページアプリ
リソースを呼び出す Web Apps

条件付きアクセスポリシーは、アプリに適用できますが、アプリがアクセスする Web API にも適用できます。条件付きアクセスポリシーを構成する方法の詳細については、「クイックスタート: Microsoft Entra の条件付きアクセスを使用して特定のアプリケーションに対して MFA を必要にする」を参照してください。

シナリオに応じて、企業のお客様はいつでも条件付きアクセスポリシーを適用および削除できます。新しいポリシーが適用されたときにアプリが機能し続けるには、チャレンジ処理を実装します。チャレンジ処理の例は次のとおりです。

条件付きアクセスの例

条件付きアクセスを処理するためにコードの変更が必要なシナリオもあれば、そのまま動作するシナリオもあります。条件付きアクセスを使用して多要素認証を実行するシナリオをいくつか次に示します。その結果、その違いについていくつかの分析情報が得られます。

シングルテナントの iOS アプリをビルドして、条件付きアクセスポリシーを適用するとします。アプリはユーザーをサインインさせ、API へのアクセスを要求しません。ユーザーがサインインすると、ポリシーが自動的に呼び出され、ユーザーは多要素認証 (MFA) を実行する必要があります。
中間層サービスを使用してダウンストリーム API にアクセスするネイティブアプリを構築しています。このアプリを使用している企業のお客様は、ダウンストリーム API にポリシーを適用します。エンドユーザーがサインインすると、ネイティブアプリケーションは中間層へのアクセスを要求し、トークンを送信します。中間層は、ダウンストリーム API へのアクセスを要求するために、代理フローを実行します。この時点で、クレーム "チャレンジ" が中間層に提示されます。中間層では、条件付きアクセスポリシーに準拠する必要があるネイティブのアプリにチャレンジを送信します。

Microsoft Graph

Microsoft Graph では、条件付きアクセスの環境でアプリを構築する場合に、特別な考慮事項があります。通常、条件付きアクセスのメカニズムは同様に動作しますが、ユーザーに表示されるポリシーは、アプリがグラフから要求している基本データに基づくものとなります。

具体的に言うと、Microsoft Graph のスコープはすべて、ポリシーを個別に適用できる、いくつかのデータセットを表します。条件付きアクセスポリシーには特定のデータセットが割り当てられるため、Microsoft Entra ID は Graph 自体ではなく、Graph の背後にあるデータに基づいて条件付きアクセスポリシーを適用します。

たとえば、アプリが次の Microsoft Graph スコープを要求したとします。

scopes="ChannelMessages.Read.All Mail.Read"

この場合アプリでは、Teams と Exchange に対して設定されたすべてのポリシーをユーザーが満たすことを想定できます。一部のスコープは、複数のデータセットにマップされる場合があります (アクセスを許可する場合)。

条件付きアクセスポリシーへの準拠

いくつかの異なるアプリトポロジでは、セッションが確立されたときに、条件付きアクセスポリシーが評価されます。条件付きアクセスポリシーは、アプリやサービスの粒度に従って動作するため、実行しようとしているシナリオによって呼び出されるポイントが大きく異なります。

アプリが条件付きアクセスポリシーを使用してサービスにアクセスしようとすると、条件付きアクセスのチャレンジが発生する可能性があります。このチャレンジは、Microsoft Entra ID からの応答に含まれる claims パラメーターにエンコードされています。このチャレンジパラメーターの例を次に示します。

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

開発者は、このチャレンジを取得して、Microsoft Entra ID への新しい要求に追加できます。この状態を渡すと、エンドユーザーに、条件付きアクセスポリシーに準拠するために必要な操作を実行することを求めるメッセージが表示されます。次のシナリオでは、エラーおよびパラメーターを抽出する方法について説明します。

シナリオ

[前提条件]

Microsoft Entra 条件付きアクセスは、Microsoft Entra ID P1 または P2 に含まれている機能です。 Microsoft 365 Business ライセンスをお持ちのお客様も、条件付きアクセス機能にアクセスできます。

特定のシナリオの考慮事項

次の情報は、これらの条件付きアクセスシナリオでのみ適用されます。

On-Behalf-Of フローを実行するアプリ
複数のサービス/リソースにアクセスするアプリ
MSAL.js を使用したシングルページアプリ

以下のセクションでは、より複雑な一般的なシナリオについて説明します。主要な運用原則では、条件付きアクセスポリシーは、条件付きアクセスポリシーが適用されるサービスに対してトークンが要求されたときに評価されます。

シナリオ:On-Behalf-Of フローを実行するアプリ

このシナリオでは、ネイティブアプリが Web サービス/API を呼び出す場合について説明します。呼び出されたサービスは、On-Behalf-Of フローでダウンストリームサービスを呼び出します。ここでは、ダウンストリームサービス (Web API 2) に、条件付きアクセスポリシーを適用し、サーバー/デーモンアプリではなく、ネイティブアプリを使用しています。

On-Behalf-Of フローを実行するアプリのフローダイアグラム

Web API 1 の初期トークン要求では、Web API 1 が常にダウンストリーム API にヒットするとは限らないため、エンドユーザーに多要素認証を求めるメッセージは表示されません。 Web API 1 が Web API 2 のユーザーに代わってトークンを要求しようとすると、ユーザーが多要素認証でサインインしていないため、要求は失敗します。

Microsoft Entra ID は、いくつかの興味深いデータを HTTP 応答で返します。

注

この場合は、多要素認証エラーの説明ですが、条件付きアクセスに関連するさまざまな interaction_required である可能性があります。

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Web API 1 では、エラー error=interaction_required をキャッチし、claims チャレンジをデスクトップアプリケーションに返送します。この時点では、デスクトップアプリケーションは新しい acquireToken() 呼び出しを行い、追加のクエリ文字列パラメーターとして claims チャレンジを追加できます。この新しい要求では、ユーザーが多要素認証を行い、この新しいトークンを Web API 1 に送り返し、代理フローを完了する必要があります。

このシナリオを試すには、.NET コードサンプルを参照してください。これは、Web API 1 から返された要求チャレンジをネイティブアプリケーションに渡し、クライアントアプリケーション内で新しい要求を作成する方法を示しています。

シナリオ:複数のサービスにアクセスするアプリ

このシナリオでは、Web アプリが、いずれかに条件付きアクセスポリシーが割り当てられている 2 つのサービスにアクセスする場合について説明します。アプリケーションロジックによっては、Web アプリが両方の Web サービスにアクセスする必要のないパスが存在する場合があります。このシナリオでは、トークンを要求する順序が、エンドユーザーエクスペリエンスに重要な役割を果たします。

A と B の Web サービスがあり、Web サービス B に条件付きアクセスポリシーが適用されているとします。最初の対話型の認証要求では、両方のサービスの同意が必要ですが、条件付きアクセスポリシーがすべての場合に必要なわけではありません。アプリが Web サービス B のトークンを要求すると、ポリシーが呼び出され、Web サービス A に対する後続の要求も成功します。

複数のサービスにアクセスするアプリのフローダイアグラム

また、最初にアプリで Web サービス A に対するトークンを要求している場合、エンドユーザーは条件付きアクセスポリシーを呼び出しません。これにより、アプリ開発者は、エンドユーザーエクスペリエンスを制御しながらも、条件付きアクセスポリシーを常に強制的に呼び出す必要がなくなります。難しいケースは、アプリが後で Web サービス B のトークンを要求する場合です。この時点で、エンドユーザーは条件付きアクセスポリシーに準拠する必要があります。アプリが acquireToken しようとすると、次のエラー (次の図参照) が発生する可能性があります。

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

新しいトークンを要求する複数のサービスにアクセスするアプリ

アプリが MSAL ライブラリを使用しており、トークンの取得に失敗した場合、常に対話形式で再試行されます。この対話型の要求が発生すると、エンドユーザーには、条件付きアクセスに準拠する機会が与えられます。これは、要求が AcquireTokenSilentAsync または PromptBehavior.Never でない限り該当し、この場合、アプリは対話型の AcquireToken 要求を実行し、エンドユーザーはポリシーに準拠する機会が与えられます。

シナリオ:MSAL.js を使用するシングルページアプリ (SPA)

このシナリオでは、シングルページアプリ (SPA) が存在し、条件付きアクセスで保護されている Web API を、このアプリから MSAL.js を使用して呼び出す場合について説明します。これは、シンプルなアーキテクチャですが、条件付きアクセスの周辺を開発するときに考慮する必要がある点がいくつかあります。

MSAL.js では、acquireTokenSilent()、acquireTokenPopup()、および acquireTokenRedirect() トークンを取得する関数があります。

アクセストークンのサイレント取得に acquireTokenSilent() が使用されます。この場合、どのような状況でも UI は表示されません。
acquireTokenPopup() と acquireTokenRedirect() の両方を対話形式でリソースのトークンを要求するために使用され、この場合、常にサインイン UI が表示されます。

Web API を呼び出すためにアクセストークンが必要な場合は、アプリは acquireTokenSilent() を試行します。トークンの期限が切れているか、条件付きアクセスポリシーに準拠する必要がある場合は、acquireToken 関数が失敗して、アプリでは acquireTokenPopup() または acquireTokenRedirect() が使用されます。

MSAL を使用するシングルページアプリケーションのフローダイアグラム

条件付きアクセスのシナリオでの例を見てみましょう。エンドユーザーがサイトに到着し、セッションは開始されていません。 loginPopup()呼び出しを実行し、多要素認証なしで ID トークンを取得します。ユーザーがボタンを押し、これにより、アプリは Web API からデータを要求する必要があります。アプリは acquireTokenSilent() 呼び出しを試みますが、ユーザーがまだ多要素認証を実行しておらず、条件付きアクセスポリシーに準拠する必要があるため、失敗します。

Microsoft Entra ID は、次の HTTP 応答を返します。

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

アプリは error=interaction_required をキャッチする必要があります。アプリは、同じソースの acquireTokenPopup() または acquireTokenRedirect() を使用できます。ユーザーは多要素認証を強制されます。ユーザーが多要素認証を完了すると、要求されたリソースの新しいアクセストークンがアプリに発行されます。

このシナリオを試すには、On-Behalf-Of フローを使用して Node.js Web API を呼び出す React SPA のコードサンプルを参照してください。このコードサンプルでは、条件付きアクセスポリシーと、このシナリオを説明するために、上記で React SPA に登録された Web API が使用されます。クレームチャレンジを正しく処理し、Web API で使用できるアクセストークンを取得する方法を示します。

こちらも参照ください

機能の詳細については、Microsoft Entra ID の条件付きアクセスに関する記事を参照してください。
他の Microsoft Entra ID コードサンプルについては、サンプルを参照してください。
MSAL SDK の詳細とリファレンスドキュメントへのアクセスについては、 Microsoft 認証ライブラリの概要を参照してください。
マルチテナントシナリオの詳細については、「マルチテナントパターンを使用してユーザーをサインインさせる方法」を参照してください。
「条件付きアクセスと IoT アプリへのアクセスのセキュリティ保護」に関する詳細を学習します。