別の API から API を呼び出す

開発者として、ある 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 に委任されたアクセス許可のアクセス トークン ("A" ラベルを持つ五角形の図形で示されています) を取得しました。 委任されたアクセス許可のアクセス トークンを使用すると、承認を必要とする元の API をユーザーに代わって呼び出すことができます。

クライアント アプリが元の API にアクセス トークンを付与する

次のアニメーションは、元の API にアクセス トークンを提供するクライアント アプリを示しています。 元の API は、アクセス トークンを完全に検証して検査し、クライアント アプリのユーザーの ID を判断します。

元の API がトークンの検証と適用を実行する

次のアニメーションでは、クライアント アプリが元の API にアクセス トークンを付与した後、元の API がトークンの検証と適用を実行することを示しています。 すべて問題なければ、API がクライアント アプリの要求を処理し、サービスを続行します。

元の API でアクセス トークンを使用してダウンストリーム API を呼び出すことはできません

次のアニメーションは、元の API がダウンストリーム API を呼び出すようになったことを示しています。 ただし、元の API では、アクセス トークンを使用してダウンストリーム API を呼び出すことはできません。

元の API が Microsoft Entra ID に戻る

次のアニメーションでは、元の API が Microsoft Entra ID に戻る必要があります。 ユーザーの代わりにダウンストリーム API を呼び出すには、アクセス トークンが必要です。

次のアニメーションは、元の API がクライアント アプリから受信したトークンと、元の API のクライアント資格情報を提供する Original API を示しています。

Microsoft Entra ID が、同意や条件付きアクセスの適用などを確認します。 呼び出し元のクライアントに戻り、トークンを取得できない理由を指定しなければならない場合があります。 通常は、クレーム チャレンジ プロセスを使用して、同意が受け取られないことに関する情報 (条件付きアクセス ポリシーに関連する情報など) を使用して呼び出し元アプリケーションに戻ります。

Microsoft Entra ID がチェックを実行する

次のアニメーションでは、Microsoft Entra ID はそのチェックを実行します。 すべて問題なければ、Microsoft Entra ID が元の API にアクセス トークンを発行して、ユーザーに代わってダウンストリーム API を呼び出します。

元の API には、On-Behalf-Of フローを含むユーザー コンテキストがある

次のアニメーションは、API がダウンストリーム API を呼び出す際にユーザー コンテキストを引き続き使用できるようにする、On-Behalf-Of フロー (OBO) プロセスを示しています。

元の 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 認証ライブラリのサポートについて説明します。