Azure API Management での API への認証と認可
適用対象: すべての API Management レベル
この記事では、マネージド API へのユーザーのアクセスをセキュリティで保護するのに役立つ、API Management の豊富で柔軟な機能セットの概要について説明します。
API Management の API 認証と認可には、API Management ゲートウェイを通じたバックエンド API へのクライアント アプリのエンド ツー エンド通信のセキュリティ保護が含まれます。 多くの顧客環境では、OAuth 2.0 が推奨される API 承認プロトコルです。 API Management では、クライアントと API Management ゲートウェイの間、ゲートウェイとバックエンド API の間、またはその両方の OAuth 2.0 認証が個別にサポートされます。
API Management では、OAuth 2.0 を補完する、または API の OAuth 2.0 認証が不可能な場合に役立つ、その他のクライアント側およびサービス側の認証と認可メカニズムがサポートされています。 これらのオプションの中からどのように選択するかは、組織の API 環境の成熟度、セキュリティとコンプライアンスの要件、および一般的な API の脅威を軽減するための組織のアプローチによって異なります。
重要
ユーザーの API へのアクセスをセキュリティで保護することは、API Management 環境のセキュリティ保護に関する多くの考慮事項のうちの 1 つです。 詳細については、「API Management の Azure セキュリティ ベースライン」を参照してください。
Note
その他の API Management コンポーネントには、ユーザー アクセスをセキュリティで保護し、制限するための個別のメカニズムがあります。
- Azure コントロール プレーンを使用して API Management インスタンスを管理するために、API Management では Microsoft Entra ID と Azure ロールベースのアクセス制御 (RBAC) に依存しています。
- API Management 開発者ポータルでは、セキュリティで保護されたユーザーのサインアップとサインインを容易にするいくつかのオプションがサポートされています。
認証と認可
API へのアクセスのコンテキストでの認証と認可の簡単な説明を次に示します。
認証 - API にアクセスするユーザーまたはアプリの ID を確認するプロセス。 認証は、ユーザー名やパスワードなどの資格情報、証明書、またはシングル サインオン (SSO) やその他の方法を使用して行うことができます。
認可 - 特定の API にアクセスするアクセス許可をユーザーまたはアプリが持っているかどうかを判別するプロセス。多くの場合、OAuth 2.0 などのトークンベースのプロトコルが使用されます。
Note
認証と認可を補完するには、TLS を使用して API へのアクセスもセキュリティで保護し、認証または認可に使用される資格情報またはトークンを保護する必要があります。
OAuth 2.0 の概念
OAuth 2.0 は、Web API などのリソースへのアクセスをセキュリティで保護するために広く使用されている標準的な認可フレームワークです。 OAuth 2.0 では、ユーザーの資格情報を共有することなく、クライアント アプリがユーザーの代わりにリソースに対して実行できる操作が制限されます。 OAuth 2.0 は認証プロトコルではありませんが、OpenID Connect (OIDC) と共によく使用されます。これにより、ユーザー認証と SSO 機能が提供され、OAuth 2.0 が拡張されます。
OAuth フロー
クライアント アプリが TLS と OAuth 2.0 を使用してセキュリティで保護された要求で API を呼び出すと起こることについて説明します。 フローの省略例を次に示します。
クライアント (呼び出し元アプリまたは ベアラー) は、ID プロバイダーに対する資格情報を使用して認証します。
クライアントは、ID プロバイダーの承認サーバーから時間制限付きアクセス トークン (JSON Web トークンまたは JWT) を取得します。
ID プロバイダー (Microsoft Entra ID など) はトークンの "発行者" であり、トークンには、"リソース サーバー" (バックエンド API、API Management ゲートウェイ自体など) へのアクセスを認可する "対象ユーザー要求" が含まれます。
クライアントは API を呼び出し、アクセス トークン (Authorization ヘッダーなど) を提示します。
リソース サーバーがアクセス トークンを検証します。 検証は、発行者と対象ユーザーの要求に予期される値が含まれていることを確認する複雑なプロセスです。
トークンの検証条件に基づいて、バックエンド API のリソースへのアクセスが許可されます。
クライアント アプリの種類とシナリオに応じて、トークンの要求と管理にさまざまな "認可フロー" が必要になります。 たとえば、認可コード フローと付与タイプは、Web API を呼び出すアプリでよく使用されます。 詳細については、Microsoft Entra ID での OAuth フローとアプリケーション シナリオに関する記事を参照してください。
API Management での OAuth 2.0 認可シナリオ
シナリオ 1 - クライアント アプリがバックエンドに対して直接認可する
一般的な認可シナリオは、呼び出し元のアプリケーションがバックエンド API へのアクセスを直接要求し、Authorization ヘッダーの OAuth 2.0 トークンをゲートウェイに提示する場合です。 その後、Azure API Management は呼び出し元とバックエンド API の間の "透過的な" プロキシとして機能し、トークンは変更なしでバックエンドに渡されます。 アクセス トークンのスコープは、呼び出し元のアプリケーションとバックエンド API の間にあります。
次の図は、Microsoft Entra ID が認可プロバイダーである例を示しています。 クライアント アプリは、シングルページ アプリケーション (SPA) である場合があります。
HTTP 要求と共に送信されるアクセス トークンはバックエンド API を対象としていますが、API Management では引き続き多層防御アプローチが可能です。 たとえば、JWT を検証するポリシー、トークンなしで到着した要求を拒否するポリシー、または対象のバックエンド API に対して無効なトークンを構成します。 トークンから抽出された他の目的の要求を確認するように API Management を構成することもできます。
Note
このように Azure API Management を介して公開される API を OAuth 2.0 を使用して保護する場合は、Azure portal または開発者ポータルのテスト コンソール ユーザーの代わりに、テスト目的で有効なトークンを生成するように API Management を構成できます。 API Management インスタンスに OAuth 2.0 サーバーを追加し、API で OAuth 2.0 承認設定を有効にする必要があります。 詳細については、「OAuth 2.0 ユーザー認可を構成して開発者ポータルのテスト コンソールを承認する方法」を参照してください。
例:
ヒント
特殊なケースでは、Microsoft Entra ID を使用して API アクセスが保護されている場合に、トークン検証用に validate-azure-ad-token ポリシーを構成できます。
シナリオ 2 - クライアント アプリが API Management に対して認可する
このシナリオでは、API Management サービスが API に代わって動作し、呼び出し元のアプリケーションは API Management インスタンスへのアクセスを要求します。 アクセス トークンのスコープは、呼び出し元のアプリケーションと API Management ゲートウェイの間にあります。 API Management で、ゲートウェイがバックエンドに要求を渡す前にトークンを検証するポリシー (validate-jwt または validate-azure-ad-token) を構成します。 通常、別のメカニズムによって、ゲートウェイとバックエンド API の間の接続がセキュリティで保護されます。
次の例では、Microsoft Entra ID が再び認可プロバイダーであり、相互 TLS (mTLS) 認証によってゲートウェイとバックエンドの間の接続がセキュリティで保護されます。
これを行う理由はさまざまです。 たとえば次のような点です。
バックエンドがレガシ API であり、OAuth をサポートするように更新できない
API Management は、最初にトークンを検証するように構成する必要があります (少なくとも発行者と対象ユーザーの要求を確認します)。 検証後、API Management からの接続をセキュリティで保護するために使用できるいくつかのオプションのいずれかを使用します (例: 相互 TLS (mTLS) 認証)。 この記事の後半の「サービス側のオプション」を参照してください。
バックエンドで必要なコンテキストを呼び出し元から確立することができない
API Management では、呼び出し元から受信したトークンを正常に検証した後、独自のコンテキストまたは呼び出し元アプリケーションから派生したコンテキストを使用して、バックエンド API のアクセス トークンを取得する必要があります。 このシナリオは、次のいずれかを使用して実現できます。
構成された ID プロバイダーからバックエンド API に対して有効なアクセス トークンを取得するためのカスタム ポリシー (例: send-request)。
API Management インスタンスの独自の ID - API Management リソースのシステムによって割り当てられたマネージド ID またはユーザー割り当てマネージド ID からバックエンド API にトークンを渡します。
組織は、標準化された認可アプローチを採用したいと考えている
組織は、API バックエンドの認証と認可のメカニズムに関係なく、フロントエンドでの標準化された認可アプローチのために OAuth 2.0 に集約することを選択できます。 API Management のゲートウェイを使用すると、組織のバックエンドの進化に伴って、API コンシューマーに対する一貫した認可構成と共通のエクスペリエンスが実現できます。
シナリオ 3: API Management がバックエンドに対する認可を行う
マネージド 接続 (旧称: 承認) では、API Management の資格情報マネージャーを使用して、LinkedIn、GitHub、その他の OAuth 2.0 互換バックエンドなどの 1 つ以上のバックエンドまたは SaaS サービスへのアクセスを承認します。 このシナリオでは、ユーザーまたはクライアント アプリは、ID プロバイダーまたはその他のクライアント側オプションを使用してゲートウェイ アクセスを制御し、API Management ゲートウェイに要求を行います。 その後、ポリシー構成を通じて、ユーザーまたはクライアント アプリはバックエンド認証と認可を API Management に委任します。
次の例では、クライアントとゲートウェイの間でサブスクリプション キーが使用され、GitHub はバックエンド API の資格情報プロバイダーです。
資格情報プロバイダーに接続すると、API Management は OAuth 2.0 フローで API アクセスのトークンを取得して更新します。 接続により、次のような複数のシナリオでトークン管理が簡略化されます:
- クライアント アプリでは、GraphQL リゾルバーを使用して複数のフィールドを解決するために、複数の SaaS バックエンドに対する認可が必要になる場合があります。
- ユーザーは、自分の ID プロバイダーからの SSO によって API Management に対して認証を行いますが、バックエンド SaaS プロバイダー (LinkedIn など) に対しては共通の組織アカウントを使用して認可を行います。
- クライアント アプリ (またはボット) は、認証されたユーザーの代わりに、セキュリティ保護されたバックエンド オンライン リソースにアクセスする必要があります (例: メールの確認や注文の送信など)。
例 :
- 資格情報マネージャーの構成 - Microsoft Graph API
- 資格情報マネージャーの構成 - GitHub API
- 資格情報マネージャーを構成する - バックエンド API へのユーザー委任アクセス
API をセキュリティで保護するためのその他のオプション
認可が推奨され、OAuth 2.0 が API の強力な認可を有効にする主要な方法となっている一方で、API Management には、クライアントとゲートウェイ (クライアント側) 間、またはゲートウェイとバックエンド (サービス側) 間のアクセスをセキュリティで保護または制限するための、その他のいくつかのメカニズムが用意されています。 組織の要件によっては、OAuth 2.0 を補完するためにこれらを使用できます。 または、呼び出し元のアプリケーションまたはバックエンド API がレガシであるか、OAuth 2.0 をまだサポートしていない場合は、これらを個別に構成します。
クライアント側のオプション
| メカニズム | 説明 | 考慮事項 |
|---|---|---|
| mTLS | 接続しているクライアントによって提示された証明書を検証し、API Management で管理されている証明書に対して証明書のプロパティをチェックします | 証明書はキー コンテナーに格納できます。 |
| 呼び出し元 IP を制限する | 特定の IP アドレスまたはアドレス範囲からの呼び出しをフィルター処理 (許可/拒否) します。 | 特定のユーザーまたは組織へのアクセス、またはアップストリーム サービスからのトラフィックへのアクセスを制限するために使用します。 |
| サブスクリプション キー | API Management のサブスクリプションに基づいて 1 つ以上の API へのアクセスを制限します | 別の認証または認可方法に加えて、サブスクリプション (API) キーを使用することもお勧めします。 サブスクリプション キー自体は強力な認証形式ではありませんが、サブスクリプション キーを使用すると、個々の顧客の API の使用状況の追跡や特定の API 製品へのアクセスの許可など、特定のシナリオで役立つ場合があります。 |
ヒント
多層防御を行う場合は、API Management インスタンスの上流に Web アプリケーション ファイアウォールをデプロイすることを強くお勧めします。 たとえば、Azure Application Gateway や Azure Front Door を使います。
サービス側のオプション
| メカニズム | 説明 | 考慮事項 |
|---|---|---|
| マネージド ID の認証 | システム割り当てまたはユーザー割り当て マネージド ID を使用してバックエンド API に対して認証します。 | Microsoft Entra ID からトークンを取得して行われる、保護されたバックエンド リソースへのスコープ指定されたアクセスに推奨されます。 |
| 証明書の認証 | クライアント証明書を使用してバックエンド API に対して認証します。 | 証明書はキー コンテナーに格納できます。 |
| 基本認証 | Authorization ヘッダーを介して渡されるユーザー名とパスワードを使用してバックエンド API に対して認証します。 | より良いオプションを使用できる場合は推奨されません。 |
次の手順
- 認証と承認の詳細については、Microsoft ID プラットフォームを参照してください。
- API Management を使用して OWASP API のセキュリティ脅威を軽減する方法について説明します。