開発者として、ある API が別の API を呼び出す必要がある場合にゼロ トラストを確認するにはどうすればよいですか? この記事では、動作中のアプリケーションを、ユーザーに代わって安全に開発する方法について学習します。
ユーザーがアプリの UI を操作する場合、アプリは委任されたアクセス許可を使用して、どのユーザーに代わってアプリが動作しているのかを認識する場合があります。 API の呼び出し時にアプリが提供するアクセス トークンのサブジェクト (sub) 要求またはオブジェクト ID (oid) とテナント ID (tid) 要求を検査します。 API は信頼されていないアプリに依存しません。これは、ネットワーク上のどこかからの呼び出しにすぎません。 代わりに、トークンを検証して、Microsoft Entra ID が検証したアプリ ユーザーの代わりに API が動作することを確認します。
ある API ( 元の API と呼ばれます) が別の API を呼び出す場合、呼び出す API ( ダウンストリーム API と呼ばれます) が検証プロセスに従う必要があります。 ダウンストリーム API は、信頼されていないネットワーク ソースに依存できません。 適切に検証されたアクセス トークンからユーザー ID を取得する必要があります。
ダウンストリーム API が適切な検証プロセスに従わない場合、ダウンストリーム API は、別の方法でユーザーの ID を提供するために、元の API に依存する必要があります。 ダウンストリーム API は、アプリケーションのアクセス許可を誤って使用して操作を実行する可能性があります。 その後、元の API が、ダウンストリーム API に対してどの結果を達成できるかをユーザーが実現できる唯一の権限になります。 元の API は、意図的に (または意図せず) ユーザーが他の方法では実行できないタスクをユーザーが実行できるようにする場合があります。 たとえば、あるユーザーが別のユーザーの詳細を変更したり、ユーザーがアクセス許可を持っていないドキュメントの読み取りと更新を行ったりすることができます。 検証が正しくないと、重大なセキュリティの問題が発生する可能性があります。
セキュリティを強化するために、元の API は、元の API が呼び出しを行うときにダウンストリーム API に提供する委任されたアクセス許可のアクセス トークンを取得します。 この仕組みを見てみましょう。
- クライアント アプリは、元の API を呼び出すアクセス トークンを取得します。 クライアント アプリケーションは、元の API への委任されたアクセス許可アクセス トークンを取得します。 委任されたアクセス許可のアクセス トークンを使用すると、承認を必要とする元の API をユーザーに代わって呼び出すことができます。
- クライアント アプリは、元の API にアクセス トークンを提供します。 クライアント アプリは、元の API へのアクセス トークンを提供します。 元の API は、アクセス トークンを完全に検証して検査し、クライアント アプリのユーザーの ID を判断します。
- 元の API は、トークンの検証と適用を実行します。 クライアント アプリが元の API にアクセス トークンを渡した後、Original API はトークンの検証と適用を実行します。 すべて問題なければ、API がクライアント アプリの要求を処理し、サービスを続行します。
- 元の API では、アクセス トークンを使用してダウンストリーム API を呼び出すことはできません。 元の API はダウンストリーム API を呼び出したいと考えています。 ただし、元の API では、アクセス トークンを使用してダウンストリーム API を呼び出すことはできません。
- 元の API は Microsoft Entra ID に戻ります。 元の API は Microsoft Entra ID に戻る必要があります。 ユーザーの代わりにダウンストリーム API を呼び出すには、アクセス トークンが必要です。 Original API は、元の API がクライアント アプリから受け取ったトークンと、元の API のクライアント資格情報を提供します。
- Microsoft Entra ID はチェックを実行します。 Microsoft Entra ID が、同意や条件付きアクセスの適用などを確認します。 呼び出し元のクライアントに戻り、トークンを取得できない理由を指定しなければならない場合があります。 通常は、クレーム チャレンジ プロセスを使用して、同意が受け取られないことに関する情報 (条件付きアクセス ポリシーに関連する情報など) を使用して呼び出し元アプリケーションに戻ります。 すべて問題なければ、Microsoft Entra ID が元の API にアクセス トークンを発行して、ユーザーに代わってダウンストリーム API を呼び出します。
- 元の API には、On-Behalf-Of フローを使用するユーザー コンテキストがあります。 On-Behalf-Of フロー (OBO) プロセスを使用すると、API はダウンストリーム API を呼び出す際に引き続きユーザー コンテキストを持つことができます。
- 元の API はダウンストリーム API を呼び出します。 ダウンストリーム API を呼び出します。 ダウンストリーム API が受け取るトークンには、ダウンストリーム API を示す適切な対象ユーザー (aud) 要求があります。 このトークンには、許可された同意のスコープと、元のアプリ ユーザーの ID が含まれます。 ダウンストリーム API は、有効なアクセス許可を適切に実装して、識別されたユーザーが要求されたタスクを実行するためのアクセス許可を持っていることを確認できます。 On-Behalf-Of フローを使用して、API のトークンを取得し、別の API を呼び出して、ユーザー コンテキストがすべてのダウンストリーム API に確実に渡されるようにする必要があります。
最適なオプション: 元の API が On-Behalf-Of フローを実行する
最適なオプションは、元の API が On-Behalf-Of フロー (OBO) を実行することです。 ダウンストリーム API が正しいトークンを受け取ると、正しい応答ができます。 API がユーザーに代わって動作していて、別の API を呼び出す必要がある場合、API は OBO を使用して委任されたアクセス許可アクセス トークンを取得し、ユーザーの代わりにダウンストリーム API を呼び出す必要があります。 API がユーザーに代わって動作している場合、API はアプリケーションのアクセス許可を使用してダウンストリーム API を呼び出してはいけません。
次のステップ
- Microsoft ID プラットフォームの認証フローとアプリのシナリオ、認証フローと、それが使用されるアプリケーション シナリオについて説明します。
- API 保護では、登録を通じて API を保護し、アクセス許可と同意を定義し、ゼロ トラストの目標を達成するためのアクセスを強制するためのベスト プラクティスについて説明します。
- Microsoft ID 同意フレームワーク によって保護される API の例では、最適なユーザー エクスペリエンスを実現するための最小特権アプリケーション アクセス許可戦略を設計する方法を説明します。
- 「トークンのカスタマイズ」では、Microsoft Entra トークンで受け取ることができる情報について説明しています。 最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上させるためにトークンをカスタマイズする方法について説明します。
- Microsoft ID を使用してカスタム API をセキュリティで保護する Learn モジュールでは、Microsoft ID を使用して Web API をセキュリティで保護する方法と、別のアプリケーションから呼び出す方法について説明します。
- アプリケーション プロパティのセキュリティのベスト プラクティス リダイレクト URI、アクセス トークン、証明書とシークレット、アプリケーション ID URI、およびアプリケーションの所有権について説明します。
- Microsoft ID プラットフォームの認証ライブラリでは、さまざまなアプリケーションの種類に対する Microsoft 認証ライブラリのサポートについて説明します。