API 資格情報と資格情報マネージャーについて

適用対象: すべての API Management レベル

バックエンド API へのアクセスの管理がしやすいよう、API Management インスタンスには資格情報マネージャーが用意されています。 API Management インスタンスから、資格情報マネージャーを使用して API 資格情報へのアクセスを管理、格納、制御できます。

Note

  • 現在、認証情報マネージャーでは、バックエンド OAuth 2.0 API への接続 (旧称: "承認") の構成と管理が可能です。
  • 資格情報マネージャーに破壊的変更は導入されていません。 OAuth 2.0 の資格情報プロバイダーと接続には、従来の API Management 承認 API とリソース プロバイダーが使用されています。

OAuth 2.0 API のマネージド接続

資格情報マネージャーを利用すると、OAuth 2.0 を使用する 1 つまたは複数のバックエンド サービスや SaaS サービスに関して横断的にユーザー、グループ、サービス プリンシパルの認証と承認を行うプロセスを大幅にシンプル化できます。 API Management の資格情報マネージャーでは、OAuth 2.0、同意、トークンの取得、資格情報ストアへのトークン キャッシュ保持、トークンの更新を簡単に構成でき、1 行のコーディングも必要とされません。 API Management インスタンス、サービス プリンシパル、ユーザー、またはグループに認証を委任するには、アクセス ポリシーを使用します。 OAuth 2.0 に関する背景知識については、「Microsoft ID プラットフォームと OAuth 2.0 承認コード フロー」を参照してください。

この機能があるため、API はサブスクリプション キーの有無にかかわらず公開可能であり、OAuth 2.0 承認をバックエンド サービスに対して使用でき、また、サービス統合によってセキュリティ機能の強化、実装、保守を行う際の開発コストを抑えることができます。

API Management 資格情報マネージャーとサポートされている SaaS ID プロバイダーの図。

ユース ケースの例

API Management の管理下で OAuth 接続を使用することにより、お客様は、OAuth 2.0 を使用する SaaS プロバイダーやバックエンド サービスに簡単に接続できます。 次に例をいくつか示します。

  • 格納されている認可トークンを添付し、要求をプロキシ経由にすることで、SaaS バックエンドに簡単に接続する

  • 認可トークンを添付することで、Azure App Service Web アプリまたは Azure Functions バックエンドへの要求をプロキシ経由にする。その後、変換ロジックを適用する SaaS バックエンドに要求を送信できます

  • 複数のアクセス トークンを添付して GraphQL フェデレーション バックエンドへの要求をプロキシ経由にすることで、フェデレーションを簡単に実行する

  • 取得したトークン エンドポイントを公開し、キャッシュされたトークンを取得し、任意のコンピューティング (コンソール アプリや Kubernetes デーモンなど) からユーザーに代わって SaaS バックエンドを呼び出す。 サポートされている言語で、任意の SaaS SDK を組み合わせます。

  • 複数の SaaS バックエンドに接続する場合の Azure Functions の無人シナリオ。

  • Durable Functions を、SaaS 接続を使用する Logic Apps により近づける。

  • OAuth 2.0 接続においては、API Management 内のすべての API を、それぞれ Logic Apps のカスタム コネクタとして機能させることができます。

資格情報マネージャーのしくみ

資格情報マネージャー内のトークン資格情報は、管理およびランタイムという 2 つの部分から構成されます。

  • 資格情報マネージャーの管理部分は、OAuth 2.0 トークン用資格情報プロバイダーのセットアップと構成、ID プロバイダー用の同意フローの有効化、および、資格情報アクセス用に資格情報プロバイダーへの接続を 1 つまたは複数セットアップする機能を担います。 詳細については、接続の管理部分に関する説明を参照してください。

  • ランタイム部分は、get-authorization-context ポリシーを使用し、承認のアクセス トークンおよび更新トークンのフェッチと格納を実行します。 API Management が呼び出され、get-authorization-context ポリシーが実行されると、まず既存の承認トークンが有効かどうかが検証されます。 認可トークンの有効期限が切れている場合、API Management は OAuth 2.0 フローを使用して、格納されているトークンを ID プロバイダーから更新します。 その後、アクセス トークンを使用してバックエンド サービスへのアクセスが承認されます。 詳細については、接続のランタイム部分に関する説明を参照してください。

資格情報マネージャーを使用する状況

資格情報マネージャーは、以下で説明する 3 つのシナリオにおいて使用されます。

構成のシナリオ

資格情報プロバイダーと接続を構成した後は、API マネージャーで接続をテストできます。 API マネージャーは、テスト用のバックエンド OAuth API を、インスタンスのマネージド ID で get-authorization-context ポリシーを使用するように構成します。 これにより、API マネージャーはテスト API を呼び出して接続をテストできるようになります。

資格情報マネージャーの初期構成シナリオの図。

無人シナリオ

既定では、接続が作成される際、API Management インスタンスのマネージド ID 用にアクセス ポリシーと接続が事前構成されます。 そのような接続の使用時には、さまざまなユーザーがクライアント アプリケーション (静的 Web アプリなど) にサインインし、API Management を介して公開されたバックエンド API を呼び出します。 呼び出しを行うには、get-authorization-context ポリシーに基づいて接続が適用されます。 ユーザー コンテキストとの関連がない事前構成済みの接続が API 呼び出しで使用されるため、すべてのユーザーに同じデータが返されます。

資格情報マネージャーのマネージド ID シナリオの図。

有人 (ユーザー委任) シナリオ

クライアント アプリケーション (静的 Web アプリなど) から呼び出されるバックエンド SaaS API にユーザー コンテキストが必要とされる用途で、ユーザーから見た認証の使い勝手をシンプルにしたい場合は、Microsoft Entra のユーザーまたはグループ ID の代理で接続にアクセスする手段を提供できます。 この場合、構成済みのユーザーは一度ログインして同意を提供するだけで済み、以後は API Management インスタンスによって接続が作成され管理されます。 API Management は、外部サービスへの転送が必要な呼び出しを受けると、接続から取得したアクセス トークンを要求にアタッチします。 このしくみは、API の要求と応答が個人向けを想定したものである場合 (例: 特定のユーザーのプロファイル情報を取得する場合) に最適です。

資格情報マネージャーのユーザー委任シナリオの図。

資格情報マネージャーを構成する方法

要件

  • API Management インスタンスに対してマネージド システム割り当て ID が有効になっている必要があります。

  • API Management インスタンスでは、ポート 443 (HTTPS) 上でインターネットへの送信接続が確立されている必要があります。

可用性

  • すべての API Management サービス レベル

  • セルフホステッド ゲートウェイではサポートされていません

  • ソブリン クラウド、および australiacentral、australiacentral2、jioindiacentral リージョンではサポートされていません

手順の例

セキュリティに関する考慮事項

アクセス トークンとその他のシークレット (クライアント シークレットなど) は、エンベロープ暗号化で暗号化され、内部のマルチテナント ストレージに格納されます。 データは、データごとに一意のキーを使用して AES-128 で暗号化されます。 これらのキーは、Azure Key Vault に格納されて毎月ローテーションされる、マスター証明書で非対称に暗号化されます。

制限

リソース 制限
サービス インスタンス 1 件あたりの資格情報プロバイダー数の上限 1,000
資格情報プロバイダーあたりの最大接続数 10,000
接続あたりのアクセス ポリシーの最大数 100
接続ごとに 1 分あたりの認可要求の最大数 250

よく寄せられる質問 (FAQ)

アクセス トークンはいつ更新されますか?

承認コード タイプの接続の場合、アクセス トークンは次のように更新されます: 実行時に get-authorization-context ポリシーが実行されると、API Management により、格納されているアクセス トークンが有効かどうかがチェックされます。 トークンの有効期限が切れているか有効期限が近い場合、API Management では更新トークンを使用して、構成された ID プロバイダーから新しいアクセス トークンと新しい更新トークンをフェッチします。 更新トークンが期限切れの場合はエラーがスローされ、接続が機能するためには再承認が必要になります。

ID プロバイダーでクライアント シークレットの有効期限が切れた場合はどうなりますか?

実行時に API Management で新しいトークンをフェッチできないため、エラーが発生します。

  • 承認コード タイプの接続の場合、クライアント シークレットは資格情報プロバイダー レベルで更新される必要があります。

  • クライアント資格情報タイプの接続の場合、クライアント シークレットは接続レベルで更新される必要があります。

この機能は VNet 内で実行されている API Management を使用する場合はサポートされますか?

はい。ただし、ポート 443 で AzureConnectors サービス タグへの送信接続が有効になっている必要があります。 詳細については、仮想ネットワークの構成のリファレンスを参照してください。

資格情報プロバイダーが削除された場合、何が起きますか?

その基になる接続やアクセス ポリシーもすべて削除されます。

アクセス トークンは API Management によってキャッシュされますか?

クラシックおよび v2 サービス レベルでは、アクセス トークンは、そのトークンの有効期限の 3 分前まで、API Management インスタンスによってキャッシュされます。 アクセス トークン有効期限までの期間が 3 分未満である場合、キャッシュされる期間はアクセス トークンの期限切れまでになります。

アクセス トークンは従量課金レベルではキャッシュされません。