適用対象: Developer | Basic | Basic v2 | Standard | Standard v2 | Premium | Premium v2
API Management には、完全にカスタマイズ可能なスタンドアロンのマネージド開発者ポータルが用意されています。これを、外部 (または内部) から使用することにより、開発者ユーザーは API Management を通じて公開されている API を検出して操作できます。 開発者ポータルには、セキュリティで保護されたユーザーのサインアップとサインインを容易にするオプションがいくつかあります。
注
開発者ポータルでは既定で匿名アクセスが有効になっています。 この既定の設定は、テスト コンソールの使用などの機能は制限されていますが、サインインせずにポータルや API などのコンテンツを表示できることを意味します。 ユーザーがサインインして開発者ポータルを表示する必要がある設定を有効にすることができます。 Azure portal で、API Management インスタンスの左側にあるメニューの [開発者ポータル] で、[ID]>[設定] を選択します。 [匿名ユーザー] で、[匿名ユーザーをサインイン ページにリダイレクトする] を選択 (有効に) します。
認証オプション
外部ユーザー - 外部ユーザー の開発者ポータルへのアクセスを有効にするには、 Microsoft Entra 外部 ID で有効になっている外部 ID プロバイダーを使用します。
- たとえば、ユーザーが既存のソーシャル メディア アカウントを使用して開発者ポータルにアクセスできるようにします。
- このサービスには、エンド ユーザーのサインアップとサインインエクスペリエンスを有効にする機能が用意されています。
現在、API Management では、外部テナントではなく Microsoft Entra ID ワークフォース テナントで構成されている場合、外部 ID プロバイダーがサポートされています。 詳細については、「 Microsoft Entra External ID を使用して開発者アカウントを承認する方法」を参照してください。
注
API Management は、外部 ID プロバイダーとしての Azure Active Directory B2C のレガシ サポートを提供します。 ただし、API Management 開発者ポータルの新しいデプロイには、Azure Active Directory B2C ではなく外部 ID プロバイダーとして Microsoft Entra External ID を使用することをお勧めします。
Von Bedeutung
2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。 詳細については、FAQ を参照してください。
内部ユーザー - 内部ユーザー の開発者ポータルへのアクセスを有効にするには、企業 (従業員) の Microsoft Entra ID テナントを使用します。 Microsoft Entra ID では、開発者ポータルを使用して API にアクセスしてこれを検出する必要がある企業ユーザーにシームレスなシングル サインオン (SSO) エクスペリエンスを提供します。
開発者ポータルで Microsoft Entra 認証を有効にする手順については、「Azure API Management で Microsoft Entra ID を使用して開発者アカウントを承認する方法」を参照してください。
基本認証 - 組み込みの開発者ポータルの ユーザー名とパスワード プロバイダーを 使用します。 このオプションを使用すると、開発者は API Management に直接登録し、API Management ユーザー アカウントを使用してサインインできます。 このオプションを使用したユーザー登録は、CAPTCHA サービスによって保護されます。
注意事項
基本認証を使用して開発者ポータルへのユーザーのアクセスをセキュリティで保護できますが、 Microsoft Entra ID などのより安全な認証方法を構成することをお勧めします。
開発者ポータルのテスト コンソール
開発者ポータルでは、開発者ユーザーがサインアップしてアクセスおよびサインインするための構成が提供されるだけでなく、開発者がバックエンド API に API Management を介してテスト要求を送信できるテスト コンソールも含まれています。 このテスト機能の存在は、Azure portal を使用してサービスを管理する API Management のユーザーにも役立ちます。
OAuth 2.0 を使用して Azure API Management 経由で公開されている API をセキュリティで保護する場合 (つまり、呼び出し元アプリケーション (ベアラー) が有効なアクセス トークンを取得して渡す必要があります。Azure portal または開発者ポータルのテスト コンソール ユーザーに代わって有効なトークンを生成するように API Management を構成できます。 詳細については、「OAuth 2.0 ユーザー認可を構成して開発者ポータルのテスト コンソールを承認する方法」を参照してください。
テスト コンソールで API テスト用の有効な OAuth 2.0 トークンを取得できるようにするには、次のようにします。
インスタンスに OAuth 2.0 ユーザー承認サーバーを追加します。 Microsoft Entra ID、Microsoft Entra External ID、サード パーティの ID プロバイダーなど、任意の OAuth 2.0 プロバイダーを使用できます。
その承認サーバーの設定を使用して API を構成します。 ポータルで、API の [設定] ページ>の [セキュリティ]>[ユーザーの承認] で OAuth 2.0 承認を構成します。
API テスト用のこの OAuth 2.0 構成は、開発者ポータルへのユーザー アクセスに必要な構成とは無関係です。 ただし、ID プロバイダーとユーザーは同じにすることができます。 たとえば、イントラネット アプリケーションでは、企業 ID で SSO を使用して開発者ポータルへのユーザー アクセスを要求できます。 同じ企業 ID が、同じユーザー コンテキストで呼び出し中のバックエンド サービス用のトークンをテスト コンソールを通して取得できます。
シナリオ
さまざまな認証と承認のオプションがさまざまなシナリオに適用されます。 次のセクションでは、3 つのシナリオ例の構成の概要について説明します。 API Management によって公開される API を完全にセキュリティで保護して構成するには、さらに手順を実行する必要があります。 ただし、このシナリオでは、必要な認証と承認を提供するために、各ケースで推奨される最小構成に意図的に重点を置いています。
シナリオ 1 - イントラネット API とアプリケーション
- API Management 共同作成者およびバックエンド API 開発者は、OAuth 2.0 によって保護された API を発行したいと考えています。
- この API は、ユーザーが Microsoft Entra ID を介して SSO を使用してサインインするデスクトップ アプリケーションによって使用されます。
- デスクトップ アプリケーション開発者は、API Management 開発者ポータルを使用して API を検出してテストする必要があります。
主な構成:
| 構成 | リファレンス |
|---|---|
| 企業 ID と Microsoft Entra ID を使用して、API Management 開発者ポータルの開発者ユーザーを承認します。 | Azure API Management で Microsoft Entra ID を使用して開発者アカウントを承認する |
| デスクトップ アプリ開発者がバックエンド API を実行するための有効な OAuth 2.0 トークンを取得するように、開発者ポータルでテスト コンソールを設定します。 Azure portal のテスト コンソールにも同じ構成を使用できます。これには、API Management 共同作成者とバックエンド開発者がアクセスできます。 トークンは、API Management サブスクリプション キーと組み合わせて使用できます。 |
OAuth 2.0 ユーザー承認を構成して開発者ポータルのテスト コンソールを承認する方法 Azure API Management のサブスクリプション |
| アクセス トークンを使用して API Management を介して API が呼び出されたときに、OAuth 2.0 トークンと要求を検証します。 | JWT ポリシーを検証する |
API Management をネットワーク境界に移動し、リバース プロキシを介してイングレスを制御することで、このシナリオをさらに進めます。 参照アーキテクチャについては、「Application Gateway と API Management で API を保護する」を参照してください。
シナリオ 2 - 外部 API、パートナー アプリケーション
- API Management 共同作成者およびバックエンド API 開発者は、Azure API Management を使用してレガシ API を公開するための概念実証をすばやく作成したいと考えています。 API Management を介した API は、外部 (インターネット) に接続されています。
- API はクライアント証明書認証を使用し、パートナーが沖合で開発した新しい公開シングルページ アプリ (SPA) によって使用されます。
- SPA では、OAuth 2.0 と OpenID Connect (OIDC) が使用されます。
- アプリケーション開発者は、テスト バックエンド エンドポイントを使用して、開発者ポータルを使用してテスト環境の API にアクセスし、フロントエンド開発を高速化します。
主な構成:
| 構成 | リファレンス |
|---|---|
| 既定のユーザー名とパスワード認証を使用して、開発者ポータルへのフロントエンド開発者アクセスを構成します。 開発者を開発者ポータルに招待することもできます。 |
開発者ポータルのユーザーをユーザー名とパスワードを使用して認証するように構成する Azure API Management でユーザー アカウントを管理する方法 |
| SPA がアクセス トークンを使用して API Management を呼び出すときに、OAuth 2.0 トークンと要求を検証します。 この場合、対象ユーザーは API Management です。 | JWT ポリシーを検証する |
| バックエンドにクライアント証明書認証を使用するように API Management を設定します。 | Azure API Management でクライアント証明書認証を使用してバックエンド サービスを保護する |
このシナリオをさらに進めるために、 Microsoft Entra 承認と Microsoft EntraB2B コラボレーション で開発者ポータルを使用して、配信パートナーがより緊密に共同作業できるようにします。 開発環境またはテスト環境の RBAC を使用して API Management へのアクセスを委任し、独自の企業資格情報を使用して開発者ポータルに SSO を有効にすることを検討してください。
シナリオ 3 - 外部 API、SaaS、公開
API Management 共同作成者およびバックエンド API 開発者は、コミュニティ開発者が使用できるいくつかの新しい API を作成します。
API は一般公開されていますが、完全な機能はペイウォールの背後で保護され、OAuth 2.0 を使用してセキュリティで保護されています。 ライセンスを購入すると、開発者は、運用環境で使用するために有効な独自のクライアント資格情報とサブスクリプション キーを取得します。
外部コミュニティ開発者は、開発者ポータルを使用して API を検出します。 開発者はサインアップし、ソーシャル メディア アカウントを使用して開発者ポータルにサインインします。
関心のある開発者ポータル ユーザーは、テスト サブスクリプション キーを持っていれば、ライセンスを購入しなくても、テスト コンテキストで API 機能を探索できます。 開発者ポータルのテスト コンソールは、呼び出し元のアプリケーションを表し、バックエンド API への既定のアクセス トークンを生成します。
注意事項
開発者ポータルのテスト コンソールでクライアント資格情報フローを使用する場合は、特別な注意が必要です。 「セキュリティに関する考慮事項」を参照してください。
主な構成:
| 構成 | リファレンス |
|---|---|
| コミュニティ開発者に公開する API の組み合わせを表すように、Azure API Management で製品を設定します。 開発者が API を使用できるようにサブスクリプションを設定します。 |
チュートリアル:製品を作成して発行する Azure API Management のサブスクリプション |
| Microsoft Entra External ID を使用して、開発者ポータルへのコミュニティ開発者アクセスを構成します。 Microsoft Entra External ID は、1 つ以上のダウンストリーム ソーシャル メディア ID プロバイダーと連携するように構成できます。 | Azure API Management で Microsoft Entra External ID を使用して開発者アカウントを承認する方法 |
| クライアント資格情報フローを使用して、バックエンド API に対する有効な OAuth 2.0 トークンを取得するように、開発者ポータルでテスト コンソールを設定します。 |
OAuth 2.0 ユーザー承認を構成して開発者ポータルのテスト コンソールを承認する方法 この記事に示す構成手順を調整して、承認コード付与フローではなくクライアント資格情報付与フローを使用します。 |
ユーザー登録または製品サブスクリプションを委任してさらに進め、独自のロジックでプロセスを拡張します。
関連するコンテンツ
- 認証と承認の詳細については、Microsoft ID プラットフォームを参照してください。
- API Management を使用して OWASP API セキュリティの脅威を軽減する 方法について説明します。