このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
Microsoft Edge をダウンロードする
Internet Explorer と Microsoft Edge の詳細情報
この記事では、
OAuth 2.0 プロトコルと Azure Active Directory (Azure AD)
を使用して、API を保護するように
Azure API Management
インスタンスを構成する大まかな手順を説明します。
API 認可の概念の概要については、
API Management の認証と認可
に関する記事を参照してください。
この記事の手順に従う前に、次のものが必要です。
API Management インスタンス
API Management インスタンスを使用する公開された API
Azure AD テナント
次の手順に従って、OAuth 2.0 承認と Azure AD を使用して API Management で API を保護します。
アプリケーション (この記事では、"バックエンドアプリ" と呼ばれます) を Azure AD に登録して API へのアクセスを保護します。
API にアクセスするには、ユーザーまたはアプリケーションが各 API 要求で、このアプリへのアクセス権を付与する有効な OAuth トークンを取得、提示します。
API Management で
validate-jwt
ポリシーを構成し、各受信 API 要求で提示される OAuth トークンを検証します。 有効な要求は API に渡すことができます。
OAuth 承認フローと、必要な OAuth トークンを生成する方法の詳細については、この記事では取り上げません。 通常、個別のクライアント アプリを使用して、API へのアクセスを承認する Azure AD からトークンが取得されます。 詳細情報へのリンクについては、「
次のステップ
」を参照してください。
API を表すアプリケーションを Azure AD に登録する
Azure portal を使用して、API を表すアプリケーションをまず登録することにより、Azure AD で API を保護します。
アプリの登録の詳細については、次を参照してください。「
クイックスタート:Web API を公開するようにアプリケーションを構成する
」。
Azure portal
で、
[アプリの登録]
を検索して選択します。
[新規登録]
を選択します。
[アプリケーションの登録]
ページが表示されたら、以下のアプリケーションの登録情報を入力します。
[名前]
セクションに、アプリのユーザーに表示されるわかりやすいアプリケーション名を入力します (例:
backend-app
)。
[サポートされているアカウントの種類]
セクションで、シナリオに適したオプションを選択します。
[リダイレクト URI]
セクションは空のままにします。
[登録]
を選択して、アプリケーションを作成します。
アプリの
[概要]
ページで、
[アプリケーション (クライアント) ID]
の値を見つけ、後で使用するために記録します。
サイド メニューの
[管理]
セクションで、
[API の公開]
を選択し、
[アプリケーション ID URI]
を既定値に設定します。 バックエンドアプリへのアクセス用の OAuth 2.0 トークンを取得するために個別のクライアント アプリを開発するには、後で使用するためにこの値を記録しておきます。
[スコープの追加]
ボタンを選択して、
[スコープの追加]
ページを表示します。
新しい
[スコープ名]
、
[管理者の同意の表示名]
、
[管理者の同意の説明]
を入力します。
[有効]
のスコープ状態が選択されていることを確認します。
[Scope の追加]
ボタンを選択してスコープを作成します。
前の 2 つの手順を繰り返して、API でサポートされているすべてのスコープを追加します。
スコープが作成されたら、後で使用するためにそれらを書き留めておきます。
次のポリシーの例では、
<inbound>
ポリシー セクションに追加された場合、Authorization ヘッダーで提示されている Azure AD から取得されたアクセス トークン内の対象ユーザーのクレーム値をチェックします。 トークンが有効ではない場合、エラー メッセージを返します。 シナリオに適したポリシー スコープでこのポリシーを構成します。
openid-config
URL で、
aad-tenant
は Azure AD のテナント ID です。 この値は、Azure portal (Azure AD リソースの
[概要]
ページなど) で見つけます。 ここに示す例では、シングルテナントの Azure AD アプリと v2 構成エンドポイントを想定しています。
claim
の値は、Azure AD に登録したバックエンド アプリのクライアント ID です。
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/{aad-tenant}/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud">
<value>{backend-app-client-id}</value>
</claim>
</required-claims>
</validate-jwt>
上記の openid-config URL は、v2 エンドポイントに対応しています。 v1 openid-config エンドポイントの場合は、https://login.microsoftonline.com/{aad-tenant}/.well-known/openid-configuration を使用します。
ポリシーの構成方法については、ポリシーの設定と編集に関する記事をご覧ください。 JWT 検証に関するその他のカスタマイズについては、validate-jwt リファレンスを参照してください。
承認ワークフロー
ユーザーまたはアプリケーションが、バックエンドアプリへのアクセス権を付与するアクセス許可を持つトークンを Azure AD から取得します。
API Management への API 要求の Authorization ヘッダーにトークンが追加されます。
API Management で、validate-jwt ポリシーを使用してトークンが検証されます。
要求に有効なトークンがない場合、API Management はそれをブロックします。
要求に有効なトークンが付随する場合、ゲートウェイは API に要求を転送できます。
