

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# スコープ、M2M、リソースサーバー
<a name="cognito-user-pools-define-resource-servers"></a>

ユーザープールのドメインを設定すると、Amazon Cognito は OAuth 2.0 認可サーバーおよびホストされたウェブ UI を自動的にプロビジョニングします。このウェブ UI により、アプリケーションはユーザーにサインアップページとサインインページを表示できます。詳細については、「[ユーザープールのマネージドログイン](cognito-user-pools-managed-login.md)」を参照してください。認可サーバーによってアクセストークンに追加するスコープを選択できます。スコープはリソースサーバーとユーザーデータへのアクセスを許可します。

*リソースサーバー*とは、OAuth 2.0 API サーバーのことです。リソースサーバーは、アクセスが保護されたリソースを保護するために、保護対象の API でリクエストされたメソッドとパスを承認するスコープが、ユーザープールのアクセストークンに含まれていることを検証します。トークンの署名に基づく発行者の検証、トークンの有効期限に基づく有効性の検証、トークンクレームのスコープに基づくアクセスレベルの検証を行います。ユーザープールスコープは、アクセストークンの `scope` クレームにあります。Amazon Cognito アクセストークンのクレームの詳細については、「[アクセストークンの理解](amazon-cognito-user-pools-using-the-access-token.md)」を参照してください。

Amazon Cognito を使用すると、アクセストークンのスコープは、外部 API またはユーザー属性へのアクセスを認可できます。アクセストークンは、ローカルユーザー、フェデレーションユーザー、またはマシン ID に発行できます。

**Topics**
+ [API 認可](#cognito-user-pools-define-resource-servers-about-api-authz)
+ [Machine to machine (M2M) 認可](#cognito-user-pools-define-resource-servers-about-m2m)
+ [スコープについて](#cognito-user-pools-define-resource-servers-about-scopes)
+ [リソースサーバーについて](#cognito-user-pools-define-resource-servers-about-resource-servers)
+ [リソースバインディング](#cognito-user-pools-resource-binding)

## API 認可
<a name="cognito-user-pools-define-resource-servers-about-api-authz"></a>

以下は、Amazon Cognito トークンを使用して API へのリクエストを認可する方法の一部です。

**アクセストークン**  
Amazon Cognito オーソライザーを REST API メソッドリクエスト設定に追加する場合は、オーソライザー設定に **[認可スコープ]** を追加します。この設定では、API は `Authorization` ヘッダー内のアクセストークンを受け入れたうえで、受け入れたスコープについてレビューします。

**ID トークン**  
有効な ID トークンを REST API の Amazon Cognito オーソライザーに渡すと、API Gateway はリクエストを受け入れ、ID トークンの内容を API バックエンドに渡します。

**Amazon Verified Permissions**  
Verified Permissions では、[API にリンクされたポリシーストア](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores_api-userpool.html)を作成するオプションがあります。Verified Permissions は、リクエスト `Authorization` ヘッダーから ID トークンまたはアクセストークンを処理する Lambda オーソライザーを作成して割り当てます。この Lambda オーソライザーは、トークンをポリシーストアに渡します。ここで、Verified Permissions はトークンをポリシーと比較し、オーソライザーに許可または拒否の決定を返します。

**その他のリソース**
+ [API Gateway での REST API へのアクセスの制御と管理](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)
+ [Amazon Verified Permissions による承認](amazon-cognito-authorization-with-avp.md)

## Machine to machine (M2M) 認可
<a name="cognito-user-pools-define-resource-servers-about-m2m"></a>

Amazon Cognito は、*マシン ID* を使用して API データにアクセスするアプリケーションをサポートしています。ユーザープール内のマシン ID は、アプリケーションサーバー上で実行され、リモート API に接続する[機密クライアント](user-pool-settings-client-apps.md#user-pool-settings-client-app-client-types)です。オペレーションは、スケジュールされたタスク、データストリーム、アセットの更新など、ユーザーとのインタラクションなしで行われます。これらのクライアントは、アクセストークンを使用してリクエストを認可すると、*Machine to Machine* (M2M) 認可を実行します。M2M 認可では、共有シークレットがアクセスコントロールのユーザー認証情報を置き換えます。

M2M 認可で API にアクセスするアプリケーションには、クライアント ID とクライアントシークレットが必要です。ユーザープールでは、クライアント認証情報の付与をサポートするアプリケーションクライアントを構築する必要があります。クライアント認証情報をサポートするには、アプリケーションクライアントにクライアントシークレットが必要であり、ユーザープールドメインがなくてはなりません。このフローでは、マシン ID は [トークンエンドポイント](token-endpoint.md) から直接アクセストークンをリクエストします。クライアント認証情報の付与には、アクセストークン内の[リソースサーバー](#cognito-user-pools-define-resource-servers-about-resource-servers)からのカスタムスコープのみを認可できます。アプリケーションクライアントのセットアップの詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。

クライアント認証情報の付与からのアクセストークンは、マシン ID が API にリクエストすることを許可するオペレーションの検証可能なステートメントです。アクセストークンが API リクエストを認可する方法の詳細については、引き続きお読みください。アプリケーションの例については、「[Amazon Cognito and API Gateway based machine to machine authorization using AWS CDK](https://github.com/aws-samples/amazon-cognito-and-api-gateway-based-machine-to-machine-authorization-using-aws-cdk)」を参照してください。

M2M 認可には、月間アクティブユーザー (MAU) に請求する方法とは異なる請求モデルがあります。ユーザー認証にアクティブなユーザーあたりのコストがかかる場合、M2M 請求にはアクティブなクライアント認証情報アプリケーションクライアントと、トークンリクエストの合計ボリュームが反映されます。詳細については、「[Amazon Cognito の料金](https://aws.amazon.com/cognito/pricing)」を参照してください。M2M 認可のコストを制御するには、アクセストークンの期間と、アプリケーションが行うトークンリクエストの数を最適化します。API Gateway キャッシングを使用して M2M 認可の新しいトークンのリクエストを減らす方法については、「[ユーザープールトークンの有効期限とキャッシュの管理](amazon-cognito-user-pools-using-tokens-caching-tokens.md)」を参照してください。

 AWS 請求書にコストを追加する Amazon Cognito オペレーションの最適化については、「」を参照してください[のコスト管理](tracking-cost.md#tracking-cost-managing)。

**Machine to Machine (M2M) クライアント認証情報のクライアントメタデータ**  
[クライアントメタデータ](cognito-user-pools-working-with-lambda-triggers.md#working-with-lambda-trigger-client-metadata)は M2M リクエストで渡すことができます。クライアントメタデータは、[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md) の結果に役立つユーザーまたはアプリケーション環境からの追加情報です。ユーザープリンシパルによる認証オペレーションでは、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) API リクエストおよび [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) API リクエストの本文で、クライアントメタデータをトークン生成前トリガーに渡すことができます。アプリケーションは、[トークンエンドポイント](token-endpoint.md)への直接リクエストを使用して M2M のアクセストークン生成フローを実行するため、異なるモデルとなります。クライアント認証情報のトークンリクエストの POST 本文で、クライアントメタデータオブジェクトを URL エンコード (`x-www-form-urlencoded`) した `aws_client_metadata` パラメータを文字列に渡します。リクエスト例については、「[基本認可によるクライアント認証情報POST 本文認可によるクライアント認証情報](token-endpoint.md#exchanging-client-credentials-for-an-access-token-in-request-body)」を参照してください。次に示すのは、キーと値のペア `{"environment": "dev", "language": "en-US"}` を渡すパラメータの例です。

```
aws_client_metadata=%7B%22environment%22%3A%20%22dev%22,%20%22language%22%3A%20%22en-US%22%7D
```

## スコープについて
<a name="cognito-user-pools-define-resource-servers-about-scopes"></a>

*スコープ*はアプリがリソースにリクエストできるアクセスのレベルです。Amazon Cognito アクセストークンのスコープは、ユーザープールで設定した信頼 (既知のデジタル署名を持つアクセストークンの信頼できる発行者) によってバックアップされます。ユーザープールが生成できるアクセストークンのスコープでは、顧客が自分のユーザープロファイルの一部または全部の管理や、バックエンド API からのデータの取得を許可されていることを証明します。Amazon Cognito ユーザープールが発行するアクセストークンのスコープには、*ユーザープールのリザーブド API スコープ*、*カスタムスコープ*、および *OpenID Connect (OIDC) スコープ*があります。

**ユーザープールのリザーブド API スコープ**  
`aws.cognito.signin.user.admin` スコープは、Amazon Cognito ユーザープール API の現在のユーザーのセルフサービスオペレーションを認可します。アクセストークンのベアラーに対して、当該ベアラーに関するすべての情報を、[GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) や [UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html) などの API オペレーションを使用してクエリおよび更新することを認可します。Amazon Cognito ユーザープール API でユーザーを認証する場合は、このスコープだけをアクセストークンで受け取ります。また、アプリケーションクライアントにユーザー属性の読み取りと書き込みを許可している場合、このユーザー属性の読み取りと書き込みに必要な唯一のスコープでもあります。このスコープは、[認可エンドポイント](authorization-endpoint.md) へのリクエストでリクエストすることもできます。このスコープだけでは、[userInfo エンドポイント](userinfo-endpoint.md) にユーザー属性をリクエストするには不十分です。ユーザープール API とユーザーへの `userInfo` リクエストの両方を承認するアクセストークンについては、`/oauth2/authorize` リクエストで `openid` スコープと `aws.cognito.signin.user.admin` スコープの両方をリクエストする必要があります。**

**カスタムスコープ**  
カスタムスコープは、リソースサーバーで保護する外部 API へのリクエストを承認します。カスタムスコープを他の種類のスコープと一緒にリクエストできます。カスタムスコープの詳細については、このページ全体を通じて説明しています。

**OpenID Connect (OIDC) のスコープ**  
ユーザープール認可サーバー (マネージドログインを含む) でユーザーを認証する場合は、スコープをリクエストする必要があります。ユーザープールのローカルユーザーとサードパーティのフェデレーションユーザーは、Amazon Cognito 認可サーバーで認証できます。OIDC スコープは、ユーザープールの [userInfo エンドポイント](userinfo-endpoint.md) からユーザー情報を読み取ることをアプリケーションに認可します。`userInfo` エンドポイントからユーザー属性をクエリする OAuth モデルでは、ユーザー属性に対する大量のリクエストに合わせてアプリケーションを最適化できます。`userInfo` エンドポイントは、アクセストークンのスコープによって決まるアクセス許可レベルで属性を返します。以下の OIDC スコープでアクセストークンを発行することをアプリケーションクライアントに認可できます。

openid  
OpenID Connect (OIDC) クエリの最小スコープ。ID トークン、一意の識別子のクレーム `sub`、および他のスコープをリクエストする機能を承認します。  
`openid` スコープをリクエストし、それ以外をリクエストしない場合、ユーザープール ID トークンと `userInfo` レスポンスには、アプリケーションクライアントが読み取ることができるすべてのユーザー属性のクレームが含まれます。`openid` や他の OIDC スコープ (`profile`、`email`、`phone` など) をリクエストすると、ID トークンと [userInfo](userinfo-endpoint.md#userinfo-endpoint.title) レスポンスの内容は追加のスコープの制約に制限されます。  
例えば、[認可エンドポイント](authorization-endpoint.md) へのリクエストでパラメータ `scope=openid+email` を使用すると、`sub`、`email`、`email_verified` を含む ID トークンが返されます。このリクエストのアクセストークンは、[userInfo エンドポイント](userinfo-endpoint.md) から同じ属性を返します。リクエストでパラメータ `scope=openid` を使用すると、ID トークンと `userInfo` 内のクライアントが読み取り可能なすべての属性が返されます。

profile  
アプリクライアントが読み取ることができるすべてのユーザー属性を承認します。

email  
ユーザー属性 `email` および `email_verified` を承認します。Amazon Cognito は、値が明示的に設定されている場合、`email_verified` を返します。

phone  
ユーザー属性 `phone_number` および `phone_number_verified` を承認します。

## リソースサーバーについて
<a name="cognito-user-pools-define-resource-servers-about-resource-servers"></a>

リソースサーバー API は、データベース内の情報へのアクセスを許可したり、IT リソースを制御したりすることができます。Amazon Cognito のアクセストークンは、OAuth 2.0 をサポートする API へのアクセスを許可できます。Amazon API Gateway REST API には、Amazon Cognito のアクセストークンによる認可の[組み込みサポート](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)があります。アプリは、API コール内でアクセストークンをリソースサーバーに渡します。リソースサーバーはアクセストークンを検査し、アクセスを付与するかどうかを決定します。

Amazon Cognito は、ユーザープールのアクセストークンのスキーマを将来更新する可能性があります。アプリケーションがアクセストークンを API に渡す前に、アクセストークンの内容を分析する場合は、スキーマの更新を受け入れるようにコードを設計する必要があります。

カスタムスコープはユーザーが定義するスコープであり、ユーザープールの承認機能を拡張して、ユーザーとユーザー属性のクエリや変更とは関係のない目的にも対応できるようにします。例えば、写真用のサーバーリソースがある場合、2 つのスコープを定義することが考えられます。写真への読み取りアクセス用の `photos.read` と、書き込み/削除アクセス用の `photos.write` です。アクセストークンを承認して許可するように API を設定し、`scope` クレームでの `photos.read` によるアクセストークンへの `HTTP GET` リクエスト、および `photos.write` によるトークンへの `HTTP POST`リクエストを許可できます。これらは*カスタムスコープ*です。

**注記**  
リソースサーバーはトークン内のクレームを処理する前に、アクセストークンの署名と有効期限を検証する必要があります。トークンの検証の詳細については、「[JSON ウェブトークンの検証](amazon-cognito-user-pools-using-tokens-verifying-a-jwt.md)」を参照してください。Amazon API Gateway でユーザープールのトークンを検証および使用する方法の詳細については、ブログ「[Amazon Cognito ユーザープールと API Gateway の統合](https://aws.amazon.com/blogs/mobile/integrating-amazon-cognito-user-pools-with-api-gateway/)」を参照してください。API Gateway は、アクセストークンの検証とリソースの保護に適したオプションです。API Gateway カスタムオーソライザーの詳細については、「[API Gateway Lambda オーソライザーを使用する](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)」を参照してください。

**概要:**  
Amazon Cognito を使用すると、OAuth2.0 **リソースサーバー**を作成し、これらに**カスタムスコープ**を関連付けることができます。アクセストークンのカスタムスコープは、API の特定のアクションを許可します。ユーザープール内のどのアプリケーションクライアントに対しても、任意のリソースサーバーからカスタムスコープを発行することを許可できます。カスタムスコープをアプリケーションクライアントに関連付け、これらのスコープを [トークンエンドポイント](token-endpoint.md)から OAuth2.0 認可コード付与、暗黙的な付与、クライアント認証情報付与でリクエストできます。Amazon Cognito は、アクセストークンの `scope` クレームにカスタムスコープを追加します。クライアントはサーバーリソースに対してアクセストークンを使用して、トークンに存在するスコープに基づいて承認を判断できます。アクセストークンスコープの詳細については、「[ユーザープールのトークンの使用](amazon-cognito-user-pools-using-tokens-with-identity-providers.md)」を参照してください。

![\[リソースサーバーのフローの概要。クライアントはカスタムスコープでの付与をリクエストし、ユーザープールはカスタムスコープでアクセストークンを返し、クライアントはアクセストークンを API に提示します。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/resource-servers.png)


カスタムスコープでアクセストークンを取得するには、アプリケーションは認可コードを引き換えるか、クライアント認証情報の付与をリクエストするために、[トークンエンドポイント](token-endpoint.md) にリクエストを行う必要があります。マネージドログインでは、暗黙的な付与からアクセストークン内のカスタムスコープをリクエストすることもできます。

**注記**  
[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) リクエストと [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) リクエストは、ユーザープールを IdP として人間との対話型の認証を行うように設計されているため、アクセストークンの `scope` クレームを単一の値 `aws.cognito.signin.user.admin` で生成するだけです。

**リソースサーバーおよびカスタムスコープの管理**

リソースを作成するときに、リソースサーバー名とリソースサーバー識別子を指定する必要があります。リソースサーバーに作成したスコープごとに、スコープ名と説明を指定する必要があります。
+ **リソースサーバー名**: リソースサーバーのわかりやすい名前 (`Solar system object tracker` や `Photo API` など)。
+ **リソースサーバーの識別子**: リソースサーバーの一意の識別子。識別子は、API に関連付ける任意の名前 (`solar-system-data` など) です。API URI パスへの直接参照のように長い識別子 (`https://solar-system-data-api.example.com` など) を設定できますが、文字列が長くなるとアクセストークンのサイズが大きくなります。
+ **スコープ名**: `scope` クレームに必要な値。例えば、`sunproximity.read`。
+ **説明**: スコープのわかりやすい説明。例えば、`Check current proximity to sun`。

Amazon Cognito では、ユーザープールのローカルユーザーであるか、サードパーティ ID プロバイダーのフェデレーションユーザーであるかに関係なく、すべてのユーザーのアクセストークンにカスタムスコープを含めることができます。マネージドログインを含む OAuth 2.0 認可サーバーによる認証フロー中に、ユーザーのアクセストークンのスコープを選択できます。ユーザーの認証は、リクエストパラメータの 1 つとして `scope` を使用して [認可エンドポイント](authorization-endpoint.md) で開始する必要があります。リソースサーバーには次の形式が推奨されます。識別子として、API のわかりやすい名前を使用します。カスタムスコープには、リソースサーバーが許可するアクションを使用します。

```
resourceServerIdentifier/scopeName
```

例えば、カイパーベルトで新しい小惑星を発見し、それを `solar-system-data` API を通じて登録するとします。小惑星のデータベースへの書き込み操作を許可するスコープは `asteroids.add` です。発見の登録を許可するアクセストークンをリクエストするときは、`scope` HTTPS リクエストパラメータを `scope=solar-system-data/asteroids.add` としてフォーマットします。

スコープをリソースサーバーから削除しても、すべのクライアントとの関連付けは削除されません。代わりに、スコープが inactive とマークされます。**Amazon Cognito はアクセストークンに非アクティブなスコープを追加しませんが、それ以外はアプリからのスコープのリクエストを通常どおりに処理します。後でスコープをリソースサーバーに再度追加すると、Amazon Cognito はそのスコープを再度アクセストークンに書き込みます。アプリケーションクライアントに関連付けていないスコープをリクエストすると、ユーザープールのリソースサーバーからスコープを削除したかどうかに関係なく、認証は失敗します。

 AWS マネジメントコンソール、API、または CLI を使用して、ユーザープールのリソースサーバーとスコープを定義できます。

### ユーザープールのリソースサーバーを定義する (AWS マネジメントコンソール)
<a name="cognito-user-pools-define-resource-servers-console"></a>

を使用して AWS マネジメントコンソール 、ユーザープールのリソースサーバーを定義できます。

**リソースサーバーを定義する**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)にサインインします。

1. ナビゲーションペインで **[User Pools]** (ユーザープール) を選択してから、編集するユーザープールを選択します。

1. **[ブランディング]** の下で **[ドメイン]** メニューを選択し、**[リソースサーバー]** を見つけます。

1. **[Create a resource server]** (リソースサーバーの作成) を選択します。

1. **[Resource server name]** (リソースサーバー名) を入力します。例えば、`Photo Server`。

1. **[Resource server identifier]** (リソースサーバー識別子) を入力します。例えば、`com.example.photos`。

1. リソースの **[Custom scopes]** (カスタムスコープ) (例: `read` および `write` ) を入力します。

1. **[Scope name]** (スコープ名) ごとに **[Description]** (説明) (例: `view your photos` および `update your photos`) を入力します。

1. **[作成]** を選択します。

カスタムスコープは、**[ドメイン]** メニューで **[リソースサーバー]** の **[カスタムスコープ]** 列で確認できます。カスタムスコープは、アプリケーションクライアントに対して **[アプリケーション]** の **[アプリケーションクライアント]** で有効にすることができます。アプリケーションクライアントを選択し、**[ログインページ]** を見つけて **[編集]** を選択します。**[Custom scopes]** (カスタムスコープ) を追加し、**[Save changes]** (変更の保存) を選択します。

### ユーザープール (AWS CLI および AWS API) のリソースサーバーの定義
<a name="cognito-user-pools-define-resource-servers-cli-api"></a>

次のコマンドを使用して、ユーザープールのリソースサーバー設定を指定します。

**リソースサーバーを作成する**
+ AWS CLI: `aws cognito-idp create-resource-server`
+ AWS API: [CreateResourceServer](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateResourceServer.html)

**リソースサーバーの設定に関する情報を取得する**
+ AWS CLI: `aws cognito-idp describe-resource-server`
+ AWS API: [DescribeResourceServer](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeResourceServer.html)

**ユーザープールのすべてのリソースサーバーに関する情報を一覧表示する**
+ AWS CLI: `aws cognito-idp list-resource-servers`
+ AWS API: [ListResourceServers](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListResourceServers.html)

**リソースサーバーを削除するには**
+ AWS CLI: `aws cognito-idp delete-resource-server`
+ AWS API: [DeleteResourceServer](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteResourceServer.html)

**リソースサーバーの設定を更新する**
+ AWS CLI: `aws cognito-idp update-resource-server`
+ AWS API: [UpdateResourceServer](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateResourceServer.html)

## リソースバインディング
<a name="cognito-user-pools-resource-binding"></a>

リソースバインディング (リソースインジケーターとも呼ばれます) を使用すると、ユーザープールの認可サーバーに対して API 固有の付与をリクエストできます。リソースバインディングは、[RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) に定義されている OAuth 2.0 の拡張機能です。これにより、クライアントは認可リクエスト時に、どのリソースサーバーにアクセスするかを明示的に指定できます。リソースバインディングを使用すると、API 設定では、特に意図されていないトークンへのアクセスを拒否できます。

**注記**  
アクセストークンは、ユーザーのリソースにのみバインドできます。クライアント認証情報の M2M 付与を使用してリソースバインディングをリクエストすることはできません。

Amazon Cognito ユーザープールでリソースバインディングを使用する場合、クライアントはユーザープール認可サーバーに対する認証リクエストに `resource` パラメータを含めることができます。ユーザープールは、リクエストされたリソースの値が URL であり、[アプリケーションクライアント](user-pool-settings-client-apps.md#cognito-user-pools-app-idp-settings-about)のコールバック URL (`localhost` 専用の `https://` と `http://`、または `myapp://` などのカスタムスキーム) と同じスキームルールに従っていることを検証します。Amazon Cognito は、[アクセストークン](amazon-cognito-user-pools-using-the-access-token.md)の `aud` クレームで、リクエストされた URI をオーディエンスとして設定します。リクエストされたリソースがユーザープールのリソースサーバーである場合、リソースサーバーの識別子は URL 形式である必要があります。認証リクエストごとに 1 つのリソースをリクエストできます。

この機能は、ユーザープールの OAuth 2.0 認可サーバーによる[マネージドログイン認証](authentication-flows-selection-managedlogin.md)専用です。リソースバインディングは、[認可エンドポイント](authorization-endpoint.md)からの暗黙的な付与および認証コード付与でリクエストできます。[トークンエンドポイント](token-endpoint.md)からのトークン更新の付与は、元のリクエストから `aud` クレームを継承します。現在、[SDK 認証モデル](authentication-flows-selection-sdk.md)では使用できません。

**Amazon Cognito ユーザープールでリソースバインディングを実装する**

1. 一意の識別子を使用して、ユーザープール内の 1 つ以上のリソースサーバーを設定します。

1. `/oauth2/authorize` への認可リクエストでは、認可コードまたは暗黙的な付与をリクエストし、`resource` パラメータを含めます。`resource` の値は、URL 形式のリソースサーバー識別子または URL である必要があります。例えば、`&resource=https://solar-system-data-api.example.com`。

1. 認可サーバーは、リソースリクエストを検証して認証を完了し、アクセストークンの `aud` クレームを、リクエストされたリソース URL に設定します。

1. トークンがリクエスト先に発行されたことを検証するために、ユーザーのアクセストークンを使用するリソースは、`aud` クレームをチェックします。