次の方法で共有


別の 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 を示しています。

図は、ID とアクセス トークンを持つクライアント アプリと、承認が必要な元の API を示しています。

このクライアント アプリケーションは、元の API に委任されたアクセス許可のアクセス トークン ("A" ラベルを持つ五角形の図形で示されています) を取得しました。 委任されたアクセス許可のアクセス トークンを使用すると、承認を必要とする元の API をユーザーに代わって呼び出すことができます。

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

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

アニメーション化された図は、承認が必要な元の API にアクセス トークンを与えるクライアント アプリを示しています。

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

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

アニメーション化された図は、右側の元の API にアクセス トークンを提供する ID トークンが左側にあるクライアント アプリを示しています。

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

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

アニメーション化された図は、元の API にアクセス トークンを与えるクライアント アプリを示しています。承認が必要な場合、元の API がダウンストリーム API にトークンを渡さないようにします。

元の API が Microsoft Entra ID に戻る

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

アニメーション化された図は、ダウンストリーム API を呼び出すために Microsoft Entra ID からの検証を必要とする元の API にアクセス トークンを提供するクライアント アプリを示しています。

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

アニメーション化された図は、ダウンストリーム API を呼び出すために Microsoft Entra ID から検証を受け取る元の API にアクセス トークンを与えるクライアント アプリを示しています。

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

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

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

アニメーション化された図は、Microsoft Entra ID を使用して検証した後、ダウンストリーム API にアクセス トークンを与える元の API を示しています。

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

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

アニメーション化された図は、ダウンストリーム API にアクセス トークンを与える元の API を示しています。

元の API がダウンストリーム API を呼び出す

次のアニメーションでは、ダウンストリーム API を呼び出します。 ダウンストリーム API が受け取るトークンには、ダウンストリーム API を示す適切な対象ユーザー (aud) 要求があります。

アニメーション化された図は、元の API からのアクセス トークンを検証するダウンストリーム API を示しています。

このトークンには、許可された同意のスコープと、元のアプリ ユーザーの ID が含まれます。 ダウンストリーム API は、有効なアクセス許可を適切に実装して、識別されたユーザーが要求されたタスクを実行するためのアクセス許可を持っていることを確認できます。 On-Behalf-Of フローを使用して、API のトークンを取得し、別の API を呼び出して、ユーザー コンテキストがすべてのダウンストリーム API に確実に渡されるようにする必要があります。

最適なオプション: 元の API が On-Behalf-Of フローを実行する

この最後のアニメーションは、元の API が On-Behalf-Of フロー (OBO) を実行することが最適なオプションであることを示しています。 ダウンストリーム API が正しいトークンを受け取ると、正しい応答ができます。

アニメーション化された図は、元の API からアクセス トークンを受け取るダウンストリーム API を示しています。

API がユーザーに代わって動作していて、別の API を呼び出す必要がある場合、API は OBO を使用して委任されたアクセス許可アクセス トークンを取得し、ユーザーの代わりにダウンストリーム API を呼び出す必要があります。 API がユーザーに代わって動作している場合、API はアプリケーションのアクセス許可を使用してダウンストリーム API を呼び出してはいけません。

次のステップ