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

# Amazon Cognito user pools
<a name="cognito-user-pools"></a>

Amazon Cognito ユーザープールは、ウェブおよびモバイルアプリケーションの認証と認可のためのユーザーディレクトリです。アプリケーションの観点から見ると、Amazon Cognito ユーザープールは OpenID Connect (OIDC) ID プロバイダー (OIDC) です。ユーザープールには、セキュリティ、ID フェデレーション、アプリ統合、ユーザーエクスペリエンスのカスタマイズなどの機能が何層も追加されます。

例えば、ユーザーのセッションが信頼できるソースからのものであることを確認できます。Amazon Cognito ディレクトリを外部 ID プロバイダーと組み合わせることができます。お好みの AWS SDK を使用して、アプリに最適な API 認可モデルを選択できます。また、Amazon Cognito のデフォルトの動作を変更またはオーバーホールする  AWS Lambda  関数を追加することもできます。

![\[ユーザープールの仕組みの概要を示す図。クライアントは、 AWS SDK またはユーザープールに組み込まれた OIDC IdP を使用してアプリケーションビルドでサインインできます。ユーザープールは、複数のソーシャル ID プロバイダー、OpenID Connect ID プロバイダー、SAML 2.0 ID プロバイダーのサインインプロセスも統合します。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/scenario-authentication-cup.png)


**Topics**
+ [機能](#cognito-user-pools-features)
+ [ユーザープールの機能プラン](cognito-sign-in-feature-plans.md)
+ [Amazon Cognito ユーザープールに対するセキュリティのベストプラクティス](user-pool-security-best-practices.md)
+ [Amazon Cognito ユーザープールによる認証](authentication.md)
+ [サードパーティーの ID プロバイダーを使用したユーザープールへのサインイン](cognito-user-pools-identity-federation.md)
+ [ユーザープールのマネージドログイン](cognito-user-pools-managed-login.md)
+ [Lambda トリガーを使用したユーザープールワークフローのカスタマイズ](cognito-user-pools-working-with-lambda-triggers.md)
+ [ユーザープール内のユーザーを管理する](managing-users.md)
+ [ユーザープール JSON ウェブトークン (JWT) の理解](amazon-cognito-user-pools-using-tokens-with-identity-providers.md)
+ [サインイン完了後にリソースにアクセスする](accessing-resources.md)
+ [スコープ、M2M、リソースサーバー](cognito-user-pools-define-resource-servers.md)
+ [ユーザープールの機能を設定する](user-pools-configure-features.md)
+ [Amazon Cognito ユーザープールのセキュリティ機能を使用する](managing-security.md)
+ [ユーザープールのエンドポイントとマネージドログインのリファレンス](cognito-userpools-server-contract-reference.md)

## 機能
<a name="cognito-user-pools-features"></a>

Amazon Cognito ユーザープには次の機能があります。

### サインアップ
<a name="cognito-user-pools-sign-up"></a>

Amazon Cognito ユーザープールには、ユーザープールにユーザープロファイルを追加するためのユーザー主導型、管理者主導型、およびプログラムによる方法があります。Amazon Cognito ユーザープールは、以下のサインアップモデルをサポートしています。アプリでは、これらのモデルを任意に組み合わせて、アプリで使用できます。

**重要**  
ユーザープールでユーザーサインアップを有効にすると、インターネット上のすべてのユーザーがアカウントにサインアップしてアプリケーションにサインインできるようになります。アプリケーションをパブリックサインアップで開く場合を除き、ユーザープールで自己登録を有効にしないでください。この設定を変更するには、ユーザープールコンソールの **[認証]** の下にある **[サインアップ]** メニューで **[セルフサービスのサインアップ]** を更新するか、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) または [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストで [AllowAdminCreateUserOnly](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUserConfigType.html#CognitoUserPools-Type-AdminCreateUserConfigType-AllowAdminCreateUserOnly) の値を更新します。  
ユーザープールに設定できるセキュリティ機能については、「[Amazon Cognito ユーザープールのセキュリティ機能を使用する](managing-security.md)」を参照してください。

1. ユーザーはアプリに情報を入力し、ユーザープールにネイティブなユーザープロファイルを作成できます。API サインアップオペレーションを呼び出して、ユーザープールにユーザーを登録できます。これらのサインアップ操作は誰にでも公開することも、クライアントシークレットまたは  AWS  認証情報を使用して認可することもできます。

1. ユーザーを Amazon Cognito への情報の受け渡しを許可できるサードパーティーの IdP にリダイレクトできます。Amazon Cognito は、OIDC ID トークン、OAuth 2.0 `userInfo` データ、および SAML 2.0 アサーションを処理して、ユーザープールのユーザープロファイルに入れます。Amazon Cognito に受信させる属性は、属性マッピングルールに基づいて制御します。

1. パブリックサインアップやフェデレーションサインアップをスキップして、独自のデータソースとスキーマに基づいてユーザーを作成できます。Amazon Cognito コンソールまたは API でユーザーを直接追加できます。CSV ファイルからのユーザーをインポートします。既存のディレクトリで新しいユーザーを検索し、既存のデータからユーザープロファイルを入力するjust-in-time AWS Lambda 関数を実行します。

ユーザーがサインアップしたら、Amazon Cognito がアクセストークンと ID トークンにリストするグループにユーザーを追加できます。ID トークンをアイデンティティプールに渡すときに、ユーザープールグループを IAM ロールにリンクすることもできます。

**関連トピック**
+ [ユーザープール内のユーザーを管理する](managing-users.md)
+ [API、OIDC、マネージドログインページの認証についての理解](authentication-flows-public-server-side.md#user-pools-API-operations)
+ [SDK を使用した Amazon Cognito ID プロバイダーのコード例 AWS SDKs](service_code_examples_cognito-identity-provider.md)

### サインイン
<a name="cognito-user-pools-sign-in"></a>

Amazon Cognito は、スタンドアロンのユーザーディレクトリおよび ID プロバイダー (IdP) として使用し、アプリケーションの ID プロバイダー (IdP) として使用できます。ユーザーは、Amazon Cognito がホストするマネージドログインページを使用するか、Amazon Cognito ユーザープール API を介してカスタム構築されたユーザー認証サービスを使用してサインインできます。カスタム構築されたフロントエンドの背後にあるアプリケーション層は、正当なリクエストであることを確認する複数の方法のいずれかを使用して、リクエストをバックエンドで承認できます。

ユーザーは、ユーザー名とパスワード、パスキー、E メールおよび SMS メッセージのワンタイムパスワードを設定してサインインできます。外部ユーザーディレクトリとの統合サインイン、サインイン後の多要素認証 (MFA)、記憶されているデバイスの信頼、独自に設計したカスタム認証フローを提供できます。

外部ディレクトリ (オプションで Amazon Cognito に組み込まれたユーザーディレクトリと組み合わせる) を使用してユーザーをサインインさせるには、次の統合を追加できます。

1. OAuth 2.0 ソーシャルサインインを使用してサインインし、顧客ユーザーデータをインポートします。Amazon Cognito は、OAuth 2.0 による Google、Facebook、Amazon、および Apple へのサインインをサポートしています。

1. SAML および OIDC サインインを使用してサインインし、職場および学校のユーザーデータをインポートします。Amazon Cognito は、任意の SAMID Connect (OIDC) ID プロバイダー (IdP) からのクレームを受け入れるように設定することもできます。

1.  外部ユーザープロファイルをネイティブユーザープロファイルにリンクします。リンクされたユーザーは、サードパーティーのユーザー ID を使用してサインインし、組み込みディレクトリのユーザーに割り当てたアクセス権を受け取ることができます。

**関連トピック**
+ [サードパーティーの ID プロバイダーを使用したユーザープールへのサインイン](cognito-user-pools-identity-federation.md)
+ [フェデレーションユーザーを既存のユーザープロファイルにリンクする](cognito-user-pools-identity-federation-consolidate-users.md)

**マシンツーマシン認可**  
一部のセッションは、人間からマシンへのインタラクションではありません。自動プロセスによって API へのリクエストを承認できるサービスアカウントが必要になる場合があります。OAuth 2.0 スコープを使用して Machine to Machine 認証用のアクセストークンを生成するには、[クライアント認証情報の付与](https://www.rfc-editor.org/rfc/rfc6749#section-4.4)を生成するアプリケーションクライアントを追加します。

**関連トピック**
+ [スコープ、M2M、リソースサーバー](cognito-user-pools-define-resource-servers.md)

### マネージドログイン
<a name="cognito-user-pools-hosted-ui"></a>

ユーザーインターフェイスを構築しない場合は、カスタマイズしたマネージドログインパージをユーザーに提供できます。マネージドログインとは、サインアップ、サインイン、多要素認証 (MFA)、パスワードリセットのための一連のウェブページです。マネージドログインを既存のドメインに追加するか、 AWS サブドメインでプレフィックス識別子を使用できます。

**関連トピック**
+ [ユーザープールのマネージドログイン](cognito-user-pools-managed-login.md)
+ [ユーザープールのドメインを設定する](cognito-user-pools-assign-domain.md)

### セキュリティ
<a name="cognito-user-pools-security"></a>

ローカルユーザーは、SMS メッセージや Eメールメッセージのコード、または多要素認証 (MFA) コードを生成するアプリケーションを使用して、追加の認証要素を提供できます。アプリケーション内で MFA を設定および処理するメカニズムを構築することも、マネージドログインで MFA を管理することも可能です。Amazon Cognito ユーザープールは、ユーザーが信頼できるデバイスからサインインするときに MFA をバイパスできます。

最初にユーザーに MFA を要求しない場合は、条件付きで要求できます。アダプティブ認証を使用すると、Amazon Cognito は悪意のある可能性があるアクティビティを検出し、ユーザーに MFA の設定を要求したり、サインインをブロックしたりすることができます。

ユーザープールへのネットワークトラフィックが悪意のある可能性がある場合は、モニタリングして AWS WAF ウェブ ACLs でアクションを実行できます。

**関連トピック**
+ [ユーザープールに MFA を追加します](user-pool-settings-mfa.md)
+ [脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)
+ [AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)

### カスタマーユーザーエクスペリエンス
<a name="cognito-user-pools-custom-user-experience"></a>

ユーザーのサインアップ、サインイン、またはプロファイル更新のほとんどの段階で、Amazon Cognito がリクエストを処理する方法をカスタマイズできます。Lambda トリガーを使用すると、ID トークンを変更したり、カスタム条件に基づいてサインアップリクエストを拒否したりできます。自分のカスタム認証フローを作成できます。

カスタム CSS とロゴをアップロードして、マネージドログインの外観と操作感をユーザーが使い慣れたものにすることができます。

**関連トピック**
+ [Lambda トリガーを使用したユーザープールワークフローのカスタマイズ](cognito-user-pools-working-with-lambda-triggers.md)
+ [カスタム認証チャレンジの Lambda トリガー](user-pool-lambda-challenge.md)
+ [マネージドログインページにブランディングを適用する](managed-login-branding.md)

### モニタリングと分析
<a name="cognito-user-pools-monitoring-and-analytics"></a>

Amazon Cognito ユーザープールは、マネージドログインへのリクエストなどの API リクエストを AWS CloudTrailに記録します。パフォーマンスメトリクスを Amazon CloudWatch Logs で確認し、Lambda トリガーを使用してカスタムログを CloudWatch にプッシュできます。また、E メールメッセージと SMS メッセージの配信状況をモニタリングし、Service Quotas コンソールで API リクエストの量をモニタリングできます。

プラス[機能プラン](cognito-sign-in-feature-plans.md)では、自動学習テクノロジーでユーザーの認証試行をモニタリングして漏えいの兆候がないか確認し、リスクを即座に修復できます。また、これらの高度なセキュリティ機能では、ユーザーアクティビティをユーザープールに記録します。必要に応じて Amazon S3、CloudWatch Logs、または Amazon Data Firehose にも記録します。

API リクエストのデバイスおよびセッションデータを Amazon Pinpoint キャンペーンに記録することもできます。Amazon Pinpoint では、ユーザーアクティビティの分析に基づいて、アプリからプッシュ通知を送信できます。

**関連トピック**
+ [Amazon Cognito ログイン AWS CloudTrail](logging-using-cloudtrail.md)
+ [CloudWatch と Service Quotas でのクォータと使用状況の追跡](tracking-quotas-and-usage-in-cloud-watch-and-service-quotas.md)
+ [Amazon Cognito ユーザープールからのログのエクスポート](exporting-quotas-and-usage.md)
+ [ユーザープール分析に Amazon Pinpoint を使用する](cognito-user-pools-pinpoint-integration.md)

### Amazon Cognito アイデンティティプール統合
<a name="cognito-user-pools-identity-pools-integration"></a>

Amazon Cognito のもう半分はアイデンティティプールです。アイデンティティプールは、ユーザーからの Amazon DynamoDB や Amazon S3 など、 AWS のサービス に対して API リクエストを認可およびモニタリングするための認証情報を提供します。ユーザープール内のユーザーをどのように分類したかに基づいてデータを保護する ID ベースのアクセスポリシーを構築できます。アイデンティティプールは、ユーザープールの認証とは無関係に、さまざまな ID プロバイダーからのトークンや SAML 2.0 アサーションを受け入れることもできます。

**関連トピック**
+ [サインイン後の ID プール AWS のサービス を使用した へのアクセス](amazon-cognito-integrating-user-pools-with-identity-pools.md)
+ [Amazon Cognito アイデンティティプール](cognito-identity.md)

# ユーザープールの機能プラン
<a name="cognito-sign-in-feature-plans"></a>

コストを理解することは、Amazon Cognito ユーザープール認証の実装準備における重要なステップです。Amazon Cognito には、ユーザープール向けの機能プランがあります。各プランには、一連の機能とアクティブなユーザーあたりの月額コストが設定されています。機能プランの階層が上がるほど、それより下の機能プランより多くの機能を利用できます。

ユーザープールには、オンとオフを切り替えることができるさまざまな機能があります。例えば、多要素認証 (MFA) をオンにし、サードパーティ ID プロバイダー (IdP) によるサインインをオフにすることができます。一部の変更を行うには、機能プランを切り替える必要があります。ユーザープールの次の特性によって、 が毎月 AWS 請求する使用コストが決まります。
+ 選択した機能
+ アプリケーションがユーザープール API に対して行う 1 秒あたりのリクエスト数
+ 1 か月に認証、更新、またはクエリアクティビティを行ったユーザーの数。[月間アクティブユーザー](quotas.md#monthly-active-users) (MAU) 数とも呼ばれます。
+ サードパーティの SAML 2.0 または OpenID Connect (OIDC) IdP からの月間アクティブユーザー数
+ Machine to Machine 認証のためにクライアント認証情報の付与を行うアプリケーションクライアントとユーザープールの数

ユーザープールの料金に関する最新情報については、「[Amazon Cognito の料金](https://aws.amazon.com/cognito/pricing)」を参照してください。

機能プランの選択は、1 つのユーザープールに適用されます。同じ AWS アカウント 内の異なるユーザープールごとに、異なるプランを選択できます。ユーザープール内のアプリケーションクライアントに個別の機能プランを適用することはできません。新しいユーザープールにデフォルトで選択されるプランは、エッセンシャルです。

アプリケーションの要件に合わせて、いつでも機能プランを切り替えることができます。プランの切り替えに伴う変更によっては、アクティブな機能をオフにする必要があります。詳細については、「[機能をオフにして機能プランを変更する](feature-plans-deactivate.md)」を参照してください。ユーザープールの機能プラン

**ライト**  
ライトは、月間アクティブユーザー数が少ないユーザープール向けの低コストの機能プランです。ユーザーディレクトリの認証機能が基本的なものである場合は、このプランで十分です。このプランには、サインイン機能と、クラシックのホストされた UI (マネージドログインの前身で、よりスリムでカスタマイズ性が低い) が含まれています。ライトプランには、アクセストークンのカスタマイズやパスキー認証など、多くの新しい機能は含まれていません。

**エッセンシャル**  
エッセンシャルには、最新のユーザープール認証機能がすべて含まれています。このプランは、アプリケーションに新しいオプションを追加します。ログインページがマネージドログインであるか、カスタム構築であるかは問いません。エッセンシャルには、[[選択ベースのサインイン]](authentication-flows-selection-sdk.md#authentication-flows-selection-choice) や [[E メール MFA]](user-pool-settings-mfa-sms-email-message.md) などの高度な認証機能があります。

**Plus**  
プラスには、エッセンシャルプランのすべての機能に加えて、ユーザーを保護するための高度なセキュリティ機能が含まれています。ユーザーのサインイン、サインアップ、パスワード管理のリクエストをモニタリングして、漏えいの兆候がないか確認します。例えば、ユーザープールでは、ユーザーが予期しない場所からサインインしていないか、公衆への情報漏洩につながるパスワードを使用していないかを検出できます。  
プラスプランのユーザープールは、ユーザーアクティビティの詳細とリスク評価のログを生成します。これらのログを外部サービスにエクスポートするときに、独自の使用状況とセキュリティの分析を適用できます。

**注記**  
以前は、一部のユーザープール機能が「*高度なセキュリティ機能*」料金体系に含まれていました。この体系に含まれていた機能は、現在、エッセンシャルプランまたはプラスプランに含まれています。

**Topics**
+ [機能プランを選択する](#cognito-sign-in-feature-plans-choose)
+ [プラン別の機能](#cognito-sign-in-feature-plans-list)
+ [エッセンシャルプランの機能](feature-plans-features-essentials.md)
+ [プラスプランの機能](feature-plans-features-plus.md)
+ [機能をオフにして機能プランを変更する](feature-plans-deactivate.md)

## 機能プランを選択する
<a name="cognito-sign-in-feature-plans-choose"></a>

------
#### [ AWS マネジメントコンソール ]

機能プランを選択するには

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択、または[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[設定]** メニューを選択し、**[機能プラン]** タブを確認します。

1. ライト、エッセンシャル、プラスの各プランで使用できる機能を確認します。

1. プランを変更するには、**[エッセンシャルに切り替える]** または **[プラスに切り替える]** を選択します。**ライト**プランに切り替えるには、**[その他のプラン]**、**[ライトと比較]** の順に選択します。

1. 次の画面で、選択内容を確認し、**[確認]** を選択します。

------
#### [ CLI/API/SDK ]

[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) オペレーションと [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) オペレーションでは、`UserPoolTier` パラメータで機能プランを設定します。`UserPoolTier` の値を指定しない場合、ユーザープールのデフォルトは `Essentials` です。`AdvancedSecurityMode` を `AUDIT` または `ENFORCED` に設定する場合、ユーザープール階層は `PLUS` にする必要があり、指定しない場合はデフォルトで `PLUS` になります。

構文については、[CreateUserPool の「例」](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#API_CreateUserPool_Examples)を参照してください。さまざまなプログラミング言語の SDK のこの関数へのリンクについては、「[CreateUserPool の」も参照](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#API_CreateUserPool_SeeAlso)してください。 AWS SDKs 

```
"UserPoolTier": "PLUS"
```

では AWS CLI、このオプションは `--user-pool-tier`引数です。

```
--user-pool-tier PLUS
```

詳細については、 AWS CLI コマンドリファレンスの [create-user-pool](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool.html) と [update-user-pool](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html) を参照してください。

------

## プラン別の機能
<a name="cognito-sign-in-feature-plans-list"></a>


**ユーザープールの機能とプラン**  

| 機能 | 説明 | 機能プラン | 
| --- | --- | --- | 
| 安全でないパスワードからの保護 | プレーンテキストのパスワードに漏えいの兆候がないかランタイムに確認する | Plus | 
| 悪意のあるログイン試行からの保護 | セッションプロパティに侵害の兆候がないかランタイムに確認する | Plus | 
| ユーザーアクティビティの記録と分析 | ユーザー認証セッションのプロパティとリスクスコアのログを生成する | Plus | 
| ユーザーアクティビティログのエクスポート | ユーザーセッションとリスクログを外部にプッシュする AWS のサービス | Plus | 
| ビジュアルエディタによるマネージドログインページのカスタマイズ | Amazon Cognito コンソールのビジュアルエディタを使用して、マネージドログインページにブランディングとスタイルを適用する | エッセンシャル \$1 プラス | 
| メールワンタイムコード付きの MFA | ユーザー名の認証後に、追加の E メールメッセージサインイン要素の提供をローカルユーザーにリクエストまたは要求する | エッセンシャル \$1 プラス | 
| 実行時にアクセストークンのスコープとクレームをカスタマイズ | Lambda トリガーを使用してユーザープールのアクセストークンの認証機能を拡張する | エッセンシャル \$1 プラス | 
| ワンタイムコードによるパスワードなしのサインイン | 最初の認証要素として E メールまたは SMS でワンタイムパスワードを受け取ることをユーザーに許可する | エッセンシャル \$1 プラス | 
| ハードウェアまたはソフトウェアの FIDO2 Authenticator を使用したパスキーサインイン | FIDO2 Authenticator に保存されている暗号化キーを最初の認証要素として使用することをユーザーに許可する | エッセンシャル \$1 プラス | 
| サインアップとサインイン | 認証オペレーションを実行し、新規ユーザーがアプリケーションのアカウントに登録できるようにする | ライト \$1 エッセンシャル \$1 プラス | 
| ユーザーグループ | ユーザーの論理グループを作成し、アイデンティティプールのオペレーションにデフォルトの IAM ロールを割り当てる | ライト \$1 エッセンシャル \$1 プラス | 
| ソーシャルプロバイダー、SAML プロバイダー、OIDC プロバイダーによるサインイン | 直接サインインするか、希望するプロバイダーを使用してサインインするかのオプションをユーザーに提供する | ライト \$1 エッセンシャル \$1 プラス | 
| OAuth 2.0/OIDC 認可サーバー | OIDC 発行者として機能する | ライト \$1 エッセンシャル \$1 プラス | 
| ログインページ | ホストされた認証用ウェブページのコレクション。マネージドログインは、エッセンシャル階層とプラス階層で使用できます。クラシックのホストされた UI は、すべての機能階層で使用できます。 | ライト \$1 エッセンシャル \$1 プラス | 
| パスワード、カスタム、更新トークン、SRP 認証 | アプリケーションでユーザー名とパスワードの入力をユーザーに求める | ライト \$1 エッセンシャル \$1 プラス | 
| クライアント認証情報を使用した Machine to Machine (M2M) | 人間以外のエンティティを認証するためのアクセストークンを発行する | ライト \$1 エッセンシャル \$1 プラス | 
| リソースサーバーによる API 認証 | 外部システムへのアクセスを許可するカスタムスコープを使用してアクセストークンを発行する | ライト \$1 エッセンシャル \$1 プラス | 
| ユーザーのインポート | CSV ファイルからのインポートジョブを設定し、ユーザーのサインイン時にジャストインタイム移行を実行する | ライト \$1 エッセンシャル \$1 プラス | 
| Authenticator アプリケーションと SMS ワンタイムコードを使用した MFA | ユーザー名の認証後に追加の SMS メッセージまたは Authenticator アプリケーションのサインイン要素の提供をローカルユーザーにリクエストまたは要求する | ライト \$1 エッセンシャル \$1 プラス | 
| ID トークンのスコープとクレームのランタイムカスタマイズ | Lambda トリガーを使用してユーザープールのアイデンティティ (ID) トークンの認証機能を拡張する | ライト \$1 エッセンシャル \$1 プラス | 
| Lambda トリガーを使用したカスタムランタイムアクション | 外部アクションを実行し、認証に影響を与える Lambda 関数を使用して、サインインプロセスをランタイムにカスタマイズする | ライト \$1 エッセンシャル \$1 プラス | 
| CSS によるマネージドログインページのカスタマイズ | CSS テンプレートをダウンロードし、マネージドログインページでいくつかのスタイルを変更する | ライト \$1 エッセンシャル \$1 プラス | 

# エッセンシャルプランの機能
<a name="feature-plans-features-essentials"></a>

エッセンシャル機能プランには、Amazon Cognito ユーザープールの最良かつ最新の機能のほとんどが含まれています。ライトプランからエッセンシャルプランに切り替えると、マネージドログインページの新機能、E メールメッセージのワンタイムパスワードを使用した多要素認証、拡張パスワードポリシー、カスタムアクセストークンを利用できます。ユーザープールの新機能を常に利用するには、ユーザープールのエッセンシャルプランを選択してください。

以下のセクションでは、エッセンシャルプランを使用してアプリケーションに追加できる機能を簡単に紹介します。詳細については、以降のページを参照してください。

**その他のリソース**
+ アクセストークンのカスタマイズ: [トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)
+ E メール MFA: [SMS メッセージ MFA と E メールメッセージ MFA](user-pool-settings-mfa-sms-email-message.md)
+ パスワード履歴: [パスワード、アカウント復旧、パスワードポリシー](managing-users-passwords.md)
+ 拡張 UI: [マネージドログインページにブランディングを適用する](managed-login-branding.md)

**Topics**
+ [アクセストークンのカスタマイズ](#features-access-token-customization)
+ [E メール MFA](#features-email-mfa)
+ [パスワードの再利用防止](#features-password-reuse)
+ [マネージドログインのホストされたサインインおよび認可サーバー](#features-enhanced-ui)
+ [選択ベースの認証](#features-user-auth)

## アクセストークンのカスタマイズ
<a name="features-access-token-customization"></a>

ユーザープール[アクセストークン](https://datatracker.ietf.org/doc/html/rfc6749#section-1.4)は、[API へのアクセス](cognito-user-pools-define-resource-servers.md)、[userInfo エンドポイント](userinfo-endpoint.md)からのユーザー属性の取得、または外部システムの[グループメンバーシップ](cognito-user-pools-user-groups.md)の確立に必要なアクセス許可をアプリケーションに付与します。高度なシナリオでは、実行時にアプリケーションが決定する追加の仮パラメータを、ユーザープールディレクトリのデフォルトのアクセストークンデータに追加することが考えられます。例えば、[Amazon Verified Permissions](amazon-cognito-authorization-with-avp.md) を使用してユーザーの API アクセス許可を検証し、それに応じてアクセストークンのスコープを調整する場合です。

エッセンシャルプランは、[トークン生成前トリガー](user-pool-lambda-pre-token-generation.md)の既存の機能に機能を追加します。下位の階層プランでは、追加のクレーム、ロール、グループメンバーシップを使用して ID トークンをカスタマイズできます。エッセンシャルでは、アクセストークンのクレーム、ロール、グループメンバーシップ、スコープをカスタマイズする、新しいバージョンのトリガー入力イベントを追加します。アクセストークンのカスタマイズは、イベントバージョン 3 で Machine to Machine (M2M) の[クライアント認証情報の付与](federation-endpoints-oauth-grants.md)に利用できます。

**アクセストークンをカスタマイズするには**

1. エッセンシャル機能プランまたはプラス機能プランを選択します。

1. トリガーのための Lambda 関数を作成します。サンプル関数を使用するには、[Node.js に設定](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html)します。

1. Lambda 関数に[サンプルコード](user-pool-lambda-pre-token-generation.md#aws-lambda-triggers-pre-token-generation-example-version-2-overview)を入力するか、独自のコードを作成します。関数は、Amazon Cognito からのリクエストオブジェクトを処理し、含める変更を返す必要があります。

1. 新しい機能を[バージョン 2 または 3](user-pool-lambda-pre-token-generation.md#user-pool-lambda-pre-token-generation-event-versions) のトークン生成前トリガーとして割り当てます。バージョン 2 のイベントは、ユーザー ID のアクセストークンをカスタマイズします。バージョン 3 は、ユーザー ID とマシン ID のアクセストークンをカスタマイズします。

**詳細情報**
+ [アクセストークンのカスタマイズ](user-pool-lambda-pre-token-generation.md#user-pool-lambda-pre-token-generation-accesstoken)
+ [Amazon Cognito ユーザープールでアクセストークンをカスタマイズする方法](https://aws.amazon.com/blogs/security/how-to-customize-access-tokens-in-amazon-cognito-user-pools/)

## E メール MFA
<a name="features-email-mfa"></a>

Amazon Cognito ユーザープールは、多要素認証 (MFA) の 2 番目の要素として E メールを使用するように設定できます。E メール MFA を使用すると、Amazon Cognito は、認証プロセスを完了するために入力する必要がある検証コードを含む E メールをユーザーに送信できます。これにより、ユーザーログインフローに重要なセキュリティレイヤーが追加されます。E メールベースの MFA を有効にするには、デフォルトの E メール設定ではなく、[Amazon SES E メール送信設定](user-pool-email.md#user-pool-email-developer)を使用するようにユーザープールを設定する必要があります。

ユーザーが E メールメッセージによる MFA を選択すると、Amazon Cognito は、サインインの試行の都度、ユーザーの登録済み E メールアドレスに 1 回限りの検証コードを送信します。その後、認証フローを完了してアクセスするには、このコードをユーザープールに返す必要があります。これにより、ユーザーのユーザー名とパスワードが漏えいした場合でも、アプリケーションリソースにアクセスする前に、E メールで送信されたコードという追加の要素を提供する必要があるように設定されます。

詳細については、「[SMS メッセージ MFA と E メールメッセージ MFA](user-pool-settings-mfa-sms-email-message.md)」を参照してください。以下は、E メール MFA でのユーザープールとユーザーを設定する方法の概要です。

**Amazon Cognito コンソールで E メール MFA を設定するには**

1. エッセンシャル機能プランまたはプラス機能プランを選択します。

1. ユーザープールの **[サインイン]** メニューで、**[多要素認証]** を編集します。

1. 設定する **[MFA 強制適用]** のレベルを選択します。**[MFA を要求する] **にすると、API のユーザーは MFA を使用して設定、確認、サインインのためのチャレンジを自動的に受け取ります。MFA を必要とするユーザープールでは、マネージドログインが MFA 要素を選択して設定するようユーザーに求めます。**[オプションの MFA]** にすると、アプリケーションは、MFA の設定と、E メール MFA のユーザー希望を設定するオプションをユーザーに提供する必要があります。

1. **[MFA の方法]** で、**[E メールメッセージ]** をオプションの 1 つとして選択します。

**詳細情報**
+ [SMS メッセージ MFA と E メールメッセージ MFA](user-pool-settings-mfa-sms-email-message.md)

## パスワードの再利用防止
<a name="features-password-reuse"></a>

デフォルトでは、Amazon Cognito ユーザープールのパスワードポリシーは、パスワードの長さと文字タイプの要件、および仮パスワードの有効期限を設定します。エッセンシャルプランでは、パスワード履歴を強制する機能が追加されます。ユーザーがパスワードのリセットを試みると、ユーザープールは、ユーザーが以前のパスワードに設定できなくなるようにできます。パスワードポリシーの設定の詳細については、「[ユーザープールのパスワードの追加要件](managing-users-passwords.md#user-pool-settings-policies)」を参照してください。以下は、パスワード履歴ポリシーを使用してユーザープールを設定する方法の概要です。

**Amazon Cognito コンソールでパスワード履歴を設定するには**

1. エッセンシャル機能プランまたはプラス機能プランを選択します。

1. ユーザープールの **[認証方法]** メニューで、**[パスワードポリシー]** を見つけて **[編集]** を選択します。

1. 使用可能な他のオプションを設定し、**[以前のパスワードの使用の防止]** の値を設定します。

**詳細情報**
+ [パスワード、アカウント復旧、パスワードポリシー](managing-users-passwords.md)

## マネージドログインのホストされたサインインおよび認可サーバー
<a name="features-enhanced-ui"></a>

Amazon Cognito ユーザープールには、OpenID Connect (OIDC) IdP、サードパーティ IdP のサービスプロバイダーまたは依拠しているパーティ、サインアップとサインインのための公開ユーザーインタラクティブページといった機能をサポートするオプションのウェブページがあります。これらのページは、まとめて*マネージドログイン*と呼ばれます。ユーザープールのドメインを選択すると、Amazon Cognito は、これらのページを自動的にアクティブ化します。ライトプランでは、ホストされた UI が表示されます。エッセンシャルプランでは、この高度なバージョンのサインアップページとサインインページが表示されます。

マネージドログインページには、ブランディングとスタイルをカスタマイズするための、より多くの機能とオプションを備えたクリーンな最新のインターフェイスがあります。エッセンシャルプランは、マネージドログインへのアクセスを可能にする最下位のプランです。

**Amazon Cognito コンソールでマネージドログインを設定するには**

1. **[設定]** メニューで、エッセンシャル機能プランまたはプラス機能プランを選択します。

1. **[ドメイン]** メニューで、ユーザープールに[ドメインを割り当て](cognito-user-pools-assign-domain.md)、**[マネージドログイン]** の **[ブランディングバージョン]** を選択します。

1. **[マネージドログイン]**メニューの **[スタイル]** タブで、**[スタイルを作成]** を選択して、スタイルをアプリケーションクライアントに割り当てるか、新しいアプリケーションクライアントを作成します。

**詳細情報**
+ [ユーザープールのマネージドログイン](cognito-user-pools-managed-login.md)

## 選択ベースの認証
<a name="features-user-auth"></a>

エッセンシャル階層は、拡張 UI および SDK ベースの API オペレーションに、認証オペレーション用の新しい*認証フロー*を導入します。このフローは*選択ベースの認証*です。選択ベースの認証とは、ユーザーの認証の開始方法として、アプリケーション側でサインイン方法を宣言するのではなく、可能なサインイン方法をクエリして選択することから始める方法です。選択ベースの認証をサポートし、ユーザー名パスワード、パスワードなし、パスキーによる認証を有効にするようにユーザープールを設定できます。API の場合、これは `USER_AUTH` フローです。

**Amazon Cognito コンソールで選択ベースの認証を設定するには**

1. エッセンシャル機能プランまたはプラス機能プランを選択します。

1. ユーザープールの **[サインイン]** メニューで、**[選択ベースのサインインのオプション]** を編集します。選択ベースの認証で有効にする認証方法を選択して設定します。

1. ユーザープールの **[認証方法]** メニューで、サインインオペレーションの設定を編集します。

**詳細情報**
+ [Amazon Cognito ユーザープールによる認証](authentication.md)

# プラスプランの機能
<a name="feature-plans-features-plus"></a>

プラス機能プランには、Amazon Cognito ユーザープールの高度なセキュリティ機能が含まれています。これらの機能は、実行時にユーザーコンテキストをログに記録して分析し、デバイス、場所、リクエストデータ、パスワードにセキュリティ上の問題が潜んでいないか確認します。次に、ユーザーアカウントをブロックまたはセキュリティ保護を追加する自動応答により、潜在的なリスクを軽減します。また、セキュリティログを Amazon S3、Amazon Data Firehose、または Amazon CloudWatch Logs にエクスポートして、さらに分析することもできます。

エッセンシャルプランからプラス プランに切り替えると、エッセンシャルのすべての機能に加えて、上位の機能を利用できます。例えば、脅威保護のセキュリティオプションセット (*高度なセキュリティ機能*とも呼ばれます) を利用できます。認証フロントエンドの脅威に自動的に適応するようにユーザープールを設定するには、ユーザープールのプラスプランを選択してください。

以下のセクションでは、プラスプランでアプリケーションに追加できる機能を簡単に紹介します。詳細については、以降のページを参照してください。

**その他のリソース**
+ アダプティブ認証: [アダプティブ認証の使用](cognito-user-pool-settings-adaptive-authentication.md)
+ 漏えいした認証情報: [漏えいした認証情報の検出の使用](cognito-user-pool-settings-compromised-credentials.md)
+ ログのエクスポート: [Amazon Cognito ユーザープールからのログのエクスポート](exporting-quotas-and-usage.md)

**Topics**
+ [脅威保護: アダプティブ認証](#features-adaptive-authentication)
+ [脅威保護: 漏えいした認証情報の検出](#features-compromised-credentials)
+ [脅威保護: ユーザーアクティビティのログ記録](#features-user-logs)

## 脅威保護: アダプティブ認証
<a name="features-adaptive-authentication"></a>

プラスプランには、*アダプティブ認証*機能が含まれています。この機能を有効にすると、ユーザープールはすべてのユーザー認証セッションのリスク評価を行います。結果として得られるリスク評価から、サインインしたユーザーのリスクレベルがしきい値の設定を超えている場合、認証をブロックしたり、MFA をプッシュしたりできます。アダプティブ認証を使用すると、ユーザープールとアプリケーションは、ユーザーのアカウントが攻撃を受けている可能性があるときに、自動的にブロックしたり、MFA を設定したりします。また、ユーザープールからリスク評価に関するフィードバックを提供して、将来の評価を調整することもできます。

**Amazon Cognito コンソールでアダプティブ認証を設定するには**

1. プラス機能プランを選択します。

1. ユーザープールの **[脅威保護]** メニューで、**[脅威保護]** の下にある **[標準認証とカスタム認証]** を編集します。

1. 標準認証またはカスタム認証の **[強制モード]** を **[フル機能]** に設定します。

1. **[アダプティブ認証]** で、さまざまなリスクレベルに対する自動リスク対応を設定します。

**詳細情報**
+ [アダプティブ認証の使用](cognito-user-pool-settings-adaptive-authentication.md)
+ [アプリケーションにおける脅威保護のためのデータ収集](user-pool-settings-viewing-threat-protection-app.md)

## 脅威保護: 漏えいした認証情報の検出
<a name="features-compromised-credentials"></a>

プラスプランには、*[漏えいした認証情報の検出]* 機能が含まれています。この機能は、安全でないパスワードの使用や、それに伴って生じる意図しないアプリケーションアクセスの脅威から保護します。ユーザー名とパスワードによるサインインをユーザーに許可すると、他の場所で使用したパスワードが再利用される可能性があります。また、そのパスワードは漏洩しているか、一般的に推測されている可能性があります。漏えいした認証情報の検出では、ユーザーが送信したパスワードがユーザープールによって読み取られ、パスワードデータベースと比較されます。これにより、パスワードが漏えいしている可能性が高いと判断された場合は、サインインをブロックし、アプリケーションでユーザーのパスワードリセットを開始するようにユーザープールを設定できます。

漏えいした認証情報の検出は、新しいユーザーがサインアップしたとき、既存のユーザーがサインインしたとき、およびユーザーがパスワードをリセットしようとしたときに、安全でないパスワードに反応する可能性があります。この機能を使用すると、ユーザープールは、ユーザーがパスワードを入力する場所を問わず、安全でないパスワードを使用したサインインを防止または警告できます。

**Amazon Cognito コンソールで漏えいした認証情報の検出を設定するには**

1. プラス機能プランを選択します。

1. ユーザープールの **[脅威保護]** メニューで、**[脅威保護]** の下にある **[標準認証とカスタム認証]** を編集します。

1. 標準認証またはカスタム認証の **[強制モード]** を **[フル機能]** に設定します。

1. **[漏えいした認証情報]** で、チェックする認証オペレーションのタイプと、ユーザープールからの必要な自動レスポンスを設定します。

**詳細情報**
+ [漏えいした認証情報の検出の使用](cognito-user-pool-settings-compromised-credentials.md)

## 脅威保護: ユーザーアクティビティのログ記録
<a name="features-user-logs"></a>

プラスプランには、ユーザー認証試行のセキュリティ分析と詳細を示すログ記録機能が追加されています。アプリケーションに接続したデバイスに関するリスク評価、ユーザー IP アドレス、ユーザーエージェント、その他の情報を確認できます。これらの情報に基づいて、組み込みの脅威保護機能を使用して対処することも、独自のシステムでログを分析して適切な措置を講じることもできます。脅威保護から Amazon S3、CloudWatch Logs、または Amazon DynamoDB にログをエクスポートできます。

**Amazon Cognito コンソールでユーザーアクティビティのログ記録を設定するには**

1. プラス機能プランを選択します。

1. ユーザープールの **[脅威保護]** メニューで、**[脅威保護]** の下にある **[標準認証とカスタム認証]** を編集します。

1. 標準認証またはカスタム認証の **[強制モード]** を **[監査のみ]** に設定します。これはログに関する最小限の設定です。**[フル機能]** モードに切り替えて、その他の脅威保護機能を設定することもできます。

1. サードパーティー分析 AWS のサービス のためにログを別の にエクスポートするには、ユーザープールの**ログストリーミング**メニューに移動し、エクスポート先を設定します。

**詳細情報**
+ [ユーザー認証イベントのエクスポート](cognito-user-pool-settings-adaptive-authentication.md#user-pool-settings-adaptive-authentication-event-user-history-exporting)
+ [Amazon Cognito ユーザープールからのログのエクスポート](exporting-quotas-and-usage.md)

# 機能をオフにして機能プランを変更する
<a name="feature-plans-deactivate"></a>

機能プランは、ユーザープールに設定オプションを追加します。これらの機能は、関連する機能プランがアクティブな場合にのみ設定して使用できます。例えば、アクセストークンのカスタマイズは、プラスプランとエッセンシャルプランでは設定できますが、ライトプランでは設定できません。これらの機能を非アクティブ化するには、アクティブな各コンポーネントを非アクティブ化する必要があります。Amazon Cognito コンソールの **[設定]** メニューの **[切り替え]** オプションは、機能プランを変更する前に非アクティブ化する必要がある機能を通知します。この章では、非アクティブ化によってユーザープール設定に加えられる変更と、これらの機能を個別にオフにする方法について説明します。

**アクセストークンのカスタマイズ**  
アクセストークンのカスタマイズを含まないプランに切り替えるには、ユーザープールから [[トークン生成前 Lambda トリガー]](user-pool-lambda-pre-token-generation.md#user-pool-lambda-pre-token-generation-accesstoken) を削除する必要があります。アクセストークンをカスタマイズすることなく新しいトークン生成前トリガーを追加するには、トリガーに新しい関数を割り当て、`V1_0` イベント用に設定します。これらのバージョン 1 トリガーイベントは、ID トークンの変更のみを処理できます。  
アクセストークンのカスタマイズを手動で非アクティブ化するには、トークン生成前トリガーを削除し、新しいバージョン 1 のトリガーを追加します。

**脅威保護**  
脅威保護のないプランに切り替えるには、ユーザープールの **[脅威保護]** メニューからすべての機能を非アクティブ化します。

**ログのエクスポート**  
ログのエクスポートがないプランに切り替えるには、ユーザープールの **[ログストリーミング]** メニューで、この機能を非アクティブ化します。これにより、ユーザープールは、ローカルまたはエクスポートされたユーザーアクティビティログを生成しなくなります。`UserActivity` の `EventSource` 値がある設定を削除する [SetLogDeliveryConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetLogDeliveryConfiguration.html) API リクエストを送信することもできます。

**E メール MFA**  
E メール MFA のないプランに切り替えるには、ユーザープールの **[サインイン]** メニューに移動します。**[多要素認証]** を編集し、使用可能な **[MFA メソッド]** の 1 つとしての **[E メールメッセージ]** を選択解除します。

# Amazon Cognito ユーザープールに対するセキュリティのベストプラクティス
<a name="user-pool-security-best-practices"></a>

このページでは、一般的な脅威から保護する場合に実装できるセキュリティのベストプラクティスについて説明します。選択する設定は、各アプリケーションのユースケースによって異なります。管理オペレーションには、少なくとも最小特権を適用し、アプリケーションとユーザーのシークレットを保護する対策を講じることをお勧めします。もう 1 つの高度で効果的なステップは、 AWS WAF ウェブ ACLs を設定してユーザープールに適用することです。

## ネットワークレベルでユーザープールを保護する
<a name="user-pool-security-best-practices-network"></a>

AWS WAF ウェブ ACLs は、Amazon Cognito で構築する認証メカニズムのパフォーマンスとコストを保護できます。ウェブ ACL を使用すると、API およびマネージドログインのリクエストの前にガードレールを実装できます。ウェブ ACL は、ネットワーク層とアプリケーション層のフィルターを作成し、独自に作成したルールに基づいてトラフィックをドロップしたり、CAPTCHA を要求したりできます。リクエストは、ウェブ ACL ルールの条件を満たすまで Amazon Cognito リソースに渡されません。詳細については、「[AWS WAF ウェブ ACL](user-pool-waf.md)」を参照してください。

## SMS メッセージの不正使用から保護する
<a name="user-pool-security-best-practices-sms"></a>

ユーザープールでパブリックサインアップを許可すると、Amazon Cognito が SMS テキストメッセージで送信するコードを使用して、アカウント検証を設定できます。SMS メッセージは、不要なアクティビティに関連付けられ、 AWS 請求額が増加する可能性があります。不正を伴うような SMS メッセージの送信に対して耐障害性のあるインフラストラクチャを設定してください。詳細については、 AWS ブログの以下の投稿を参照してください。
+ [Amazon Cognito ユーザープールを使用したユーザーサインアップ詐欺や SMS ポンピングのリスクを軽減する](https://aws.amazon.com/blogs/security/reduce-risks-of-user-sign-up-fraud-and-sms-pumping-with-amazon-cognito-user-pools/)
+ [SMS Pumping に対する防御: AWS 人為的に拡張されたトラフィックとの戦いに役立つ新機能](https://aws.amazon.com/blogs/messaging-and-targeting/defending-against-sms-pumping-new-aws-features-to-help-combat-artificially-inflated-traffic/)

## パブリック認証を理解する
<a name="user-pool-security-best-practices-public-operations"></a>

Amazon Cognito ユーザープールには、カスタマーアイデンティティおよびアクセス管理 (CIAM) 機能があり、一般のユーザーがユーザーアカウントにサインアップしてアプリケーションにアクセスできるユースケースをサポートしています。ユーザープールでセルフサービスのサインアップを許可すると、パブリックインターネットからのユーザーアカウントへのリクエストが受け付けられます。セルフサービスリクエストは、[SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) や [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) などの API オペレーションからと、マネージドログインを使用したユーザーインタラクションから送信されます。パブリックリクエストに伴う不正使用を軽減するか、パブリック認証オペレーションを完全に無効化するようにユーザープールを設定できます。

以下の設定は、ユーザープールとアプリケーションクライアントでパブリック認証リクエストと内部認証リクエストを管理する方法の例をいくつか示しています。


**ユーザープールへのパブリックアクセスに影響するユーザープール設定の例**  

| 設定 | 利用可能なオプション | 設定場所 | パブリック認証への影響 | コンソール設定 | API オペレーションとパラメータ | 
| --- | --- | --- | --- | --- | --- | 
| [セルフサービスのサインアップ](user-pool-settings-admin-create-user-policy.md) | アカウントへのサインアップや、管理者としてのユーザーアカウントの作成をユーザーに許可する | ユーザープール | パブリックサインアップを防止する | [サインアップ] – [セルフサービスのサインアップ] |  [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-AdminCreateUserConfig)、[UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html#CognitoUserPools-UpdateUserPool-request-AdminCreateUserConfig) `AdminCreateUserConfig` – `AllowAdminCreateUserOnly`  | 
| [管理者による確認](signing-up-users-in-your-app.md#signing-up-users-in-your-app-and-confirming-them-as-admin) | 確認コードを新規ユーザーに送信するか、管理者に確認を求める | ユーザープール | 管理者のアクションなしでのサインアップの確認を防止する | [サインアップ] – [Cognito アシスト型の検証および確認] |  [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-AccountRecoverySetting)、[UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html#CognitoUserPools-UpdateUserPool-request-AccountRecoverySetting) `AccountRecoverySettings` – `admin_only`  | 
| [ユーザー開示](cognito-user-pool-managing-errors.md) | サインイン時およびパスワードリセット時に「ユーザーが見つかりません」というメッセージを送信するか、開示を防止する | アプリケーションクライアント | サインイン名、E メールアドレス、または電話番号の推測を防ぐ | [アプリケーションクライアント] – [ユーザー存在エラーを防ぐ] |  [CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html#CognitoUserPools-CreateUserPoolClient-request-PreventUserExistenceErrors)、[UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html#CognitoUserPools-UpdateUserPoolClient-request-PreventUserExistenceErrors) `PreventUserExistenceErrors`  | 
| [クライアントシークレット](user-pool-settings-client-apps.md#user-pool-settings-client-app-client-types) | サインアップ時、サインイン時、パスワードリセット時にシークレットハッシュを要求するかどうかを指定する | アプリケーションクライアント | 不正なソースからの認証リクエストを防ぐ | [アプリケーションクライアント] – [クライアントシークレット] |  [CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html#CognitoUserPools-CreateUserPoolClient-request-GenerateSecret) `GenerateSecret`  | 
| [ウェブ ACL](user-pool-waf.md) | 認証リクエストのネットワークファイアウォールを有効化するかどうかを指定する | ユーザープール | 管理者が定義したリクエスト特性と IP アドレスルールに基づいてアクセスを制限または禁止する | [AWS WAF] - [WAF 設定] |  [AssociateWebACL](https://docs.aws.amazon.com/waf/latest/APIReference/API_AssociateWebACL.html#WAF-AssociateWebACL-request-ResourceArn) `ResourceArn`  | 
| [外部 IdP](cognito-user-pools-identity-provider.md) | サードパーティ IdP、ユーザープールディレクトリ、または両方のユーザーによるサインインを許可する | アプリケーションクライアント | サインアップとサインインから[ローカルユーザー](cognito-terms.md#terms-localuser)または[フェデレーションユーザー](cognito-terms.md#terms-federateduser)を除外する | [アプリケーションクライアント] – [ID プロバイダー] |  [CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html#CognitoUserPools-CreateUserPoolClient-request-SupportedIdentityProviders)、[UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html#CognitoUserPools-UpdateUserPoolClient-request-SupportedIdentityProviders) `SupportedIdentityProviders`  | 
| [認可サーバー](cognito-user-pools-assign-domain.md) | 認証用のパブリックウェブページをホストするかどうかを指定する | ユーザープール | パブリックウェブページをオフにし、SDK ベースの認証のみを許可する | [ドメイン] |  [CreateUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolDomain.html) 任意のユーザープールドメインを作成すると、パブリックウェブページが使用可能になります。  | 
| [脅威保護](cognito-user-pool-settings-threat-protection.md) | 悪意のあるアクティビティや安全でないパスワードの兆候に関するモニタリングを有効または無効にする | ユーザープールまたはアプリケーションクライアント | ユーザーが侵害の兆候を示した場合、自動的にサインインをブロックするか、MFA を要求することができる | [脅威保護] – [保護設定] |  [SetRiskConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetRiskConfiguration.html) `SetRiskConfiguration` のパラメータは、脅威保護の設定を定義します。  | 

## 秘密クライアントをクライアントシークレットで保護する
<a name="user-pool-security-best-practices-client-secret"></a>

クライアントシークレットは、[アプリケーションクライアント](user-pool-settings-client-apps.md)に関連付けられたオプションの文字列です。クライアントシークレットを持つアプリケーションクライアントへのすべての認証リクエストには、ユーザー名、クライアント ID、およびクライアントシークレットから生成された[シークレットハッシュ](signing-up-users-in-your-app.md#cognito-user-pools-computing-secret-hash)を含める必要があります。クライアントシークレットを知らないユーザーは、最初からアプリケーションからシャットアウトされます。

ただし、クライアントシークレットには制限があります。クライアントシークレットをパブリッククライアントソフトウェアに埋め込むと、クライアントシークレットは閲覧可能になります。これにより、ユーザーの作成、パスワードリセットリクエストの送信、アプリケーションクライアントでの他のオペレーションの実行が可能になります。クライアントシークレットは、シークレットにアクセスできる唯一のエンティティがアプリケーションである場合にのみ実装する必要があります。通常、これが可能なのは、サーバー側の秘密クライアントアプリケーションです。これは、クライアントシークレットが必須である [M2M アプリケーション](cognito-user-pools-define-resource-servers.md)にも当てはまります。暗号化されたローカルストレージまたは にクライアントシークレットを保存します AWS Secrets Manager。クライアントシークレットをパブリックインターネットに公開することは絶対に避けてください。

## その他のシークレットを保護する
<a name="user-pool-security-best-practices-manage-secrets"></a>

Amazon Cognito ユーザープールの認証システムでは、個人データ、パスワード、 AWS 認証情報を扱う場合があります。アプリケーションでアクセスする可能性があるシークレットを扱うためのベストプラクティスを以下に示します。

**パスワード**  
ユーザーは、アプリケーションへのサインイン時にパスワードを入力する場合があります。Amazon Cognito には、更新トークンがあり、これをアプリケーションで使用することで、期限切れのユーザーセッションを新しいパスワードの入力を求めることなく継続できます。パスワードやパスワードハッシュは、ローカルストレージに保存しないようにします。パスワードを不透明なものとして扱い、ユーザープールにのみ渡すようにアプリケーションを設計します。  
ベストプラクティスとしては、[WebAuthn パスキー](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passkey)を使用してパスワードなしの認証を実装します。パスワードを実装する必要がある場合は、[セキュアリモートパスワード (SRP) 認証フロー](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-srp)と[多要素認証 (MFA)](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-mfa) を使用します。

**AWS 認証情報**  
管理認証とユーザープール管理オペレーションには、 AWS 認証情報を使用した認証が必要です。これらのオペレーションをアプリケーションに実装するには、[一時的な AWS 認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)への安全なアクセスを許可します。認証情報へのアクセスは、管理するサーバーコンポーネントで実行するアプリケーションにのみ許可します。 AWS 認証情報を持つアプリケーションを GitHub などのパブリックバージョン管理システムに配置しないでください。パブリッククライアント側のアプリケーションで AWS 認証情報をエンコードしないでください。

**PKCE コード検証子**  
[Proof Key for Code Exchange (PKCE)](using-pkce-in-authorization-code.md) は、ユーザープール認可サーバーでの OpenID Connect (OIDC) 認証コード付与に使用します。アプリケーションは、認証コードをリクエストするときに、コード検証シークレットをユーザープールと共有します。認証コードをトークンと交換するには、クライアントがコード検証子を認識していることを再確認する必要があります。これにより、傍受された認証コードでトークンが発行されないようにします。  
クライアントは、認可リクエストごとに新しいランダムなコード検証子を生成する必要があります。静的または予測可能なコード検証子を使用すると、攻撃者はハードコードされた検証子と認証コードを傍受するだけで済みます。コード検証子の値がユーザーに公開されないようにアプリケーションを設計します。

## ユーザープール管理の最小特権
<a name="user-pool-security-best-practices-least-privilege"></a>

IAM ポリシーは、Amazon Cognito ユーザープールの管理および管理認証オペレーションに対してプリンシパルが持つアクセスレベルを定義できます。例えば、次のようになります。
+ ウェブサーバーに対しては、管理 API オペレーションによる認証のためのアクセス許可を付与します。
+ でユーザープールを管理する AWS IAM アイデンティティセンター ユーザーに AWS アカウント、ユーザープールのメンテナンスとレポートのためのアクセス許可を付与します。

Amazon Cognito でのリソースの詳細度は、IAM ポリシーの目的においては、ユーザープールとアイデンティティプールの [2 つのリソースタイプ](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncognitoidentity.html#amazoncognitoidentity-resources-for-iam-policies)に制限されています。個々のアプリケーションクライアントを管理するためのアクセス許可は適用できないことに注意してください。付与したアクセス許可はすべてのアプリケーションクライアントに有効であることを念頭にユーザープールを設定してください。組織に複数のアプリケーションテナントがあり、セキュリティモデルでテナント間の管理責任を分離する必要がある場合は、[ユーザープールごとのテナントを 1 つとするマルチテナンシー](bp_user-pool-based-multi-tenancy.md)を実装します。

ユーザー認証オペレーション (`InitiateAuth` など) のためのアクセス許可を持つ IAM ポリシーを作成することはできますが、これらのアクセス許可は効果がありません。[パブリック API オペレーションとトークンで認可された API オペレーション](authentication-flows-public-server-side.md)は、IAM アクセス許可の対象ではありません。使用可能なユーザープール認証オペレーションのうち、アクセス許可を付与できるのは、*管理*サーバー側のオペレーション (`AdminInitiateAuth` など) に対してのみです。

最小特権 `Action` リストを使用して、ユーザープールの管理レベルを制限できます。次のポリシー例で対象としている管理者は、IdP、リソースサーバー、アプリケーションクライアント、ユーザープールドメインは管理できますが、ユーザーやユーザープールは管理できません。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "UserPoolClientAdministrator",
      "Action": [
        "cognito-idp:CreateIdentityProvider",
        "cognito-idp:CreateManagedLoginBranding",
        "cognito-idp:CreateResourceServer",
        "cognito-idp:CreateUserPoolDomain",
        "cognito-idp:DeleteIdentityProvider",
        "cognito-idp:DeleteResourceServer",
        "cognito-idp:DeleteUserPoolDomain",
        "cognito-idp:DescribeIdentityProvider",
        "cognito-idp:DescribeManagedLoginBranding",
        "cognito-idp:DescribeManagedLoginBrandingByClient",
        "cognito-idp:DescribeResourceServer",
        "cognito-idp:DescribeUserPool",
        "cognito-idp:DescribeUserPoolClient",
        "cognito-idp:DescribeUserPoolDomain",
        "cognito-idp:GetIdentityProviderByIdentifier",
        "cognito-idp:GetUICustomization",
        "cognito-idp:ListIdentityProviders",
        "cognito-idp:ListResourceServers",
        "cognito-idp:ListUserPoolClients",
        "cognito-idp:ListUserPools",
        "cognito-idp:SetUICustomization",
        "cognito-idp:UpdateIdentityProvider",
        "cognito-idp:UpdateManagedLoginBranding",
        "cognito-idp:UpdateResourceServer",
        "cognito-idp:UpdateUserPoolClient",
        "cognito-idp:UpdateUserPoolDomain"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_EXAMPLE"
    }
  ]
}
```

------

次のポリシー例では、サーバー側のアプリケーションに対して、ユーザーやグループの管理と認証を許可します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "UserAdminAuthN",
      "Action": [
        "cognito-idp:AdminAddUserToGroup",
        "cognito-idp:AdminConfirmSignUp",
        "cognito-idp:AdminCreateUser",
        "cognito-idp:AdminDeleteUser",
        "cognito-idp:AdminDeleteUserAttributes",
        "cognito-idp:AdminDisableProviderForUser",
        "cognito-idp:AdminDisableUser",
        "cognito-idp:AdminEnableUser",
        "cognito-idp:AdminForgetDevice",
        "cognito-idp:AdminGetDevice",
        "cognito-idp:AdminGetUser",
        "cognito-idp:AdminInitiateAuth",
        "cognito-idp:AdminLinkProviderForUser",
        "cognito-idp:AdminListDevices",
        "cognito-idp:AdminListGroupsForUser",
        "cognito-idp:AdminListUserAuthEvents",
        "cognito-idp:AdminRemoveUserFromGroup",
        "cognito-idp:AdminResetUserPassword",
        "cognito-idp:AdminRespondToAuthChallenge",
        "cognito-idp:AdminSetUserMFAPreference",
        "cognito-idp:AdminSetUserPassword",
        "cognito-idp:AdminSetUserSettings",
        "cognito-idp:AdminUpdateAuthEventFeedback",
        "cognito-idp:AdminUpdateDeviceStatus",
        "cognito-idp:AdminUpdateUserAttributes",
        "cognito-idp:AdminUserGlobalSignOut",
        "cognito-idp:AssociateSoftwareToken",
        "cognito-idp:ListGroups",
        "cognito-idp:ListUsers",
        "cognito-idp:ListUsersInGroup",
        "cognito-idp:RevokeToken",
        "cognito-idp:UpdateGroup",
        "cognito-idp:VerifySoftwareToken"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_EXAMPLE"
    }
  ]
}
```

------

## トークンの保護と検証
<a name="user-pool-security-best-practices-secure-tokens"></a>

トークンには、エンドユーザーに開示したくないグループメンバーシップやユーザー属性への内部参照が含まれている場合があります。ID トークンとアクセストークンは、ローカルストレージに保存しないでください。更新トークンは、ユーザープールのみがアクセスできるキーで暗号化され、ユーザーやアプリケーションからは不透明になります。ユーザーがサインアウトした場合や、セキュリティ上の理由でユーザーのセッションの保持が望ましくないと判断した場合は、[更新トークンの取り消し](token-revocation.md)を行います。

アクセストークンを使用すると、トークンが有効で期限切れでないことを独立して検証するシステムにのみ、アクセスを許可できます。検証リソースについては、「[JSON ウェブトークンの検証](amazon-cognito-user-pools-using-tokens-verifying-a-jwt.md)」を参照してください。

## 信頼する ID プロバイダーを決定する
<a name="user-pool-security-best-practices-trusted-idps"></a>

[SAML](cognito-user-pools-saml-idp.md) または [OIDC](cognito-user-pools-oidc-idp.md) ID プロバイダー (IdP) を使用してユーザープールを設定すると、IdP は新しいユーザーを作成して、ユーザー属性を設定し、アプリケーションリソースにアクセスできます。SAML プロバイダーと OIDC プロバイダーは通常、企業間取引 (B2B) やエンタープライズのシナリオで使用され、お客様やお客様の直接の顧客がプロバイダーのメンバーシップと設定を管理します。

[ソーシャルプロバイダー](cognito-user-pools-social-idp.md)は、インターネット上の誰にでもユーザーアカウントを提供するため、エンタープライズプロバイダーと比べてお客様による管理が行き届きません。アプリケーションクライアントでソーシャル IdP を有効にするのは、一般ユーザーによるアプリケーションへのサインインとリソースへのアクセスを許可する準備が整った場合のみとします。

## ユーザープロファイルへのアクセスに対するスコープの影響を理解する
<a name="user-pool-security-best-practices-scopes"></a>

ユーザープール認可サーバーへの認証リクエストで、アクセスコントロールのスコープをリクエストできます。これらのスコープは、外部リソースへのアクセスをユーザーに許可し、ユーザーが自身のユーザープロファイルを表示および変更するためのアクセスを許可できます。アプリケーションのオペレーションに必要な最小限のスコープをサポートするように、アプリケーションクライアントを設定します。

`aws.cognito.signin.user.admin` スコープは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) などのオペレーションで SDK 認証が発行するすべてのアクセストークンに存在します。スコープは、アプリケーションでのユーザープロファイルのセルフサービスオペレーション用に指定されています。このスコープは、認可サーバーに対してリクエストすることもできます。スコープは、[UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html) や [GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) など、トークンで認可されたオペレーションに必須です。これらのオペレーションの影響は、アプリケーションクライアントの読み取りおよび書き込みアクセス許可によって制限されます。

`openid`、`profile`、`email`、`phone` の各スコープは、ユーザープール認可サーバーの [userInfo エンドポイント](userinfo-endpoint.md)へのリクエストを承認します。各スコープは、エンドポイントが返すことができる属性を定義します。`openid` スコープは、他のスコープを追加せずにリクエストすると、使用可能なすべての属性を返します。他のスコープを追加してリクエストすると、レスポンスは追加のスコープが示す属性に絞り込まれます。`openid` スコープは ID トークンのリクエストも示します。このスコープを[認可エンドポイント](authorization-endpoint.md)へのリクエストから省略すると、Amazon Cognito はアクセストークンと、該当する場合は更新トークンのみを発行します。詳細については、「[アプリクライアントの用語](user-pool-settings-client-apps.md#cognito-user-pools-app-idp-settings-about)」の「**OpenID Connect のスコープ**」を参照してください。

## ユーザー属性の入力をサニタイズする
<a name="user-pool-security-best-practices-sanitize-inputs"></a>

配信方法やユーザー名となる可能性があるユーザー属性 (`email` など) には、[形式制限](user-pool-settings-attributes.md#cognito-user-pools-standard-attributes)があります。その他の属性には、文字列、ブール値、または数値データ型を含めることができます。文字列属性値は、さまざまな入力をサポートします。ユーザーディレクトリや、Amazon Cognito からユーザーに配信するメッセージに不要なデータを書き込む試みを防ぐようにアプリケーションを設定します。ユーザーが送信した文字列属性値は、アプリケーションにおいてクライアント側で検証してから Amazon Cognito に送信します。

ユーザープールは、指定した[属性マッピング](cognito-user-pools-specifying-attribute-mapping.md)に基づいて、IdP からユーザープールに属性をマッピングします。安全で予測可能な IdP 属性のみをユーザープールの文字列属性にマッピングします。

# Amazon Cognito ユーザープールによる認証
<a name="authentication"></a>

Amazon Cognito には、ユーザーを認証する方法がいくつか用意されています。ユーザーは、パスワードと WebAuthn パスキーを使用してサインインできます。Amazon Cognito は、E メールまたは SMS メッセージでワンタイムパスワードを送信できます。独自のチャレンジとレスポンスのシーケンスを調整する Lambda 関数を実装できます。これらは*認証フロー*です。認証フローでは、ユーザーがシークレットを提供します。Amazon Cognito がシークレットを検証して JSON ウェブトークン (JWT) を発行し、これをアプリケーションが OIDC ライブラリで処理します。この章では、さまざまなアプリケーション環境でさまざまな認証フロー用にユーザープールとアプリケーションクライアントを設定する方法について説明します。マネージドログインのホストされたサインインページを使用するオプションと、 AWS SDK で独自のロジックとフロントエンドを構築するためのオプションについて説明します。

ドメインの有無にかかわらず、すべてのユーザープールはユーザープール API でユーザーを認証できます。ユーザープールにドメインを追加すると、[ユーザープール エンドポイント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-userpools-server-contract-reference.html)を使用できます。ユーザープール API は、API リクエストのさまざまな認可モデルとリクエストフローをサポートします。

ユーザーのアイデンティティを検証するために、Amazon Cognito では、E メールや SMS メッセージのワンタイムパスワードやパスキーなどのパスワードに加えて、チャレンジタイプを組み込んだ認証フローをサポートしています。

**Topics**
+ [認証フローを実装する](#authentication-implement)
+ [ユーザープールによる認証について知っておくべきこと](#authentication-flow-things-to-know)
+ [認証セッションの例](#amazon-cognito-user-pools-authentication-flow)
+ [マネージドログインの認証方法を設定する](authentication-flows-selection-managedlogin.md)
+ [AWS SDKsで認証方法を管理する](authentication-flows-selection-sdk.md)
+ [認証フロー](amazon-cognito-user-pools-authentication-flow-methods.md)
+ [API 認証と SDK 認証の認可モデル](authentication-flows-public-server-side.md)

## 認証フローを実装する
<a name="authentication-implement"></a>

[マネージドログイン](authentication-flows-selection-managedlogin.md)を実装するか、認証用の AWS SDK [を使用してカスタム構築されたアプリケーションフロントエンド](authentication-flows-selection-sdk.md)を実装するかにかかわらず、実装する認証のタイプに合わせてアプリケーションクライアントを設定する必要があります。以下の情報では、[アプリケーションクライアント](user-pool-settings-client-apps.md)とアプリケーションにおける認証フローの設定について説明します。

------
#### [ App client supported flows ]

アプリケーションクライアントでサポートされているフローは、Amazon Cognito コンソールまたは AWS SDK の API を使用して設定できます。これらのフローをサポートするようにアプリケーションクライアントを設定した後で、アプリケーションにデプロイできます。

次の手順では、Amazon Cognito コンソールを使用してアプリケーションクライアントで利用できる認証フローを設定します。

**認証フロー用にアプリケーションクライアントを設定するには (コンソール)**

1. にサインイン AWS し、[Amazon Cognito ユーザープールコンソール](https://console.aws.amazon.com/cognito/v2/idp)に移動します。ユーザープールを選択するか、新しいユーザープールを作成します。

1. ユーザープールの設定で、**[アプリケーションクライアント]** メニューを選択します。アプリケーションクライアントを選択するか、新しく作成します。

1. **[アプリケーションクライアントに関する情報]** で、**[編集]** を選択します。

1. **[アプリケーションクライアントのフロー]** で、サポートする認証フローを選択します。

**認証フロー用にアプリケーションクライアントを設定するには (API/SDK)**  
Amazon Cognito API を使用してアプリケーションクライアントで利用可能な認証フローを設定するには、[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html#CognitoUserPools-CreateUserPoolClient-request-ExplicitAuthFlows) リクエストまたは [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html#CognitoUserPools-UpdateUserPoolClient-request-ExplicitAuthFlows) リクエストで `ExplicitAuthFlows` の値を設定します。次の例では、セキュアリモートパスワード (SRP) と選択ベースの認証をクライアントにプロビジョニングします。

```
"ExplicitAuthFlows": [ 
   "ALLOW_USER_AUTH",
   "ALLOW_USER_SRP_AUTH
]
```

アプリケーションクライアントがサポートするフローを設定するときは、以下のオプションと API 値を指定できます。


**アプリケーションクライアントでのフローのサポート**  

| 認証フロー | 互換性 | コンソール | API  | 
| --- | --- | --- | --- | 
| [選択ベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-choice) | サーバー側、クライアント側 | サインイン時に認証タイプを選択する | ALLOW\$1USER\$1AUTH | 
| [永続的なパスワードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-password) | クライアント側 | ユーザー名とパスワードでサインインする | ALLOW\$1USER\$1PASSWORD\$1AUTH | 
| [永続的なパスワードと安全なペイロードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-srp) | サーバー側、クライアント側 | セキュアリモートパスワード (SRP) でサインインする | ALLOW\$1USER\$1SRP\$1AUTH | 
| [トークンの更新](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-refresh) | サーバー側、クライアント側 | 既存の認証済みセッションから新しいユーザートークンを取得する | ALLOW\$1REFRESH\$1TOKEN\$1AUTH | 
| [サーバー側の認証](authentication-flows-public-server-side.md#amazon-cognito-user-pools-server-side-authentication-flow) | サーバー側 | サーバー側の管理認証情報でサインインする | ALLOW\$1ADMIN\$1USER\$1PASSWORD\$1AUTH | 
| [カスタム認証](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-custom) | サーバー側およびクライアント側のカスタム構築アプリケーション。マネージドログインとの互換性なし。 | Lambda トリガーからのカスタム認証フローでサインインする | ALLOW\$1CUSTOM\$1AUTH | 

------
#### [ Implement flows in your application ]

マネージドログインでは、設定した認証オプションが、サインインページで自動的に利用可能になります。カスタム構築アプリケーションでは、初期フローの宣言から認証を開始します。
+ ユーザーのフローオプションのリストから選択するには、`USER_AUTH` フローで[選択ベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)を宣言します。このフローでは、[パスキー](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passkey)認証や[パスワードなし](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless)の認証など、クライアントベースの認証フローでは利用できない認証方法を利用できます。
+ 認証フローを事前に選択するには、アプリケーションクライアントで利用可能な他のフローで[クライアントベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-client)を宣言します。

ユーザーをサインインさせるときは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-AuthFlow) リクエストまたは [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-AuthFlow) リクエストの本文に `AuthFlow` パラメータを含める必要があります。

選択ベースの認証:

```
"AuthFlow": "USER_AUTH"
```

SRP によるクライアントベースの認証:

```
"AuthFlow": "USER_SRP_AUTH"
```

------

## ユーザープールによる認証について知っておくべきこと
<a name="authentication-flow-things-to-know"></a>

Amazon Cognito ユーザープールを使用した認証モデルの設計では、以下の情報を考慮してください。

**マネージドログインとホストされた UI の認証フロー**  
[マネージドログイン](cognito-user-pools-managed-login.md)には、クラシックのホストされた UI よりも多くの認証オプションがあります。例えば、ユーザーはマネージドログインでのみ、パスワードなしの認証とパスキー認証を実行できます。

** AWS SDK 認証でのみ使用できるカスタム認証フロー**  
マネージドログインまたはクラシックのホストされた UI で、*カスタム認証フロー*や [Lambda トリガーによるカスタム認証](user-pool-lambda-challenge.md)を行うことはできません。カスタム認証は [AWS SDK による認証](authentication-flows-selection-sdk.md)で利用できます。

**外部 ID プロバイダー (IdP) によるサインイン用のマネージドログイン**  
[AWS SDKs による認証](authentication-flows-selection-sdk.md)では[、サードパーティーの IdPs](cognito-user-pools-identity-federation.md) を介してユーザーにサインインすることはできません。マネージドログインまたはクラシックのホストされた UI を実装し、IdP にリダイレクトしてから、結果の認証オブジェクトをアプリケーション内の OIDC ライブラリで処理する必要があります。マネージドログインの詳細については、「[ユーザープールのマネージドログイン](cognito-user-pools-managed-login.md)」を参照してください。

**パスワードなしの認証が他のユーザー機能に与える影響**  
ユーザープールとアプリケーションクライアントで[ワンタイムパスワード](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless)または[パスキー](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passkey)を使用してパスワードなしのサインインをアクティブ化すると、ユーザーの作成と移行に影響します。パスワードなしのサインインがアクティブな場合:  

1. 管理者はパスワードなしでユーザーを作成できます。デフォルトの招待メッセージテンプレートが変わり、`{###}` パスワードプレースホルダーを含まないようになります。詳細については、「[管理者としてのユーザーアカウントの作成](how-to-create-user-accounts.md)」を参照してください。

1. SDK ベースの[SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) オペレーションの場合、ユーザーはサインアップ時にパスワードを入力する必要はありません。マネージドログインとホストされた UI では、パスワードなしの認証が許可されている場合でも、サインアップページでパスワードが必要です。詳細については、「[ユーザーアカウントのサインアップと確認](signing-up-users-in-your-app.md)」を参照してください。

1. CSV ファイルからインポートされたユーザーは、ユーザーの属性に、パスワードなしのサインインオプションに利用できる E メールアドレスまたは電話番号が含まれている場合、パスワードをリセットせずに、パスワードなしのオプションで即座にサインインできます。詳細については、「[CSV ファイルからユーザープールへのユーザーのインポート](cognito-user-pools-using-import-tool.md)」を参照してください。

1. パスワードなしの認証では、[ユーザー移行の Lambda トリガー](user-pool-lambda-migrate-user.md)は呼び出されません。

1. ワンタイムパスワード (OTP) の最初の要素でサインインするユーザーは、セッションに[多要素認証 (MFA) ](user-pool-settings-mfa.md)要素を追加できません。ユーザー検証付きのパスキーは、 で設定すると MFA 要件を満たすことができます`MULTI_FACTOR_WITH_USER_VERIFICATION`。

**パスキーに依拠しているパーティの URL をパブリックサフィックスリストに含めることはできない**  
所有しているドメイン名 (`www.example.com` など) を、パスキー設定で依拠しているパーティ (RP) の ID として使用できます。この設定は、所有しているドメインで実行するカスタム構築アプリケーションをサポートすることを目的としています。[パブリックサフィックスリスト](https://publicsuffix.org/) (PSL) には、保護された高レベルのドメインが含まれています。PSL のドメインに RP URL を設定しようとすると、Amazon Cognito はエラーを返します。

**Topics**
+ [認証フローセッションの持続期間](#authentication-flow-session-duration)
+ [サインイン試行の失敗時におけるロックアウト動作](#authentication-flow-lockout-behavior)

### 認証フローセッションの持続期間
<a name="authentication-flow-session-duration"></a>

ユーザープールの機能によっては、アプリケーションが Amazon Cognito からトークンを取得する前に、`InitiateAuth` と `RespondToAuthChallenge` へのいくつかのチャレンジに応答することが必要になる場合があります。Amazon Cognito は、各リクエストへの応答にセッション文字列を含めます。API リクエストを 1 つの認証フローにまとめるには、前のリクエストに対する応答のセッション文字列を、後続の各リクエストに含めます。デフォルトでは、セッション文字列が期限切れになる前に、ユーザーに各チャレンジを完了するまでに 3 分間が与えられます。この期間を調整するには、アプリケーションクライアントの**認証フローセッション持続期間**を変更します。次の手順では、アプリクライアントの構成で、この設定を変更する方法について説明します。

**注記**  
**[認証フローセッションの持続期間]** の設定は、Amazon Cognito ユーザープール API による認証に適用されます。マネージドログインの場合、多要素認証にはセッション時間が 3 分、パスワードリセットコードには 8 分が設定されます。

------
#### [ Amazon Cognito console ]

**アプリクライアントの認証フローセッション持続期間を設定するには (AWS マネジメントコンソール)**

1. ユーザープールの **[App integration]** (アプリの統合) タブで、**[App clients and analytics]** (アプリクライアントと分析) コンテナからアプリクライアントの名前を選択します。

1. **[アプリケーションクライアントに関する情報]** コンテナで **[編集]** を選択します。

1. **[認証フローセッションの持続期間]** の値を、SMS および E メールの MFA コードに必要な有効期間 (分単位) に変更します。これにより、ユーザーがアプリクライアントで認証チャレンジを完了するまでの時間も変更されます。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ User pools API ]

**アプリクライアントの認証フローセッション持続期間を設定するには (Amazon Cognito API)**

1. `DescribeUserPoolClient` リクエストから既存のユーザープール設定を使用して `UpdateUserPoolClient` リクエストを準備します。`UpdateUserPoolClient` リクエストには、既存のアプリクライアントのプロパティをすべて含める必要があります。

1. `AuthSessionValidity` の値を、SMS MFA コードに必要な有効持続期間 (分単位) に変更します。これにより、ユーザーがアプリクライアントで認証チャレンジを完了するまでの時間も変更されます。

------

アプリクライアントの詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。

### サインイン試行の失敗時におけるロックアウト動作
<a name="authentication-flow-lockout-behavior"></a>

ユーザーのパスワードによるサインイン試行が 5 回失敗すると、認証されていない API オペレーションと IAM で認可された API オペレーションのどちらでリクエストしたかにかかわらず、Amazon Cognito はユーザーを 1 秒間ロックアウトします。ロックアウトの期間は、試行が 1 回失敗するたびに 2 倍になり、最大で約 15 分になります。

ロックアウト期間中に試行すると `Password attempts exceeded` 例外が生成され、その後のロックアウト期間の長さには影響しません。サインイン試行の累積失敗回数が *n* (`Password attempts exceeded` 例外を含まない) に達すると、Amazon Cognito はユーザーを *2^(n-5)* 秒間ロックアウトします。ロックアウトを *n=0* 初期状態にリセットするには、ユーザーは、ロックアウト期間後にサインインに成功するか、連続 15 分間、サインイン試行を開始してはなりません。この動作は変更される可能性があります。この動作は、パスワードベースの認証も実行しない限り、カスタムチャレンジに適用されません。

## 認証セッションの例
<a name="amazon-cognito-user-pools-authentication-flow"></a>

次の図とステップバイステップガイドは、ユーザーがアプリケーションにサインインする一般的なシナリオを示しています。サンプルアプリケーションでは、いくつかのサインインオプションをユーザーに示します。ユーザーは認証情報を入力してオプションを 1 つ選択し、追加の認証要素を指定してサインインします。

![\[ユーザーに入力を求め、 AWS SDK でサインインするアプリケーションを示すフローチャート。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/authentication-api-userauth.png)


ユーザーがユーザー名とパスワードでサインインしたり、E メールメッセージでワンタイムコードをリクエストしたり、フィンガープリントオプションを選択したりできるサインインページを備えたアプリケーションを想像してください。

1. **サインインプロンプト**: アプリケーションは、*[ログイン]* ボタンがあるホーム画面を表示します。

1. **サインインのリクエスト**: ユーザーは *[ログイン]* を選択します。アプリケーションは、Cookie またはキャッシュからユーザー名を取得するか、ユーザー名の入力をユーザーに求めます。

1. **リクエストオプション**: アプリケーションは、`USER_AUTH` フローの `InitiateAuth` API リクエストでユーザーのサインインオプションをリクエストし、ユーザーが利用できるサインイン方法を求めます。

1. **サインインオプションの送信**: Amazon Cognito は、`PASSWORD`、`EMAIL_OTP`、`WEB_AUTHN` で応答します。応答には、次回の応答で再生するためのセッション識別子が含まれます。

1. **表示オプション**: アプリケーションは、ユーザーがユーザー名とパスワードの入力、ワンタイムコードの取得、フィンガープリントのスキャンを行うための UI 要素を表示します。

1. **オプションの選択/認証情報の入力**: ユーザーはユーザー名とパスワードを入力します。

1. **認証の開始**: アプリケーションは、ユーザー名パスワードによるサインインを確認してユーザー名とパスワードを提供する `RespondToAuthChallenge` API リクエストにより、ユーザーのサインイン情報を提供します。

1. **認証情報の検証**: Amazon Cognito はユーザーの認証情報を確認します。

1. **追加のチャレンジ**: ユーザーは、Authenticator アプリケーションで多要素認証を設定しています。Amazon Cognito は `SOFTWARE_TOKEN_MFA` チャレンジを返します。

1. **チャレンジプロンプト**: アプリケーションは、ユーザーの Authenticator アプリケーションから時間ベースのワンタイムパスワード (TOTP) をリクエストするフォームを表示します。

1. **チャレンジへの回答**: ユーザーは TOTP を送信します。

1. **チャレンジへの応答**: 別の `RespondToAuthChallenge` リクエストで、アプリケーションはユーザーの TOTP を提供します。

1. **チャレンジレスポンスの検証**: Amazon Cognito はユーザーのコードを確認し、ユーザープールが現在のユーザーに追加のチャレンジを発行しないように設定されていることを検証します。

1. **トークンの発行**: Amazon Cognito は ID、アクセス、JSON ウェブトークン (JWT) の更新を返します。ユーザーの初期認証がここで完了します。

1. **トークンの保存**: アプリケーションはユーザーのトークンをキャッシュして、ユーザーデータの参照、リソースへのアクセスの許可、有効期限切れトークンの更新ができるようにします。

1. **認可されたコンテンツのレンダリング**: アプリケーションは、ユーザーのアイデンティティとロールに基づいて、リソースへのユーザーのアクセス権を決定し、アプリケーションコンテンツを配信します。

1. **コンテンツへのアクセス**: ユーザーはサインインし、アプリケーションの使用を開始します。

1. **期限切れトークンによるコンテンツのリクエスト**: 後で、ユーザーは認可を必要とするリソースをリクエストします。ユーザーのキャッシュされたトークンの有効期限が切れています。

1. **更新トークン**: アプリケーションは、ユーザーの保存された更新トークンを使用して `InitiateAuth` リクエストを行います。

1. **トークンの発行**: Amazon Cognito は新しい ID とアクセス用の JWT を返します。ユーザーのセッションは、追加の認証情報の入力を求められることなく、安全に更新されます。

[AWS Lambda トリガー](cognito-user-pools-working-with-lambda-triggers.md)を使用して、ユーザーの認証方法をカスタマイズできます。トリガーは独自のチャレンジを認証フローの一部として発行し検証を行います。

また、安全なバックエンドサーバーでは、管理者の認証フローを使用することもできます。[ユーザー移行の認証フロー](cognito-user-pools-using-import-tool.md)を使用すると、ユーザーにパスワードのリセットを要求することなく、ユーザーを移行できます。

# マネージドログインの認証方法を設定する
<a name="authentication-flows-selection-managedlogin"></a>

[マネージドログインページ](cognito-user-pools-managed-login.md)は、ユーザープール認証のウェブフロントエンドであり、ユーザーがサインイン、サインアウト、またはパスワードをリセットするときに呼び出すことができます。このモデルの場合、アプリケーションは OIDC ライブラリをインポートして、ユーザープールのマネージドログインページにより、ブラウザベースの認証試行を処理します。ユーザーが使用できる認証形式は、ユーザープールとアプリケーションクライアントの設定によって異なります。アプリケーションクライアントに `ALLOW_USER_AUTH` フローを実装すると、Amazon Cognito は使用可能なオプションからサインイン方法を選択するようユーザーに求めます。`ALLOW_USER_PASSWORD_AUTH` を実装して SAML プロバイダーを割り当てると、ログインページでユーザー名とパスワードを入力するか、IdP を介して接続するかを選択するオプションがユーザーに表示されます。

Amazon Cognito ユーザープールコンソールでは、アプリケーションのマネージドログイン認証の設定を開始できます。新しいユーザープールの作成時に開発対象のプラットフォームを指定すると、コンソールに OIDC および OAuth ライブラリの実装例と、サインインおよびサインアウトフローを実装するためのスターターコードが表示されます。マネージドログインは、多くの OIDC に依拠しているパーティの実装を使用して構築できます。可能な場合は、[OIDC に依拠しているパーティの認定ライブラリ](https://openid.net/developers/certified-openid-connect-implementations/)を使用することをお勧めします。詳細については、「[ユーザープールの開始方法](getting-started-user-pools.md)」を参照してください。

通常、OIDC の証明書利用者ライブラリは、ユーザープールのエンドポイントを定期的にチェックして、トークン`.well-known/openid-configuration`エンドポイントや認可エンドポイントなどの発行者 URLs を決定します。ベストプラクティスとして、必要な場合は、この自動検出動作を実装します。発行者エンドポイントを手動で設定すると、エラーが発生する可能性があります。例えば、ユーザープールのドメインを変更するとします。`openid-configuration` へのパスは、ユーザープールのドメインにリンクされていないため、サービスエンドポイントを自動検出するアプリケーションは、ドメインの変更を自動的に検出します。

## マネージドログインのユーザープール設定
<a name="authentication-flows-selection-managedlogin-settings"></a>

アプリケーションの複数のプロバイダーによるサインインを許可したり、Amazon Cognito を独立したユーザーディレクトリとして使用したりする場合があります。また、ユーザー属性を収集したり、MFA をセットアップしてプロンプトを表示したり、E メールアドレスをユーザー名として要求したりする場合も考えられます。マネージドログインとホストされた UI のフィールドを直接編集することはできません。代わりに、ユーザープールの設定により、マネージドログインの認証フローの処理が自動的に設定されます。

ユーザープール設定の以下の項目により、Amazon Cognito がマネージドログインとホストされた UI でユーザーに提示する認証方法が決まります。

------
#### [ User pool options (Sign-in menu) ]

以下のオプションは、Amazon Cognito コンソールのユーザープールの **[サインイン]** メニューにあります。

**Cognito ユーザープールのサインインオプション**  
ユーザー名のオプションがあります。マネージドログインページとホストされた UI ページは、選択した形式のユーザー名のみを受け入れます。例えば、**E メール**を唯一のサインインオプションとしてユーザープールを設定すると、マネージドログインページは E メール形式のユーザー名のみを受け入れます。

**必須の属性**  
ユーザープールで属性を必須として設定すると、ユーザーはマネージドログインでのサインアップ時に、属性の値の入力を求められます。

**選択ベースのサインインのオプション**  
[選択ベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)での認証方法の設定があります。ここでは、[パスキー](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passkey)や[パスワードなし](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless)などの認証方法を有効または無効にできます。これらの方法は、[マネージドログインのドメイン](managed-login-branding.md)と**ライト**階層より上の[機能プラン](cognito-sign-in-feature-plans.md)を持つユーザープールでのみ使用できます。

**多要素認証**  
マネージドログインとホストされた UI は、[MFA](user-pool-settings-mfa.md) の登録および認証オペレーションを処理します。ユーザープールで MFA が必須である場合、サインインページでは自動的に追加の要素を設定するようユーザーに求めます。また、MFA 設定を持つユーザーに MFA コードを使用して認証を完了するよう求めます。ユーザープールで MFA がオフまたはオプションである場合、サインインページでは MFA の設定を求めません。

**ユーザーアカウントの復旧**  
ユーザープールのセルフサービスによる[アカウントの復旧]()の設定により、ユーザーがパスワードをリセットできるリンクをサインインページに表示するかどうかが決まります。

------
#### [ User pool options (Domain menu) ]

以下のオプションは、Amazon Cognito コンソールのユーザープールの **[ドメイン]** メニューにあります。

**ドメイン**  
ユーザープールのドメインを選択すると、認証のためにブラウザを起動したときにユーザーが開くリンクのパスが設定されます。

**ブランディングバージョン**  
ブランディングバージョンを選択すると、ユーザープールのドメインにマネージドログインとホストされた UI のどちらが表示されるかが決まります。

------
#### [ User pool options (Social and external providers menu) ]

次のオプションは、Amazon Cognito コンソールのユーザープールの **[ソーシャルプロバイダーと外部プロバイダー]** メニューにあります。

**プロバイダー**  
ユーザープールに追加した ID プロバイダー (IdP) は、ユーザープール内の各アプリケーションクライアントに対してアクティブまたは非アクティブのままにすることができます。

------
#### [ App client options ]

以下のオプションは、Amazon Cognito コンソールのユーザープールの **[アプリケーションクライアント]** メニューにあります。これらのオプションを確認するには、リストからアプリケーションクライアントを選択します。

**Quick Setup アップガイド**  
Quick Setup ガイドには、さまざまな開発者環境向けのコード例が記載されています。コード例には、マネージドログイン認証をアプリケーションと統合するために必要なライブラリが含まれています。

**アプリケーションクライアント情報**  
この設定を編集して、現在のアプリケーションクライアントに対応するアプリケーションに割り当てられた IdP を設定します。Amazon Cognito は、マネージドログインページにユーザーのための選択肢を表示します。これらの選択肢は、割り当てられた方法と IdP によって決まります。例えば、`MySAML` という名前の SAML 2.0 IdP とローカルユーザープールのログインを割り当てると、マネージドログインページには認証方法プロンプトと `MySAML` のボタンが表示されます。

**認証設定**  
この設定を編集して、アプリケーションの認証方法を設定します。Amazon Cognito は、マネージドログインページにユーザーのための選択肢を表示します。これらの選択肢は、IdP としてユーザープールを利用できるかどうかと、割り当てた方法によって決まります。例えば、選択ベースの `ALLOW_USER_AUTH` 認証を割り当てると、マネージドログインページには、E メールアドレスの入力やパスキーによるサインインなど、利用可能な選択肢が表示されます。マネージドログインページには、割り当てた IdP のボタンも表示されます。

**ログインページ**  
このタブで利用可能なオプションを使用して、マネージドログインまたはホストされた UI のユーザーインタラクティブページの視覚的な効果を設定します。詳細については、「[マネージドログインページにブランディングを適用する](managed-login-branding.md)」を参照してください。

------

# AWS SDKsで認証方法を管理する
<a name="authentication-flows-selection-sdk"></a>

Amazon Cognito ユーザープールのユーザーは、さまざまな初期サインインオプション (*要素*) を使用してサインインできます。一部の要素の場合、ユーザーは多要素認証 (MFA) を追加できます。これらの最初の要素として、ユーザー名とパスワード、ワンタイムパスワード、パスキー、カスタム認証などがあります。詳細については、「[認証フロー](amazon-cognito-user-pools-authentication-flow-methods.md)」を参照してください。アプリケーションに組み込み UI コンポーネントがあり、 AWS SDK モジュールをインポートする場合は、認証用のアプリケーションロジックを構築する必要があります。2 つの主要な方法のいずれかを選択し、その方法に基づいて、実装する認証メカニズムを選択する必要があります。

*クライアントベースの認証*を実装できます。この場合、アプリケーションまたはクライアントが認証タイプを事前に宣言します。別の選択肢は、*選択ベースの認証*です。この場合、アプリケーションがユーザー名を収集し、ユーザーが使用できる認証タイプをリクエストします。これらのモデルは、要件に応じて、同じアプリケーションにまとめて実装することも、複数のアプリケーションクライアントに分割して実装することもできます。方法ごとに機能が異なります。例えば、クライアントベースにはカスタム認証があり、選択ベースにはパスワードなしの認証があります。

ユーザープール API の AWS SDK 実装で認証を実行するカスタムビルドのアプリケーションでは、ユーザープール設定、アプリケーションクライアント設定、クライアント側の設定に合わせて API リクエストを構成する必要があります。`USER_AUTH` の `AuthFlow` で始まる `InitiateAuth` セッションは、選択ベースの認証を開始します。Amazon Cognito は、優先する認証方法または選択肢のリストのいずれかをチャレンジとして使用し、API に応答します。`CUSTOM_AUTH` の `AuthFlow` で始まるセッションは、Lambda トリガーによるカスタム認証に直接進みます。

一部の認証方法は 2 つのフロータイプのいずれかに固定されており、一部の方法は両方で使用できます。

**Topics**
+ [選択ベースの認証](#authentication-flows-selection-choice)
+ [クライアントベースの認証](#authentication-flows-selection-client)

## 選択ベースの認証
<a name="authentication-flows-selection-choice"></a>

アプリケーションは、選択ベースの認証として、以下の認証方法をリクエストできます。これらのオプションは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-AuthParameters) または [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-AuthParameters) の `PREFERRED_CHALLENGE` パラメータで宣言するか、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html#CognitoUserPools-RespondToAuthChallenge-request-ChallengeName) または [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html#CognitoUserPools-AdminRespondToAuthChallenge-request-ChallengeName) の `ChallengeName` パラメータで宣言します。

1. `EMAIL_OTP` および `SMS_OTP`

   [ワンタイムパスワードによるパスワードなしのサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless)

1. `WEB_AUTHN`

   [WebAuthn パスキーを使用したパスワードなしのサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passkey)

1. `PASSWORD`

   [永続的なパスワードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-password)

   [永続的なパスワードと安全なペイロードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-srp)

   [サインイン後の MFA](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-mfa)

これらのオプションを API コンテキストで確認するには、「[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html#CognitoUserPools-RespondToAuthChallenge-request-ChallengeName)」で「`ChallengeName`」を参照してください。

選択ベースのサインインは、最初のリクエストに応じてチャレンジを発行します。このチャレンジは、リクエストされたオプションが利用可能であることを確認するか、利用可能な選択肢のリストを提供します。アプリケーションは、これらの選択肢をユーザーに表示することで、ユーザーが希望するサインイン方法の認証情報を入力し、チャレンジレスポンスで認証を続行できるようにします。

認証フローには、以下の選択ベースのオプションがあります。このタイプのすべてのリクエストでは、まずアプリケーションがユーザー名を収集するか、キャッシュから取得する必要があります。

1. `USERNAME` の `AuthParameters` のみを使用するオプションをリクエストします。Amazon Cognito は `SELECT_CHALLENGE` チャレンジを返します。そこから、アプリケーションは、ユーザーに対してチャレンジを選択し、このレスポンスをユーザープールに返すよう求めることができます。

1. `PREFERRED_CHALLENGE` の `AuthParameters` と優先チャレンジのパラメータ (ある場合) を使用して優先チャレンジをリクエストします。例えば、`PASSWORD_SRP` の `PREFERRED_CHALLENGE` をリクエストする場合は、`SRP_A` も含める必要があります。ユーザー、ユーザープール、アプリケーションクライアントがすべて優先チャレンジ用に設定されている場合、Amazon Cognito は、そのチャレンジの次のステップ (`PASSWORD_SRP`フローの `PASSWORD_VERIFIER`、`EMAIL_OTP` フリーや `SMS_OTP` フローの [CodeDeliveryDetails](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CodeDeliveryDetailsType.html) など) を返します。優先チャレンジが利用できない場合、Amazon Cognito は `SELECT_CHALLENGE` と利用可能なチャレンジのリストを返します。

1. 最初にユーザーをサインインさせ、次に選択ベースの認証オプションをリクエストします。サインインしたユーザーのアクセストークンを含む [GetUserAuthFactors](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserAuthFactors.html) リクエストは、利用可能な選択ベースの認証要素と MFA 設定を返します。このオプションを使用すると、ユーザーは最初にユーザー名とパスワードでサインインし、次に別の認証形式をアクティブ化できます。このオペレーションを使用して、優先チャレンジでサインインしたユーザーの追加のオプションを確認することもできます。

選択ベースの認証用に[アプリケーションクライアントを設定](authentication.md#authentication-implement)するには、許可された認証フローに `ALLOW_USER_AUTH` を追加します。また、ユーザープール設定で許可する選択ベースの要素を選択する必要があります。以下のプロセスは、選択ベースの認証要素を選択する方法を示しています。

------
#### [ Amazon Cognito console ]

**ユーザープールで選択ベースの認証オプションを設定するには**

1. にサインイン AWS し、[Amazon Cognito ユーザープールコンソール](https://console.aws.amazon.com/cognito/v2/idp)に移動します。ユーザープールを選択するか、新しいユーザープールを作成します。

1. ユーザープール設定で、**[サインイン]** メニューを選択します。**[選択ベースのサインインのオプション]** を見つけ、**[編集]** を選択します。

1. **[パスワード]** オプションは常に利用可能です。これには、`PASSWORD` フローと `PASSWORD_SRP`フローが含まれます。ユーザーのオプションに追加する **[その他のオプション]** を選択します。追加できるのは、**パスキー** (`WEB_AUTHN`)、**メールメッセージのワンタイムパスワード** (`EMAIL_OTP`)、**SMS メッセージワンタイムパスワード** (`SMS_OTP`) です。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ API/SDK ]

次の [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) または [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) リクエスト本文の一部は、選択ベースの認証に使用できるすべてのオプションを設定します。

```
"Policies": {
    "SignInPolicy": {
        "AllowedFirstAuthFactors": [
            "PASSWORD",
            "WEB_AUTHN",
            "EMAIL_OTP",
            "SMS_OTP"
        ]
    }
},
```

------

## クライアントベースの認証
<a name="authentication-flows-selection-client"></a>

クライアントベースの認証は、以下の認証フローをサポートします。これらのオプションは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-AuthFlow) または [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-AuthFlow) の `AuthFlow` パラメータで宣言します。

1. `USER_PASSWORD_AUTH` および `ADMIN_USER_PASSWORD_AUTH`

   [永続的なパスワードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-password)

   [サインイン後の MFA](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-mfa)

   この認証フローは、選択ベースの認証の `PASSWORD` と同等です。

1. `USER_SRP_AUTH`

   [永続的なパスワードと安全なペイロードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-srp)

   [サインイン後の MFA](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-mfa)

   この認証フローは、選択ベースの認証の `PASSWORD_SRP` と同等です。

1. `REFRESH_TOKEN_AUTH`

   [更新トークン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-refresh)

   この認証フローは、クライアントベースの認証でのみ使用できます。

1. `CUSTOM_AUTH`

   [カスタム認証](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-custom)

   この認証フローは、クライアントベースの認証でのみ使用できます。

クライアントベースの認証の場合、Amazon Cognito は、ユーザーが認証フローを開始する前に認証方法を決定済みであると想定します。ユーザーが提供するサインイン要素を決定するロジックは、デフォルト設定またはカスタムプロンプトで決定し、ユーザープールへの最初のリクエストで宣言する必要があります。`InitiateAuth` リクエストは、リストされているオプションの 1 つ (`USER_SRP_AUTH` など) に直接対応するサインイン `AuthFlow` を宣言します。この宣言により、リクエストには、認証を開始するためのパラメータ (`USERNAME`、`SECRET_HASH`、`SRP_A` など) も含まれます。Amazon Cognito は、このリクエストに続けて、SRP の `PASSWORD_VERIFIER` や TOTP MFA によるパスワードサインインの `SOFTWARE_TOKEN_MFA` など、追加のチャレンジを発行する場合があります。

クライアントベースの認証用に[アプリケーションクライアントを設定](authentication.md#authentication-implement)するには、許可された認証フローに `ALLOW_USER_AUTH` 以外の認証フローを追加します。例えば、`ALLOW_USER_PASSWORD_AUTH`、`ALLOW_CUSTOM_AUTH`、`ALLOW_REFRESH_TOKEN_AUTH` を追加します。クライアントベースの認証フローを許可するために、追加のユーザープール設定を行う必要はありません。

# 認証フロー
<a name="amazon-cognito-user-pools-authentication-flow-methods"></a>

Amazon Cognito ユーザープールの認証プロセスは、ユーザーが最初の選択を行い、認証情報を送信し、追加のチャレンジに応答する*フロー*として最もよく説明できます。マネージドログイン認証をアプリケーションに実装すると、Amazon Cognito は、これらのプロンプトとチャレンジのフローを管理します。アプリケーションのバックエンドに AWS SDK を使用してフローを実装する場合は、リクエストのロジックを構築し、ユーザーに入力を求め、チャレンジに応答する必要があります。

アプリケーション管理者は、ユーザー特性、セキュリティ要件、認可モデルを利用して、ユーザーにサインインを許可する方法を決定します。以下の質問を自問してください。
+ [他の ID プロバイダー (IdP)](#amazon-cognito-user-pools-authentication-flow-methods-federated) の認証情報を使用してサインインすることをユーザーに許可するか?
+ [ユーザー名とパスワード](#amazon-cognito-user-pools-authentication-flow-methods-password)は本人確認として十分であるか?
+ ユーザー名パスワード認証のための認証リクエストが傍受される可能性はあるか? アプリケーションでパスワードを送信したり、[ハッシュとソルトを使用して認証をネゴシエート](#amazon-cognito-user-pools-authentication-flow-methods-srp)したりするか?
+ パスワードの入力をスキップし、[ワンタイムパスワードを受信](#amazon-cognito-user-pools-authentication-flow-methods-passwordless)してサインインすることをユーザーに許可するか?
+ [サムプリント、顔、またはハードウェアセキュリティキー](#amazon-cognito-user-pools-authentication-flow-methods-passkey)を使用したサインインをユーザーに許可するか?
+ どのような場合に[多要素認証 (MFA)](#amazon-cognito-user-pools-authentication-flow-methods-mfa) を必須にするか?
+ [認証情報を再度要求せずにユーザーセッションを保持](#amazon-cognito-user-pools-authentication-flow-methods-refresh)するか?
+ Amazon Cognito の組み込み機能を超えて[認可モデルを拡張](#amazon-cognito-user-pools-authentication-flow-methods-custom)するか?

これらの質問に対する回答が得られたら、関連する機能をアクティブ化し、アプリケーションが行う認証リクエストで機能を実装する方法を検討できます。

ユーザーのサインインフローを設定したら、[GetUserAuthFactors](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserAuthFactors.html) API オペレーションへのリクエストを使用して、MFA および[選択ベース](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)の認証要素の現在のステータスを確認できます。このオペレーションには、サインインしたユーザーのアクセストークンによる認可が必要です。このオペレーションからは、ユーザー認証要素と MFA 設定が返されます。

**Topics**
+ [サードパーティの IdP によるサインイン](#amazon-cognito-user-pools-authentication-flow-methods-federated)
+ [永続的なパスワードによるサインイン](#amazon-cognito-user-pools-authentication-flow-methods-password)
+ [永続的なパスワードと安全なペイロードによるサインイン](#amazon-cognito-user-pools-authentication-flow-methods-srp)
+ [ワンタイムパスワードによるパスワードなしのサインイン](#amazon-cognito-user-pools-authentication-flow-methods-passwordless)
+ [WebAuthn パスキーを使用したパスワードなしのサインイン](#amazon-cognito-user-pools-authentication-flow-methods-passkey)
+ [サインイン後の MFA](#amazon-cognito-user-pools-authentication-flow-methods-mfa)
+ [更新トークン](#amazon-cognito-user-pools-authentication-flow-methods-refresh)
+ [カスタム認証](#amazon-cognito-user-pools-authentication-flow-methods-custom)
+ [ユーザー移行の認証フロー](#amazon-cognito-user-pools-user-migration-authentication-flow)

## サードパーティの IdP によるサインイン
<a name="amazon-cognito-user-pools-authentication-flow-methods-federated"></a>

Amazon Cognito ユーザープールは、Apple でサインイン、Amazon でログイン、OpenID Connect (OIDC) サービスなど、IdP 間の認証セッションの中間ブローカーとして機能します。このプロセスは、*フェデレーティッドサインイン*または*フェデレーティッド認証*とも呼ばれます。フェデレーティッド認証では、アプリケーションクライアントに組み込める認証フローは使用しません。代わりに、設定したユーザープール IdP をアプリケーションクライアントに割り当てます。フェデレーティッドサインインは、ユーザーがマネージドログインで IdP を選択するか、アプリケーションが IdP サインインページにリダイレクトするセッションを呼び出したときに発生します。

フェデレーティッドサインインでは、プライマリ認証要素と MFA 認証要素をユーザーの IdP に委任します。Amazon Cognito は、[ローカルユーザーにリンク](cognito-user-pools-identity-federation-consolidate-users.md)しない限り、このセクションの他の高度なフローをフェデレーションユーザーに追加しません。リンクされていないフェデレーションユーザーにはユーザー名がありますが、マッピングされた属性データのストアであり、通常はブラウザベースのフローから切り離してサインインに使用することはありません。

**実装リソース**
+ [サードパーティーの ID プロバイダーを使用したユーザープールへのサインイン](cognito-user-pools-identity-federation.md)

## 永続的なパスワードによるサインイン
<a name="amazon-cognito-user-pools-authentication-flow-methods-password"></a>

Amazon Cognito ユーザープールでは、すべてのユーザーにユーザー名があります。ユーザー名は、電話番号、E メールアドレス、選択した識別子、または管理者が指定した識別子です。このタイプのユーザーは、ユーザー名とパスワードでサインインし、必要に応じて MFA を指定できます。ユーザープールは、パブリックまたは IAM で認可された API オペレーションと SDK メソッドを使用してユーザー名パスワードによるサインインを実行できます。アプリケーションは、認証のためにパスワードをユーザープールに直接送信できます。ユーザープールは、認証が成功した結果として、追加のチャレンジまたは JSON ウェブトークン (JWT) で応答します。

------
#### [ Activate password sign-in ]

ユーザー名とパスワードによる[クライアントベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-client)をアクティブ化するには、認証を許可するようにアプリケーションクライアントを設定します。Amazon Cognito コンソールで、ユーザープール設定の **[アプリケーション]** の下にある **[アプリケーションクライアント]** メニューに移動します。クライアント側のモバイルまたはネイティブアプリケーションでプレーンパスワードサインインを許可するには、アプリケーションクライアントを編集し、**[認証フロー]** で **[ユーザー名とパスワード (ALLOW\$1USER\$1PASSWORD\$1AUTH) を使用してサインインします]** を選択します。サーバー側のアプリケーションでプレーンパスワードサインインを許可するには、アプリケーションクライアントを編集し、**[サーバー側の管理者認証情報 (ALLOW\$1ADMIN\$1USER\$1PASSWORD\$1AUTH) を使用してサインインします]** を選択します。

ユーザー名とパスワードを使用して[選択ベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)を有効にするには、それを許可するようにアプリケーションクライアントを設定します。アプリケーションクライアントを編集し、**[選択ベースのサインイン: ALLOW\$1USER\$1AUTH]** を選択します。

![\[アプリケーションクライアントのプレーンパスワード認証フローの選択を示す Amazon Cognito コンソールのスクリーンショット。オプションとして、ALLOW_USER_PASSWORD_AUTH、ALLOW_ADMIN_USER_PASSWORD_AUTH、および ALLOW_USER_AUTH が選択されています。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/screenshot-choose-password-admin-password-and-user-auth.png)


選択ベースの認証フローでパスワード認証が使用可能であることを確認するには、**[サインイン]** メニューに移動し、**[選択ベースのサインインのオプション]** セクションを確認します。**[使用できる選択肢]** に **[パスワード]** が表示されている場合は、プレーンパスワード認証でサインインできます。**[パスワード]** オプションには、プレーンパスワード認証や SRP ユーザー名パスワード認証があります。

![\[ユーザープールの USER_AUTH 選択ベースのサインイン設定におけるパスワード認証の選択を示す Amazon Cognito コンソールのスクリーンショット。[パスワード] が有効になっているオプションとして表示されています。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/screenshot-password-flow-in-user-auth.png)


[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) リクエストまたは [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) リクエストで、希望するユーザー名パスワード認証オプションを使用して `ExplicitAuthFlows` を設定します。

```
"ExplicitAuthFlows": [ 
   "ALLOW_USER_PASSWORD_AUTH",
   "ALLOW_ADMIN_USER_PASSWORD_AUTH",
   "ALLOW_USER_AUTH"
]
```

[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) リクエストで、サポートする選択ベースの認証フローを使用して `Policies` を設定します。`AllowedFirstAuthFactors` の `PASSWORD` 値には、認証フローとしてプレーンパスワードと SRP の両方のオプションが含まれます。

```
"Policies": {
   "SignInPolicy": {
      "AllowedFirstAuthFactors": [
         "PASSWORD",
         "EMAIL_OTP",
         "WEB_AUTHN"
      ]
   }
}
```

------
#### [ Choice-based sign-in with a password ]

ユーザー名パスワード認証を使用してユーザーをアプリケーションにサインインさせるには、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) リクエストまたは [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) リクエストの本文を、以下のように設定します。現在のユーザーがユーザー名パスワード認証の適格性を満たしている場合、このサインインリクエストは成功するか、次のチャレンジに進みます。それ以外の場合は、使用可能な [主な要因] 認証チャレンジのリストで応答します。このパラメータセットは、サインインに必要な最小限のものです。その他のパラメータも使用可能です。

```
{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PREFERRED_CHALLENGE" : "PASSWORD",
      "PASSWORD" : "[User's password]"
   },
   "ClientId": "1example23456789"
}
```

`PREFERRED_CHALLENGE` 値を省略して、ユーザーの適格なサインイン要素のリストを含むレスポンスを受け取ることもできます。

```
{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser"
   },
   "ClientId": "1example23456789"
}
```

優先チャレンジを送信しなかったか、送信先のユーザーが優先チャレンジの適格性を満たしていない場合、Amazon Cognito はオプションのリストを `AvailableChallenges` で返します。`AvailableChallenges` に `PASSWORD` の `ChallengeName` が含まれている場合、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) または [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) チャレンジレスポンスによる認証を次の形式で続行できます。チャレンジレスポンスを、最初のサインインリクエストへの API レスポンスに関連付ける `Session` パラメータを渡す必要があります。このパラメータセットは、サインインに必要な最小限のものです。その他のパラメータも使用可能です。

```
{
   "ChallengeName": "PASSWORD",
   "ChallengeResponses": { 
      "USERNAME" : "testuser",
      "PASSWORD" : "[User's Password]"
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response"
}
```

Amazon Cognito は、成功した適格な優先チャレンジリクエストと `PASSWORD` チャレンジレスポンスに対して、トークンを使用するか、多要素認証 (MFA) などの追加の必須チャレンジを使用して応答します。

------
#### [ Client-based sign-in with a password ]

ユーザー名パスワード認証を使用してクライアント側のアプリケーションにユーザーをサインインさせるには、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) リクエストの本文を、以下のように設定します。このパラメータセットは、サインインに必要な最小限のものです。その他のパラメータも使用可能です。

```
{
   "AuthFlow": "USER_PASSWORD_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PASSWORD" : "[User's password]"
   },
   "ClientId": "1example23456789"
}
```

ユーザー名パスワード認証を使用してサーバー側のアプリケーションにユーザーをサインインさせるには、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) リクエストの本文を、以下のように設定します。アプリケーションは、 AWS 認証情報を使用してこのリクエストに署名する必要があります。このパラメータセットは、サインインに必要な最小限のものです。その他のパラメータも使用可能です。

```
{
   "AuthFlow": "ADMIN_USER_PASSWORD_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PASSWORD" : "[User's password]"
   },
   "ClientId": "1example23456789"
}
```

Amazon Cognito は、トークンを使用するか、多要素認証 (MFA) などの追加の必須チャレンジを使用して、成功したリクエストに応答します。

------

## 永続的なパスワードと安全なペイロードによるサインイン
<a name="amazon-cognito-user-pools-authentication-flow-methods-srp"></a>

ユーザープールのユーザー名パスワードによるサインイン方法の別の形式として、セキュアリモートパスワード (SRP) プロトコルがあります。このオプションは、パスワードを知っていることの証明 (パスワードハッシュとソルト) を送信し、ユーザープールで検証できるようにします。Amazon Cognito へのリクエストには、読み取り可能なシークレット情報が含まれないため、ユーザーが入力したパスワードを処理するのはアプリケーションのみです。SRP 認証には、数学的計算が含まれていて、SDK にインポートできる既存のコンポーネントで処理するのが最適です。SRP は通常、モバイルアプリなどのクライアント側のアプリケーションに実装されます。プロトコルの詳細については、「[スタンフォード SRP ホームページ](http://srp.stanford.edu/)」を参照してください。[ウィキペディア](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)にもリソースと例があります。認証フローの SRP 計算には、[さまざまなパブリックライブラリ](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#Implementations)を利用できます。

Amazon Cognito 認証の開始/チャレンジ/応答シーケンスでは、SRP を使用してユーザーとパスワードを検証します。SRP 認証をサポートするようにユーザープールとアプリケーションクライアントを設定し、サインインリクエストとチャレンジレスポンスのロジックをアプリケーションに実装する必要があります。SRP ライブラリは、ユーザーのパスワードを所有していることをユーザープールに示すための乱数と計算値を生成できます。アプリケーションは、Amazon Cognito ユーザープールの API オペレーションと SDK メソッドにおいて、これらの計算値を JSON 形式の `AuthParameters` フィールドと `ChallengeParameters` フィールドに入力して検証を行います。

------
#### [ Activate SRP sign-in ]

ユーザー名と SRP を使用した[クライアントベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-client)を有効にするには、認証を許可するようにアプリケーションクライアントを設定します。Amazon Cognito コンソールで、ユーザープール設定の **[アプリケーション]** の下にある **[アプリケーションクライアント]** メニューに移動します。クライアント側のモバイルアプリまたはネイティブアプリで SRP サインインを許可するには、アプリケーションクライアントを編集し、**[認証フロー]** で **[セキュアリモートパスワード (SRP) (ALLOW\$1USER\$1SRP\$1AUTH) を使用してサインインします]** を選択します。

ユーザー名と SRP を使用した[選択ベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)を有効にするには、アプリケーションクライアントを編集し、**[選択ベースのサインイン: ALLOW\$1USER\$1AUTH]** を選択します。

![\[Amazon Cognito コンソールで、アプリケーションクライアントに選択されているセキュアリモートパスワード認証フローを示すスクリーンショット。オプションとして ALLOW_USER_SRP_AUTH と ALLOW_USER_AUTH が選択されています。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/screenshot-choose-SRP-and-user-auth.png)


選択ベースの認証フローで SRP 認証が使用可能であることを確認するには、**[サインイン]** メニューに移動し、**[選択ベースのサインインのオプション]** セクションを確認します。**[使用できる選択肢]** に **[パスワード]** が表示されている場合は、SRP 認証でサインインできます。**[パスワード]** オプションには、プレーンテキスト認証や SRP ユーザー名パスワード認証があります。

![\[ユーザープールの USER_AUTH 選択ベースのサインイン設定におけるパスワード認証の選択を示す Amazon Cognito コンソールのスクリーンショット。[パスワード] は、有効なオプションとして表示されています。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/screenshot-password-flow-in-user-auth.png)


[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) リクエストまたは [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) リクエストで、希望するユーザー名パスワード認証オプションを使用して `ExplicitAuthFlows` を設定します。

```
"ExplicitAuthFlows": [ 
   "ALLOW_USER_SRP_AUTH",
   "ALLOW_USER_AUTH"
]
```

[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) リクエストで、サポートする選択ベースの認証フローを使用して `Policies` を設定します。`AllowedFirstAuthFactors` の `PASSWORD` 値には、認証フローとしてプレーンテキストパスワードと SRP の両方のオプションが含まれます。

```
"Policies": {
   "SignInPolicy": {
      "AllowedFirstAuthFactors": [
         "PASSWORD",
         "EMAIL_OTP",
         "WEB_AUTHN"
      ]
   }
}
```

------
#### [ Choice-based sign-in with SRP ]

SRP のユーザー名パスワード認証を使用してユーザーをアプリケーションにサインインさせるには、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) リクエストまたは [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) リクエストの本文を、以下のように設定します。現在のユーザーがユーザー名パスワード認証の適格性を満たしている場合、このサインインリクエストは成功するか、次のチャレンジに進みます。それ以外の場合は、使用可能な [主な要因] 認証チャレンジのリストで応答します。このパラメータセットは、サインインに必要な最小限のものです。その他のパラメータも使用可能です。

```
{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PREFERRED_CHALLENGE" : "PASSWORD_SRP",
      "SRP_A" : "[g^a % N]"
   },
   "ClientId": "1example23456789"
}
```

`PREFERRED_CHALLENGE` 値を省略して、ユーザーの適格なサインイン要素のリストを含むレスポンスを受け取ることもできます。

```
{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser"
   },
   "ClientId": "1example23456789"
}
```

優先チャレンジを送信しなかったか、送信先のユーザーが優先チャレンジの適格性を満たしていない場合、Amazon Cognito はオプションのリストを `AvailableChallenges` で返します。`AvailableChallenges` に `PASSWORD_SRP` の `ChallengeName` が含まれている場合、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) または [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) チャレンジレスポンスによる認証を次の形式で続行できます。チャレンジレスポンスを、最初のサインインリクエストへの API レスポンスに関連付ける `Session` パラメータを渡す必要があります。このパラメータセットは、サインインに必要な最小限のものです。その他のパラメータも使用可能です。

```
{
   "ChallengeName": "PASSWORD_SRP",
   "ChallengeResponses": { 
      "USERNAME" : "testuser",
      "SRP_A" : "[g^a % N]"
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response"
}
```

Amazon Cognito は、適格な優先チャレンジリクエストと `PASSWORD_SRP` チャレンジレスポンスに対して、`PASSWORD_VERIFIER` チャレンジで応答します。クライアントは SRP 計算を完了し、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) リクエストまたは [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) リクエストでチャレンジに応答する必要があります。

```
{
   "ChallengeName": "PASSWORD_VERIFIER",
   "ChallengeResponses": { 
      "PASSWORD_CLAIM_SIGNATURE" : "string",
      "PASSWORD_CLAIM_SECRET_BLOCK" : "string",
      "TIMESTAMP" : "string"
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}
```

`PASSWORD_VERIFIER` チャレンジレスポンスが成功すると、Amazon Cognito はトークンを発行するか、多要素認証 (MFA) などの別の必要なチャレンジを発行します。

------
#### [ Client-based sign-in with SRP ]

SRP 認証は、サーバー側よりもクライアント側での認証の方が一般的です。ただし、[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) では SRP 認証を使用できます。ユーザーをアプリケーションにサインインさせるには、`InitiateAuth` リクエストまたは `AdminInitiateAuth` リクエストの本文を、以下のように設定します。このパラメータセットは、サインインに必要な最小限のものです。その他のパラメータも使用可能です。

クライアントは、ジェネレータモジュロ N *g* をシークレットランダム整数の *a* 乗して `SRP_A` を生成します。

```
{
   "AuthFlow": "USER_SRP_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "SRP_A" : "[g^a % N]"
   },
   "ClientId": "1example23456789"
}
```

Amazon Cognito は `PASSWORD_VERIFIER` チャレンジで応答します。クライアントは SRP 計算を完了し、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) リクエストまたは [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) リクエストでチャレンジに応答する必要があります。

```
{
   "ChallengeName": "PASSWORD_VERIFIER",
   "ChallengeResponses": { 
      "PASSWORD_CLAIM_SIGNATURE" : "string",
      "PASSWORD_CLAIM_SECRET_BLOCK" : "string",
      "TIMESTAMP" : "string"
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}
```

`PASSWORD_VERIFIER` チャレンジレスポンスが成功すると、Amazon Cognito はトークンを発行するか、多要素認証 (MFA) などの別の必要なチャレンジを発行します。

------

## ワンタイムパスワードによるパスワードなしのサインイン
<a name="amazon-cognito-user-pools-authentication-flow-methods-passwordless"></a>

パスワードは紛失したり盗まれたりする場合があります。ユーザーが検証済みの E メールアドレス、電話番号、または Authenticator アプリケーションにのみアクセスできることを確認したい場合もあります。このような場合の解決策は、*パスワードなし*のサインインです。アプリケーションは、ユーザー名、E メールアドレス、または電話番号の入力をユーザーに求めることができます。これにより、Amazon Cognito はワンタイムパスワード (OTP) を生成し、ユーザーに確認を求めます。コードが正しければ、認証が完了します。

ワンタイムパスワード (OTP) 認証フローは、ユーザープールに必要な多要素認証 (MFA) と互換性がありません。ユーザー検証によるパスキー認証は、 `FactorConfiguration`を に設定すると MFA 要件を満たすことができます`MULTI_FACTOR_WITH_USER_VERIFICATION`。ユーザープールで MFA がオプションの場合、MFA をアクティブ化したユーザーは OTP の最初の要素でサインインできません。MFA オプションユーザープールに MFA 設定がないユーザーは、パスワードなしの各要素でサインインできます。詳細については、「[ユーザープールの MFA について知っておくべきこと](user-pool-settings-mfa.md#user-pool-settings-mfa-prerequisites)」を参照してください。

ユーザーがパスワードなしの認証の一環として、SMS や E メールメッセージで受信したコードを正しく入力すると、ユーザープールは、ユーザーを認証することに加えて、ユーザーの未検証の E メールアドレスや電話番号属性を検証済みとしてマークします。E メールアドレスや電話番号を[自動的に検証](signing-up-users-in-your-app.md)するようにユーザープールを設定しているかどうかに関係なく、ユーザーステータスも `UNCONFIRMED` から `CONFIRMED` に変更されます。

**パスワードなしのサインインの新しいオプション**  
ユーザープールでパスワードなしの認証を有効にすると、一部のユーザーフローの動作が変更されます。

1. ユーザーはパスワードなしでサインアップし、サインイン時にパスワードなしの要素を選択できます。管理者としてパスワードなしでユーザーを作成することもできます。

1. [CSV ファイルでインポート](cognito-user-pools-using-import-tool.md)したユーザーは、パスワードなしの要素を使用してすぐにサインインできます。サインイン前にパスワードを設定する必要はありません。

1. パスワードを持たないユーザーは、`PreviousPassword` パラメータなしで [ChangePassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ChangePassword.html) API リクエストを送信できます。

**OTP による自動サインイン**  
E メール OTP または SMS メッセージ OTP でサインアップしてユーザーアカウントを確認するユーザーは、確認メッセージと一致するパスワードなしの要素を使用して自動的にサインインできます。マネージドログイン UI では、ユーザーがアカウントを確認して、確認コード配信方法による OTP サインインの適格性を満たしている場合、ユーザーは確認コードの入力後に、初回サインインに自動的に進みます。 AWS SDK を使用してカスタム構築されたアプリケーションで、以下のパラメータを [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) オペレーションに渡します。
+ `Session` リクエストパラメータとしての [ConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html) API レスポンスの `Session` パラメータ。
+ `USER_AUTH` の [AuthFlow](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-AuthFlow)。

`EMAIL_OTP` または `SMS_OTP` の [PREFERRED\$1CHALLENGE](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-AuthParameters) を渡すことができますが、必須ではありません。`Session` パラメータは認証の証明となり、有効なセッションコードを渡すと、Amazon Cognito は `AuthParameters` を無視します。

サインインオペレーションは、認証の成功を示すレスポンス [AuthenticationResult](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AuthenticationResultType.html) を返します。以下の条件が満たされた場合、追加のチャレンジはありません。
+ `Session` コードは有効であり、期限切れになっていない。
+ ユーザーは OTP 認証方法の適格性を満たしている。

------
#### [ Activate passwordless sign-in ]

**コンソール**  
パスワードなしのサインインを有効にするには、1 つ以上のパスワードなしのタイプでプライマリサインインを許可するようにユーザープールを設定し、`USER_AUTH` フローを許可するようにアプリケーションクライアントを設定します。Amazon Cognito コンソールで、ユーザープール設定の **[認証]** の下にある **[サインイン]** メニューに移動します。**[選択ベースのサインインのオプション]** を編集し、**[メールメッセージのワンタイムパスワード]** または **[SMS メッセージワンタイムパスワード]** を選択します。両方のオプションを有効にすることができます。変更内容を保存します。

**[アプリケーションクライアント]** メニューに移動し、アプリケーションクライアントを選択するか、新しいアプリケーションクライアントを作成します。**[編集]** を選択し、**[サインイン時に認証タイプを選択: ALLOW\$1USER\$1AUTH]** を選択します。

**API/SDK**  
ユーザープール API で、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) リクエストで適切なパスワードなしのオプションを使用して `SignInPolicy` を設定します。

```
"SignInPolicy": { 
    "AllowedFirstAuthFactors": [ 
        "EMAIL_OTP",
        "SMS_OTP"
    ]
}
```

[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) リクエストまたは [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) リクエストの必要なオプションを使用して、アプリケーションクライアント `ExplicitAuthFlows` を設定します。

```
"ExplicitAuthFlows": [ 
   "ALLOW_USER_AUTH"
]
```

------
#### [ Sign in with passwordless ]

パスワードなしのサインインには、[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) で指定できる[クライアントベース](authentication-flows-selection-sdk.md#authentication-flows-selection-client)の `AuthFlow` はありません。OTP 認証は、`USER_AUTH` の[選択ベース](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)の `AuthFlow` でのみ使用可能であり、希望するサインインオプションをリクエストするか、ユーザーの [AvailableChallenges](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-response-AvailableChallenges) からパスワードなしのオプションを選択することができます。ユーザーをアプリケーションにサインインさせるには、`InitiateAuth` リクエストまたは `AdminInitiateAuth` リクエストの本文を、以下のように設定します。このパラメータセットは、サインインに必要な最小限のものです。その他のパラメータも使用可能です。

この例では、ユーザーがどの方法でサインインするかわかりません。`PREFERRED_CHALLENGE` パラメータを追加し、優先チャレンジをユーザーに利用可能にすると、Amazon Cognito はそのチャレンジで応答します。

```
{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser"
   },
   "ClientId": "1example23456789"
}
```

この例では、代わりに `"PREFERRED_CHALLENGE": "EMAIL_OTP"` または `"PREFERRED_CHALLENGE": "SMS_OTP"` を `AuthParameters` に追加できます。ユーザーがその優先方法の適格性を満たしている場合、ユーザープールはユーザーの E メールアドレスまたは電話番号に即座にコードを送信し、`"ChallengeName": "EMAIL_OTP"` または `"ChallengeName": "SMS_OTP"` を返します。

優先チャレンジを指定しない場合、Amazon Cognito は `AvailableChallenges` パラメータで応答します。

```
{
   "AvailableChallenges": [ 
      "EMAIL_OTP", 
      "SMS_OTP",
      "PASSWORD"
    ],
   "Session": "[Session ID]"
}
```

このユーザーは、E メールメッセージの OTP、SMS メッセージの OTP、ユーザー名パスワードによるパスワードなしのサインインの適格性を満たしています。アプリケーションは、ユーザーに選択を求めるか、内部ロジックに基づいて選択を行うことができます。次に、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) リクエストまたは [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) リクエストに進み、チャレンジを選択できます。ユーザーが E メールメッセージの OTP を使用してパスワードなしの認証を完了したいとします。

```
{
   "ChallengeName": "SELECT_CHALLENGE",
   "ChallengeResponses": { 
      "USERNAME" : "testuser",
      "ANSWER" : "EMAIL_OTP" 
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}
```

Amazon Cognito は `EMAIL_OTP` チャレンジで応答し、ユーザーの検証済み E メールアドレスにコードを送信します。アプリケーションは、このチャレンジに再度応答する必要があります。

`EMAIL_OTP` を `PREFERRED_CHALLENGE` としてリクエストした場合、これも次のチャレンジレスポンスとなります。

```
{
   "ChallengeName": "EMAIL_OTP",
   "ChallengeResponses": {
      "USERNAME" : "testuser", 
      "EMAIL_OTP_CODE" : "123456" 
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}
```

------

## WebAuthn パスキーを使用したパスワードなしのサインイン
<a name="amazon-cognito-user-pools-authentication-flow-methods-passkey"></a>

パスキーは安全で、ユーザーの負担は比較的少なくて済みます。パスキーサインインでは、ユーザーが認証に使用できる外部デバイスである *Authenticator* を利用します。通常のパスワードでは、ユーザーがフィッシング、パスワードの推測、認証情報の盗難などの脆弱性にさらされます。パスキーを使用すると、アプリケーションは、携帯電話やその他のデバイスで情報システムにアタッチまたは組み込まれている高度なセキュリティ対策を活用できます。一般的なパスキーサインインワークフローは、iOS キーチェーンや Google Chrome パスワードマネージャーなど、パスワードまたは*認証情報*マネージャーをデバイスで呼び出すことから始まります。デバイス上の認証情報マネージャーは、パスキーを選択して、既存の認証情報やデバイスロック解除メカニズムを使用してパスキーを許可するようユーザーに求めます。モダンな電話には、顔スキャナー、フィンガープリントスキャナー、ロック解除パターンなどのメカニズムが備わっており、いくつかは、強力な認証の要素である*知識情報*と*所持情報*を同時に満たします。バイオメトリクスを使用したパスキー認証の場合、パスキーは*生体情報*に該当します。

パスワードをサムプリント、顔、またはセキュリティキー認証に置き換えることもできます。これは*パスキー*認証または *WebAuthn* 認証と呼ばれます。アプリケーションのデベロッパーは、ユーザーが最初にパスワードでサインインした後に、生体認証デバイスの登録を許可するのが一般的です。Amazon Cognito ユーザープールを使用すると、アプリケーションは、このサインインオプションをユーザー向けに設定できます。ユーザープールが `FactorConfiguration`に設定されている場合、パスキー認証は多要素認証 (MFA) の要件を満たすことができます`MULTI_FACTOR_WITH_USER_VERIFICATION`。この設定では、ユーザー検証によるパスキー認証が多要素認証としてカウントされます。

ワンタイムパスワード (OTP) 認証フローは、ユーザープールに必要な多要素認証 (MFA) と互換性がありません。ユーザー検証によるパスキー認証は、 `FactorConfiguration`を に設定すると MFA 要件を満たすことができます`MULTI_FACTOR_WITH_USER_VERIFICATION`。ユーザープールで MFA がオプションの場合、MFA をアクティブ化したユーザーは OTP の最初の要素でサインインできません。MFA オプションユーザープールに MFA 設定がないユーザーは、パスワードなしの各要素でサインインできます。詳細については、「[ユーザープールの MFA について知っておくべきこと](user-pool-settings-mfa.md#user-pool-settings-mfa-prerequisites)」を参照してください。

### パスキーとは
<a name="amazon-cognito-user-pools-authentication-flow-methods-passkey-what-are"></a>

パスキーを使用すると、複雑なパスワードを覚えたり、OTP を入力したりする必要がなくなり、ユーザーエクスペリエンスが簡素化します。パスキーは、[ワールドワイドウェブコンソーシアム](https://www.w3.org/TR/webauthn-3/) (W3C) と FIDO (Fast Identity Online) アライアンスが策定した WebAuthn および CTAP2 標準に基づいています。ブラウザとプラットフォームは、これらの標準を実装し、ウェブアプリケーションまたはモバイルアプリケーションでパスキーの登録や認証プロセスを開始するための API と、ユーザーがパスキー *Authenticator* を選択して操作するための UI を提供します。

ユーザーがウェブサイトやアプリに Authenticator を登録すると、Authenticator はパブリック/プライベートキーペアを作成します。WebAuthn ブラウザおよびプラットフォームは、パブリックキーをウェブサイトやアプリケーションのバックエンドに送信します。Authenticator は、ユーザーとアプリケーションに関するプライベートキー、キー ID、メタデータを保持します。ユーザーが登録済み Authenticator を使用して登録済みアプリケーションで認証しようとすると、ランダムなチャレンジが生成されます。このチャレンジへの応答は、そのアプリケーションおよびユーザーの Authenticator のプライベートキーで生成されたチャレンジのデジタル署名および関連メタデータです。ブラウザまたはアプリケーションプラットフォームはデジタル署名を受け取り、アプリケーションのバックエンドに渡します。次に、アプリケーションは保存されたパブリックキーを使用して署名を検証します。

**注記**  
アプリケーションは、ユーザーから Authenticator に提供した認証シークレットや、プライベートキーに関する情報を受け取ることはありません。

現在市販されている Authenticator の例と機能を以下に示します。Authenticator は、これらのカテゴリのいずれかまたはすべてを満たしている場合があります。
+ 一部の Authenticator は、PIN、顔やフィンガープリントによる生体認証入力、パスコードなどの要素を使用して*ユーザー検証*を行ってからアクセスを許可し、正当なユーザーのみがアクションを承認できるようにします。一方、ユーザー検証機能を備えていない Authenticator や、ユーザー検証が要件でないときにユーザー検証をスキップできる Authenticator もあります。
+ 一部の Authenticator (YubiKey ハードウェアトークンなど) はポータブルであり、USB、Bluetooth、または NFC 接続を介してデバイスと通信します。一部の Authenticator はローカルであり、PC の Windows Hello や iPhone の Face ID など、プラットフォームにバインドされています。デバイスにバインドされた Authenticator は、モバイルデバイスのように十分に小さい場合、ユーザーが持ち運ぶことができます。ワイヤレス通信を使用して、ハードウェア Authenticator をさまざまなプラットフォームに接続できる場合もあります。例えば、デスクトップブラウザのユーザーは、QR コードをスキャンするときに、スマートフォンをパスキー Authenticator として使用できます。
+ 一部のプラットフォームにバインドされたパスキーはクラウドに同期されるため、複数の場所から使用できます。例えば、iPhone の Face ID パスキーは、パスキーメタデータを iCloud キーチェーン内のユーザーの Apple アカウントと同期します。これらのパスキーは、ユーザーが各デバイスを個別に登録する必要がなく、Apple デバイス間でのシームレスな認証を許可します。1Password、Dashlane、Bitwarden などのソフトウェアベースの Authenticator は、ユーザーがこれをインストールしたすべてのプラットフォームでパスキーを同期します。

WebAuthn の用語では、ウェブサイトとアプリは*依拠しているパーティ*です。各パスキーは、特定の依拠しているパーティの ID に関連付けられます。この ID は、パスキー認証を受け入れるウェブサイトやアプリを表す統合識別子となります。開発者は、適切な認証範囲を確保するために、依拠しているパーティの ID を慎重に選択する必要があります。一般的な依拠しているパーティの ID は、ウェブサーバーのルートドメイン名です。この依拠しているパーティの ID 仕様を持つパスキーは、該当するドメインとサブドメインに対して認証できます。ユーザーがアクセスするウェブサイトの URL が依拠しているパーティの ID と一致しない場合、ブラウザとプラットフォームはパスキー認証を拒否します。同様に、モバイルアプリの場合、パスキーを使用できるのは、`.well-known` 関連付けファイルにアプリケーションパスが存在する場合のみです。このファイルは、依拠しているパーティの ID が示すパスにおいてアプリケーションが使用可能にします。

パスキーは*検出可能*です。ユーザーがユーザー名を入力することなく、ブラウザまたはプラットフォームで自動的に認識して使用できます。ユーザーは、パスキー認証をサポートするウェブサイトやアプリにアクセスすると、ブラウザまたはプラットフォームが既に認識しているパスキーのリストから選択できます。QR コードをスキャンすることもできます。

### Amazon Cognito でパスキー認証を実装する方法
<a name="amazon-cognito-user-pools-authentication-flow-methods-passkey-cognito"></a>

パスキーは、**ライト**を除くすべての[機能プラン](cognito-sign-in-feature-plans.md)で使用できるオプトイン機能です。[選択ベースの認証フロー](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)でのみ使用できます。[マネージドログイン](authentication-flows-selection-managedlogin.md)では、Amazon Cognito がパスキー認証のロジックを処理します。[AWS SDK で Amazon Cognito ユーザープールの API](#amazon-cognito-user-pools-authentication-flow-methods) を使用して、アプリケーションのバックエンドでパスキー認証を行うこともできます。

Amazon Cognito は、ES256 (-7) と RS256 (-257) の 2 つの非対称暗号化アルゴリズムのいずれかを使用して作成されたパスキーを認識します。ほとんどの Authenticator は両方のアルゴリズムをサポートしています。デフォルトでは、ユーザーはハードウェアトークン、モバイルスマートフォン、ソフトウェア Authenticator アプリケーションなど、あらゆるタイプの認証を設定できます。Amazon Cognito は現在、[証明](https://csrc.nist.gov/glossary/term/attestation)の強制をサポートしていません。

ユーザープールでは、ユーザー検証を [優先] または [必須] に設定できます。この設定は、値を指定しない API リクエストではデフォルトで [優先] になり、Amazon Cognito コンソールではデフォルトで [優先] が選択されます。ユーザー検証を [優先] に設定すると、ユーザーはユーザー検証機能を持たない Authenticator を設定でき、登録および認証オペレーションはユーザー検証なしで成功します。パスキーの登録と認証でユーザー検証を義務付けるには、この設定を [必須] に変更します。

パスキー設定で設定した依拠しているパーティ (RP) の ID は重要な決定事項です。特に指定せず、[ドメインブランディングバージョン](managed-login-branding.md)がマネージドログインの場合、ユーザープールはデフォルトで[カスタムドメイン](cognito-user-pools-add-custom-domain.md)の名前を RP ID として想定します。カスタムドメインがなく、特に指定しない場合、ユーザープールはデフォルトで[プレフィックスドメイン](cognito-user-pools-assign-domain-prefix.md)の RP ID になります。パブリックサフィックスリスト (PSL) にないドメイン名に RP ID を設定することもできます。RP ID エントリは、マネージドログインと SDK 認証のパスキー登録と認証に適用されます。パスキーは、Amazon Cognito が RP ID をドメインとする `.well-known` 関連付けファイルを見つけることができるモバイルアプリケーションでのみ機能します。ベストプラクティスとして、ウェブサイトまたはアプリが公開される前に、依拠しているパーティの ID の値を決定して設定します。RP ID を変更すると、ユーザーは新しい RP ID を使用して再登録する必要があります。

各ユーザーは最大 20 個のパスキーを登録できます。パスキーを登録できるのは、少なくとも 1 回ユーザープールにサインインした後のみです。マネージドログインは、パスキー登録の労力を大幅に軽減します。ユーザープールとアプリケーションクライアントのパスキー認証を有効にすると、マネージドログインドメインを持つユーザープールは、エンドユーザーが新しいユーザーアカウントにサインアップした後にパスキーを登録するよう通知します。また、ユーザーのブラウザをいつでも呼び出して、パスキー登録用のマネージドログインページに誘導することもできます。Amazon Cognito がパスキー認証を開始する前に、ユーザーはユーザー名を入力する必要があります。マネージドログインは、これを自動的に処理します。サインインページでユーザー名の入力を求め、ユーザーが少なくとも 1 つのパスキーを登録していることを検証し、パスキーを使用してサインインするよう促します。同様に、SDK ベースのアプリケーションは、ユーザー名の入力を求め、認証リクエストでユーザー名を提供する必要があります。

パスキーを使用したユーザープール認証を設定したときに、カスタムドメインとプレフィックスドメインがある場合、RP ID はデフォルトでカスタムドメインの完全修飾ドメイン名 (FQDN) になります。Amazon Cognito コンソールでプレフィックスドメインを RP ID として設定するには、カスタムドメインを削除するか、プレフィックスドメインの FQDN を**サードパーティドメイン**として入力します。

------
#### [ Activate passkey sign-in ]

**コンソール**  
パスキーによるサインインを有効にするには、1 つ以上のパスワードなしのタイプでプライマリサインインを許可するようにユーザープールを設定し、さらに `USER_AUTH` フローを許可するようにアプリケーションクライアントを設定します。Amazon Cognito コンソールで、ユーザープール設定の **[認証]** の下にある **[サインイン]** メニューに移動します。**[選択ベースのサインインのオプション]** を編集し、**[利用できる選択肢]** のリストに **[パスキー]** を追加します。

**[認証方法]** メニューに移動し、**[パスキー]** を編集します。
+ **[ユーザー検証]** は、現在のユーザーがパスキーの使用を許可されていることを追加でチェックするために、ユーザープールでパスキーデバイスを必須にするかどうかの設定です。ユーザー検証を使用してデバイスを設定するようユーザーに推奨するが、必須にしない場合は、**[優先]** を選択します。ユーザー検証を必要とするデバイスのみをサポートする場合は、**[必須]** を選択します。詳細については、w3.org で「[ユーザー検証](https://www.w3.org/TR/webauthn-2/#user-verification)」を参照してください。
+ **[依拠しているパーティーの ID のドメイン]** は、アプリケーションからユーザーのパスキー登録リクエストに渡す識別子です。ユーザーのパスキー発行者と信頼関係を持つ対象を設定します。依拠しているパーティの ID は、以下の場合に、ユーザープールのドメインになります。  
**Cognito ドメイン**  
ユーザープールの Amazon Cognito [プレフィックスドメイン](cognito-user-pools-assign-domain-prefix.md)。  
**カスタムドメイン**  
ユーザープールの[カスタムドメイン](cognito-user-pools-add-custom-domain.md)。  
**サードパーティードメイン**  
ユーザープールのマネージドログインページを使用しないアプリケーションのドメイン。この設定は通常、[ドメイン](cognito-user-pools-assign-domain.md)を持たないユーザープールに関連付けられ、バックエンドで AWS SDK とユーザープール API を使用して認証を実行します。

**[アプリケーションクライアント]** メニューに移動し、アプリケーションクライアントを選択するか、新しいアプリケーションクライアントを作成します。**[編集]** を選択し、**[認証フロー]** で **[サインイン時に認証タイプを選択: ALLOW\$1USER\$1AUTH]** を選択します。

**API/SDK**  
ユーザープール API で、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) リクエストの適切なパスキーオプションを使用して `SignInPolicy` を設定します。パスキー認証の `WEB_AUTHN` オプションには、他のオプションの少なくとも 1 つを追加する必要があります。パスキー登録には、既存の認証セッションが必要です。

```
"SignInPolicy": { 
    "AllowedFirstAuthFactors": [ 
        "PASSWORD",
        "WEB_AUTHN"
    ]
}
```

ユーザー検証の設定と RP ID を [SetUserPoolMfaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserPoolMfaConfig.html#CognitoUserPools-SetUserPoolMfaConfig-request-WebAuthnConfiguration) リクエストの `WebAuthnConfiguration` パラメータに指定します。パスキー認証結果の対象となる `RelyingPartyId` は、ユーザープールのプレフィックスドメインまたはカスタムドメインにするか、独自に選択したドメインにすることができます。

```
"WebAuthnConfiguration": { 
   "RelyingPartyId": "example.auth.us-east-1.amazoncognito.com",
   "UserVerification": "preferred",
   "FactorConfiguration": "SINGLE_FACTOR"
}
```

[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) リクエストまたは [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) リクエストの必要なオプションを使用して、アプリケーションクライアント `ExplicitAuthFlows` を設定します。

```
"ExplicitAuthFlows": [ 
   "ALLOW_USER_AUTH"
]
```

------
#### [ Register a passkey (managed login) ]

マネージドログインは、ユーザーのパスキー登録を処理します。ユーザープールでパスキー認証が有効な場合、Amazon Cognito は新規ユーザーアカウントの登録時にパスキーを設定するようユーザーに求めます。

ユーザーがサインアップ済みでパスキーを設定していないか、アカウントが管理者権限で作成されている場合、Amazon Cognito はパスキーを設定するようユーザーに促しません。この状態のユーザーは、パスキーを登録する前に、パスワードやパスワードなしの OTP など、別の要素でサインインする必要があります。

**パスキーを登録するには**

1. [サインインページ](authorization-endpoint.md)にユーザーを誘導します。

   ```
   https://auth.example.com/oauth2/authorize/?client_id=1example23456789&response_type=code&scope=email+openid+phone&redirect_uri=https%3A%2F%2Fwww.example.com
   ```

1. ユーザーからの認証結果を処理します。この例の場合、Amazon Cognito は、アプリケーションがトークンと交換する認証コードを使用して、ユーザーを `www.example.com` にリダイレクトします。

1. ユーザーをパスキー登録ページに誘導します。ユーザーには、ブラウザ Cookie があり、サインインセッションを維持します。パスキー URL は `client_id` パラメータと `redirect_uri` パラメータを使用します。Amazon Cognito は、認証されたユーザーにのみ、このページへのアクセスを許可します。パスワード、E メール OTP、または SMS OTP を使用してユーザーをサインインさせ、次のパターンに一致する URL を呼び出します。

   このリクエストに、`response_type` や `scope` など、[認可エンドポイント](authorization-endpoint.md)の他のパラメータを追加することもできます。

   ```
   https://auth.example.com/passkeys/add?client_id=1example23456789&redirect_uri=https%3A%2F%2Fwww.example.com
   ```

------
#### [ Register a passkey (SDK) ]

メタデータを使用してパスキーの認証情報を [PublicKeyCreationOptions](https://www.w3.org/TR/webauthn-3/#dictdef-publickeycredentialcreationoptions) オブジェクトに登録します。このオブジェクトは、サインインしたユーザーの認証情報を使用して生成し、API リクエストでパスキー発行者に提示できます。発行者は、[RegistrationResponseJSON](https://www.w3.org/TR/webauthn-3/#dictdef-registrationresponsejson) オブジェクトを返して、パスキーの登録を確認します。

パスキー登録プロセスを開始するには、既存のサインインオプションを使用してユーザーをサインインさせます。現在のユーザーのアクセストークンを使用して、[トークンで認可された](authentication-flows-public-server-side.md#user-pool-apis-auth-unauth-token-auth)[StartWebAuthnRegistration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_StartWebAuthnRegistration.html) API リクエストを承認します。次に示すのは、`GetWebAuthnRegistrationOptions` リクエストの本文の例です。

```
{
   "AccessToken": "eyJra456defEXAMPLE"
}
```

ユーザープールからのレスポンスには、`PublicKeyCreationOptions` オブジェクトが含まれています。このオブジェクトを API リクエストでユーザーの発行者に提示します。オブジェクトは、パブリックキーや依拠しているパーティの ID などの情報を提供します。発行者は `RegistrationResponseJSON` オブジェクトで応答します。

[CompleteWebAuthnRegistration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CompleteWebAuthnRegistration.html) API リクエストで (ユーザーのアクセストークンで再認可された) 登録レスポンスを提示します。ユーザープールから空の本文を持つ HTTP 200 レスポンスが返されると、ユーザーのパスキーが登録されています。

------
#### [ Sign in with a passkey ]

パスワードなしのサインインには、[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) で指定できる `AuthFlow` はありません。代わりに、`USER_AUTH` の `AuthFlow` を宣言してサインインオプションをリクエストするか、ユーザープールからのレスポンスでパスワードなしのオプションを選択する必要があります。ユーザーをアプリケーションにサインインさせるには、`InitiateAuth` リクエストまたは `AdminInitiateAuth` リクエストの本文を、以下のように設定します。このパラメータセットは、サインインに必要な最小限のものです。その他のパラメータも使用可能です。

この例では、ユーザーがパスキーでサインインすることがわかっているため、`PREFERRED_CHALLENGE` パラメータを追加します。

```
{
   "AuthFlow": "USER_AUTH",
   "AuthParameters": { 
      "USERNAME" : "testuser",
      "PREFERRED_CHALLENGE" : "WEB_AUTHN"
   },
   "ClientId": "1example23456789"
}
```

Amazon Cognito は `WEB_AUTHN` チャレンジで応答します。アプリケーションは、このチャレンジに応答する必要があります。ユーザーのパスキープロバイダーを使用してサインインリクエストを開始します。[AuthenticationResponseJSON](https://www.w3.org/TR/webauthn-3/#dictdef-authenticationresponsejson) オブジェクトが返されます。

```
{
   "ChallengeName": "WEB_AUTHN",
   "ChallengeResponses": {
      "USERNAME" : "testuser", 
      "CREDENTIAL" : "{AuthenticationResponseJSON}" 
   },
   "ClientId": "1example23456789",
   "Session": "[Session ID from the previous response]"
}
```

------

## サインイン後の MFA
<a name="amazon-cognito-user-pools-authentication-flow-methods-mfa"></a>

ユーザー名パスワードフローでサインインを完了したユーザーに対して、E メールメッセージ、SMS メッセージ、またはコード生成アプリケーションのワンタイムパスワードを使用した追加の検証を求めるように設定できます。MFA は、ワンタイムパスワードによるパスワードレスサインインとは異なります。ただし、ユーザープール `MULTI_FACTOR_WITH_USER_VERIFICATION`で を `FactorConfiguration`として設定すると、ユーザー検証付きのパスキーは MFA 要件を満たすことができます`WebAuthnConfiguration`。パスワードベースのフローの場合、ユーザープールの MFA はチャレンジレスポンスモデルであり、ユーザーは最初にパスワードを知っていることを示し、次に登録された第 2 要素デバイスにアクセスできることを示します。

**実装リソース**
+ [ユーザープールに MFA を追加します](user-pool-settings-mfa.md)

## 更新トークン
<a name="amazon-cognito-user-pools-authentication-flow-methods-refresh"></a>

認証情報を再入力せずにユーザーがサインインしたままにする場合、*更新トークン*は、アプリケーションがユーザーのセッションを維持するためのツールとなります。アプリケーションは、更新トークンをユーザープールに提示し、新しい ID トークンやアクセストークンと交換できます。トークンの更新により、サインインしているユーザーが引き続きアクティブであることの確認、更新された属性情報の取得、ユーザーの介入なしのアクセスコントロール権限の更新を行うことができます。

**実装リソース**
+ [更新トークン](amazon-cognito-user-pools-using-the-refresh-token.md)

## カスタム認証
<a name="amazon-cognito-user-pools-authentication-flow-methods-custom"></a>

ここに記載していない、ユーザーの認証方法を設定することもできます。そのためには、Lambda トリガーによる*カスタム認証*を使用します。一連の Lambda 関数により、Amazon Cognito はチャレンジを発行し、ユーザーに回答を求める質問を行い、回答が正確であることを確認し、別のチャレンジを発行すべきかどうかを判断します。質問と回答には、セキュリティの質問、CAPTCHA サービスへのリクエスト、外部 MFA サービス API へのリクエスト、またはこれらすべてが順に含まれます。

**実装リソース**
+ [カスタム認証チャレンジの Lambda トリガー](user-pool-lambda-challenge.md)

### カスタム認証フロー
<a name="amazon-cognito-user-pools-custom-authentication-flow"></a>

Amazon Cognito ユーザープールにより、カスタム認証フローを使用することもできます。これは AWS Lambda トリガーを使用したチャレンジ/レスポンスベースの認証モデルの作成に役立ちます。

カスタム認証フローを使用すると、チャレンジとレスポンスサイクルをカスタマイズすることが可能になり、さまざまな要件に対応できます。このフローは、使用する認証のタイプを示す `InitiateAuth` API 操作の呼び出しから始まり、初期の認証パラメータを提供します。Amazon Cognito は、以下のいずれかの情報を使用して `InitiateAuth` コールに応答します。
+ ユーザーへのチャレンジ、ならびにセッションおよびパラメータ。
+ ユーザーが認証に失敗した場合はエラー。
+ `InitiateAuth` コールで渡されたパラメータがユーザーのサインインに十分な場合は、ID、アクセス権限、更新トークン。(通常、ユーザーまたはアプリケーションは最初にチャレンジに応答する必要がありますが、カスタムコードはこれを判定する必要があります。)

 Amazon Cognito がチャレンジで `InitiateAuth` コールに応答する場合、アプリは追加の入力を収集して、`RespondToAuthChallenge` 操作を呼び出します。このコールは、チャレンジ応答を提供し、セッションを返します。Amazon Cognito は、`RespondToAuthChallenge` コールに対しても `InitiateAuth` コール同様の対応をします。ユーザーがサインインしている場合、Amazon Cognito はトークンを提供します。ユーザーがサインインしていない場合、Amazon Cognito は別のチャレンジまたはエラーを提供します。Amazon Cognito が別のチャレンジを返した場合、ユーザーが正常にサインインするかエラーが返されるまで、シーケンスが繰り返され、アプリは `RespondToAuthChallenge` を呼び出します。`InitiateAuth` API 操作と `RespondToAuthChallenge` API 操作に関する詳細については、[API ドキュメント](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html)に記載されています。

### カスタム認証フローとチャレンジ
<a name="Custom-authentication-flow-and-challenges"></a>

アプリはカスタム認証フローを開始するために、`InitiateAuth` を `CUSTOM_AUTH` として `Authflow` を呼び出すことができます。カスタム認証フローで、3 つの Lambda トリガーがチャレンジとレスポンスの検証を制御します。
+ `DefineAuthChallenge` Lambda トリガーは、以前のチャレンジとレスポンスのセッション配列を入力として使用します。そして、次のチャレンジ名と、ユーザーが認証済みで、トークンを付与できるかどうかを示すブール値を生成します。この Lambda トリガーは、チャレンジを通じてユーザーのパスを制御するステートマシンです。
+ `CreateAuthChallenge` Lambda トリガーは、チャレンジ名を入力として使用し、チャレンジとパラメータを生成してレスポンスを評価します。`DefineAuthChallenge` が次のチャレンジとして `CUSTOM_CHALLENGE` を返すと、認証フローは、`CreateAuthChallenge` を呼び出します。`CreateAuthChallenge`Lambda トリガーは、チャレンジメタデータパラメータで次のタイプのチャレンジを渡します。
+ `VerifyAuthChallengeResponse` Lambda 関数は、レスポンスを評価し、レスポンスが有効であるかどうかを示すブール値を返します。

カスタム認証フローでは、SRP パスワードの検証や SMS を介した MFA などの、内部定義されたチャレンジを組み合わせて使用することもできます。CAPTCHA や秘密の質問などのカスタムチャレンジを使用できます。

### カスタム認証フローにおける SRP パスワードの検証の使用
<a name="Using-SRP-password-verification-in-custom-authentication-flow"></a>

カスタム認証フローに SRP を含める場合には、最初に SRP を処理する必要があります。
+ カスタムフローで SRP パスワードの検証を開始する場合、アプリは `InitiateAuth` を `CUSTOM_AUTH` として `Authflow` を呼び出します。`AuthParameters` マップで、アプリケーションからのリクエストは、`SRP_A:` (SRP A 値) および `CHALLENGE_NAME: SRP_A` を含んでいます。
+ `CUSTOM_AUTH` フローは、`challengeName: SRP_A` および `challengeResult: true` の初期セッションにより、`DefineAuthChallenge` の Lambda トリガーを呼び出します。Lambda 関数は、`challengeName: PASSWORD_VERIFIER`、`issueTokens: false`、および `failAuthentication: false` により、応答します。
+  次にアプリケーションは、(`challengeName: PASSWORD_VERIFIER`、そして `challengeResponses` マップ内の SRP に必要な他のパラメータを使用して) `RespondToAuthChallenge` を呼び出す必要があります。
+ Amazon Cognito がパスワードを検証すると、`challengeName: PASSWORD_VERIFIER` と `challengeResult: true` の 2 番目のセッションで、`RespondToAuthChallenge` により Lambda トリガーの `DefineAuthChallenge` が呼び出されます。その時点で `DefineAuthChallenge` Lambda トリガーは、`challengeName: CUSTOM_CHALLENGE` を使用して応答することでカスタムチャレンジを開始します。
+ MFA がユーザーに対して有効になっている場合、Amazon Cognito がパスワードを確認した後、ユーザーは MFA の設定またはサインインを要求されます。

**注記**  
Amazon Cognito がホストするサインインウェブページは、[カスタム認証チャレンジの Lambda トリガー](user-pool-lambda-challenge.md) をアクティブ化できません。

サンプルコードを含めた Lambda トリガーの詳細については、「[Lambda トリガーを使用したユーザープールワークフローのカスタマイズ](cognito-user-pools-working-with-lambda-triggers.md)」を参照してください。

## ユーザー移行の認証フロー
<a name="amazon-cognito-user-pools-user-migration-authentication-flow"></a>

ユーザー移行用 Lambda トリガーは、レガシーのユーザー管理システムからユーザープールにユーザーを移行する際に役立ちます。`USER_PASSWORD_AUTH` 認証フローを選択している場合には、移行中のユーザーがパスワードをリセットする必要はありません。このフローは、認証中に暗号化された SSL 接続を介してユーザーのパスワードをサービスに送信します。

すべてのユーザーの移行が完了したら、フローをよりセキュアな SRP フローに切り替えます。SRP フローは、ネットワーク経由でパスワードを送信しません。

Lambda トリガーの詳細については、「[Lambda トリガーを使用したユーザープールワークフローのカスタマイズ](cognito-user-pools-working-with-lambda-triggers.md)」を参照してください。

Lambda トリガーを使用したユーザーの移行の詳細については、「[ユーザー移行の Lambda トリガーを使用したユーザーのインポート](cognito-user-pools-import-using-lambda.md)」を参照してください。

# API 認証と SDK 認証の認可モデル
<a name="authentication-flows-public-server-side"></a>

ユーザープール認証を使用してアプリケーション開発を始める場合は、アプリケーションタイプに適した API 認可モデルを決める必要があります。認可モデルとは、Amazon Cognito ユーザープール API および SDK 統合の認証コンポーネントを使用してリクエストを行うための認証を提供するシステムです。Amazon Cognito には、IAM 認可、パブリック、トークン認可の 3 つの承認モデルがあります。

IAM で認可されたリクエストの場合、認可は、リクエストの `Authorization` ヘッダーにある一連の AWS IAM 認証情報による署名から取得されます。サーバー側のアプリケーションの場合、この方法は IAM 認可を使用して認証オペレーションを保護します。パブリック (認証されていない) 認証リクエストでは、認可は必要ありません。これは、ユーザーに配布されるクライアント側のアプリケーションに適しています。トークンで認可されたオペレーションは、通常、パブリックオペレーションと組み合わせて実装され、認可は、リクエストの `Authorization` ヘッダーに含まれるセッショントークンまたはアクセストークンから取得されます。Amazon Cognito 認証では、通常、2 つ以上の API オペレーションを順番に実装する必要があり、使用する API オペレーションはアプリケーションの特性によって異なります。アプリケーションがユーザーに配布されるパブリッククライアントでは、サインインのリクエストに認可を必要としないパブリックオペレーションを使用します。トークンで認可されたオペレーションは、パブリックアプリケーションでユーザーのセッションを続行します。アプリケーションロジックがリモートシステムでホストされているサーバー側のクライアントでは、サインインリクエストの IAM 認可を使用して認証オペレーションを保護します。以下の API オペレーションペアとそれに対応する SDK メソッドは、使用可能な認可モデルに対応しています。

各パブリック認証オペレーションには、[UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html) や [AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) など、サーバー側に同等の形式があります。クライアント側のオペレーションはユーザーが開始し、確認を必要としますが、サーバー側のオペレーションでは、変更がユーザープール管理者によってコミットされたと見なし、変更がすぐに有効になります。この例では、Amazon Cognito からユーザーに確認コードを記載したメッセージを送信し、ユーザーのアクセストークンで [VerifyUserAttribute](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifyUserAttribute.html) リクエストによるコードの送信を許可します。サーバー側のアプリケーションは、任意の属性の値を即座に設定できますが、サインインに E メールアドレスと電話番号を使用する場合、これらの値の変更には[特別な考慮事項が適用](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html#CognitoUserPools-AdminUpdateUserAttributes-request-UserAttributes)されます。

API 認証を比較し、API オペレーションと認可モデルの詳細なリストを確認するには、「[API、OIDC、マネージドログインページの認証についての理解](#user-pools-API-operations)」を参照してください。

------
#### [ Client-side (public) authentication ]

以下は、クライアント側のアプリケーションでの一般的なリクエストのシーケンスです。

1. パブリック [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) オペレーションは、ユーザー名とパスワードなどのプライマリ認証情報を送信します。

1. トークンで認可された [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) オペレーションは、`InitiateAuth` レスポンスからの*セッション*トークンと、MFA などのチャレンジに対する回答を送信します。セッショントークン認可は、まだ完了していない認証サイクルの一部であるリクエストを示します。

1. トークンで認可された [ConfirmDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmDevice.html) オペレーションは、*アクセス*トークンを送信し、記憶されたデバイスをユーザーのプロファイルに追加する書き込みオペレーションを実行します。アクセストークン認可は、ユーザーが認証を完了した後のセルフサービスオペレーションに対するリクエストを示します。

詳細については、「[クライアント側の認証オプション](#amazon-cognito-user-pools-client-side-authentication-flow)」および「[API、OIDC、マネージドログインページの認証についての理解](#user-pools-API-operations)」を参照してください。

------
#### [ Server-side authentication ]

以下は、サーバー側のオペレーションからの一般的なリクエストのシーケンスです。各リクエストには、アプリケーションサーバーに発行された IAM マシン認証情報で署名された [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) の認可ヘッダーがあります。

1. [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) オペレーションは、ユーザー名とパスワードなどのプライマリ認証情報を送信します。

1. [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) オペレーションは、MFA などのチャレンジに対する回答を送信します。

1. [AdminUpdateDeviceStatus](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateDeviceStatus.html) オペレーションは、`AdminInitiateAuth` [レスポンス](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#API_AdminInitiateAuth_ResponseSyntax)のデバイスキーを記憶済みとして設定します。

詳細については、「[サーバー側の認証オプション](#amazon-cognito-user-pools-server-side-authentication-flow)」および「[API、OIDC、マネージドログインページの認証についての理解](#user-pools-API-operations)」を参照してください。

------

認証が失敗するか、Amazon Cognito がユーザーにトークンを発行するまで、ユーザーは連続してチャレンジに回答して認証を進めます。カスタム認証フローをサポートするために、さまざまなチャレンジを含むプロセスで Amazon Cognito でこれらの手順を繰り返すことができます。

**Topics**
+ [サーバー側の認証オプション](#amazon-cognito-user-pools-server-side-authentication-flow)
+ [クライアント側の認証オプション](#amazon-cognito-user-pools-client-side-authentication-flow)
+ [API、OIDC、マネージドログインページの認証についての理解](#user-pools-API-operations)
+ [認可モデル別にグループ化された API オペレーションのリスト](#user-pool-apis-auth-unauth)

## サーバー側の認証オプション
<a name="amazon-cognito-user-pools-server-side-authentication-flow"></a>

ウェブアプリケーションなどの*サーバー側*のアプリケーションは、ブラウザや SSH セッションなどのリモートディスプレイアプリケーションでクライアントがロードする認証をリモートサーバーに実装します。サーバー側のアプリケーションには通常、以下の特性があります。
+ Java、Ruby、Node.js などの言語でサーバーにインストールされたアプリケーションに組み込まれています。
+ ユーザープールの[アプリケーションクライアント](user-pool-settings-client-apps.md)に接続します。アプリケーションクライアントは、*秘密クライアント*と呼ばれるクライアントシークレットを持つ場合があります。
+  AWS 認証情報にアクセスできます。
+ 認証のために[マネージドログイン](cognito-user-pools-managed-login.md)を呼び出すか、 AWS SDK を使用してユーザープール API で IAM で認可されたオペレーションを使用します。
+ 内部のユーザーにサービスを提供するだけでなく、一般のユーザーにサービスを提供する場合もあります。

ユーザープール API を使用したサーバー側のオペレーションでは、パスワード、ワンタイムパスワード、またはパスキーを主要なサインイン要素として使用できます。サーバー側のアプリでのユーザープール認証は、クライアント側のアプリでの認証に似ています。次の点が異なります。
+ サーバー側のアプリケーションは [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) API リクエストを行います。このオペレーションには、 `cognito-idp:AdminInitiateAuth`および を含むアクセス許可を持つ AWS 認証情報が必要です`cognito-idp:AdminRespondToAuthChallenge`。オペレーションは、必要なチャレンジまたは認証結果を返します。
+ アプリケーションはチャレンジを受信すると、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) API リクエストを行います。`AdminRespondToAuthChallenge` API オペレーションには AWS 認証情報も必要です。

 AWS 認証情報を使用した Amazon Cognito API リクエストの署名の詳細については、 *AWS 全般のリファレンス*[の署名バージョン 4 の署名プロセス](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html)を参照してください。

`AdminInitiateAuth` からのレスポンス `ChallengeParameters` では、`USER_ID_FOR_SRP` 属性 (存在する場合) に、ユーザーのエイリアス (E メールアドレスや電話番号など) ではなく、実際のユーザー名が含まれています。`AdminRespondToAuthChallenge` への呼び出しの `ChallengeResponses` では、このユーザー名を `USERNAME` パラメータで渡す必要があります。

**注記**  
バックエンド管理者実装は、管理者認証フローを使用しているため、フローは記憶されたデバイスをサポートしていません。デバイス追跡が有効にしている場合、管理者認証は成功しますが、アクセストークンの更新に関する呼び出しはいずれも失敗します。

## クライアント側の認証オプション
<a name="amazon-cognito-user-pools-client-side-authentication-flow"></a>

モバイルアプリやその他の*クライアント側*のアプリケーションタイプは、ユーザーのデバイスにインストールされ、認証とユーザーインターフェイスのロジックをローカルで実行します。一般的に、以下の特性があります。
+ React native、Flutter、Swift などの言語で構築され、ユーザーデバイスにデプロイされます。
+ *パブリッククライアント*と呼ばれる、クライアントシークレットを持たないユーザープールの[アプリケーションクライアント](user-pool-settings-client-apps.md)に接続します。
+ IAM 認可の API リクエストを許可する AWS 認証情報にアクセスすることはできません。
+ 認証のために[マネージドログイン](cognito-user-pools-managed-login.md)を呼び出すか、 AWS SDK を使用してユーザープール API でパブリックオペレーションとトークン認可オペレーションを使用します。
+ 一般のユーザーにサービスを提供しており、誰でもサインアップしてサインインできます。

ユーザープール API を使用したクライアント側のオペレーションでは、パスワード、ワンタイムパスワード、またはパスキーを主要なサインイン要素として使用できます。[AWS Amplify](https://docs.amplify.aws/javascript/start/getting-started/) または [AWS SDK](https://aws.amazon.com/developer/tools/) で作成したユーザークライアント側のアプリケーションの場合、以下の手順で動作します。

1. ユーザーがアプリにユーザー名とパスワードを入力します。

1. アプリケーションが、ユーザーのユーザー名と SRP (Secure Remote Password) 詳細を使用して、`InitiateAuth` オペレーションを呼び出します。

   この API オペレーションは、認証のパラメータを返します。
**注記**  
アプリは、 AWS SDK に組み込まれている Amazon Cognito SRP 機能を使用して SRP の詳細を生成します。

1. アプリが `RespondToAuthChallenge` 操作を呼び出します。呼び出しが成功すると、Amazon Cognito からユーザーのトークンが返され、認証フローが完了します。

   Amazon Cognito に必要なチャレンジが別に存在する場合は、`RespondToAuthChallenge` を呼び出してもトークンは返されません。代わりに、呼び出しによってセッションが返されます。

1. `RespondToAuthChallenge` からセッションが返された場合、アプリは `RespondToAuthChallenge` を再度呼び出します。今回の呼び出しには、セッションとチャレンジのレスポンス (MFA コードなど) が使用されます。

## API、OIDC、マネージドログインページの認証についての理解
<a name="user-pools-API-operations"></a>

Amazon Cognito ユーザープールは、いくつかの認証テクノロジーの組み合わせです。ユーザープールは、外部 ID プロバイダー (IdP) に依拠しているパーティであり、OpenID Connect (OIDC) SDK を使用して認証を実装するアプリケーションの IdP です。 AWS SDK JSON ウェブトークン (JWT) の発行者として、OIDC 認証に類似した認証を (ただし、SDK の一部である API メソッドで) 提供します。また、アプリケーションへの安全なエントリポイントにもなります。

サインアップ、サインイン、ユーザープール内のユーザー管理を行うには、2 つのオプションがあります。

1. *マネージドログインページ*とクラシックの*ホストされた UI* には、[マネージドログインのユーザーインタラクティブエンドポイント](managed-login-endpoints.md)と、IdP および依拠しているパーティのロールを処理する[フェデレーションエンドポイント](federation-endpoints.md)が含まれています。これらは、ユーザープールの[ドメインを選択すると](cognito-user-pools-assign-domain.md) Amazon Cognito がアクティブ化するパブリックウェブページのパッケージを構成します。サインアップ、サインイン、パスワード管理、多要素認証 (MFA) のページなど、Amazon Cognito ユーザープールの認証および認可機能をすぐに使い始めるには、マネージドログインの組み込みユーザーインターフェイスを使用します。

   その他のユーザープールエンドポイントを使うと、サードパーティーの ID プロバイダー (IdP) を使った認証が容易になります。行われるサービスには以下が含まれます。

   1. IdPs からの認証済みクレーム用のサービスプロバイダーのコールバックエンドポイント (`saml2/idpresponse` や `oauth2/idpresponse` など)。Amazon Cognito がアプリと IdP の間の中間サービスプロバイダー (SP) である場合、コールバックエンドポイントはサービスを表します。

   1. 環境に関する情報を提供するエンドポイント (`oauth2/userInfo` や `/.well-known/jwks.json` など)。アプリケーションは、OIDC または OAuth 2.0 デベロッパーライブラリを使用してトークンを検証したり、ユーザープロファイルデータを取得したりするときに、これらのエンドポイントを使用します。

1. [Amazon Cognito ユーザープール API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html) は、ウェブアプリやモバイルアプリが独自のカスタムフロントエンドでサインイン情報を収集した後で、ユーザーを認証する一連のツールです。ユーザープール API 認証では、次の JSON ウェブトークンが生成されます。

   1. ユーザーからの検証可能な属性クレームを含む ID トークン。

   1. [AWS サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/cognito_identity.html)に対する、トークンで認可された API リクエストを作成することをユーザーに許可するアクセストークン。
**注記**  
デフォルトでは、ユーザープール API 認証のアクセストークンには `aws.cognito.signin.user.admin` スコープのみが含まれます。サードパーティー API へのリクエストを認可するなど、スコープを追加したアクセストークンを生成するには、ユーザープールエンドポイントで認証中にスコープをリクエストするか、[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)でカスタムスコープを追加します。アクセストークンのカスタマイズにより、 AWS 請求書にコストがかかります。

   1. 新しい ID トークンとアクセストークンのリクエストを承認し、ユーザー ID とアクセスコントロールのプロパティを更新する更新トークン。

通常はユーザープールのエンドポイントを使用してサインインするフェデレーションユーザーを、プロファイルがユーザープールに対して*ローカル*であるユーザーとリンクできます。ローカルユーザーは、外部 IdP を介したフェデレーションなしに、ユーザープールディレクトリにのみ存在します。[AdminLinkProviderForUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminLinkProviderForUser.html) API リクエストでフェデレーティッド ID をローカルユーザーにリンクすると、そのユーザーはユーザープール API でサインインできます。詳細については、「[フェデレーションユーザーを既存のユーザープロファイルにリンクする](cognito-user-pools-identity-federation-consolidate-users.md)」を参照してください。

Amazon Cognito ユーザープール API には 2 つの用途があります。

1. Amazon Cognito ユーザープールリソースを作成して設定します。たとえば、ユーザープールの作成、 AWS Lambda トリガーの追加、マネージドログインページをホストするユーザープールドメインの設定を行うことができます。

1. ローカルユーザーおよびリンクされたユーザーのサインアップ、サインイン、その他のユーザーオペレーションを実行します。

**Amazon Cognito ユーザープール API を使用したシナリオ例**

1. ユーザーは、アプリで作成した [Create an account] (アカウントを作成) ボタンを選択します。E メールアドレスとパスワードを入力します。

1. アプリケーションは [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) API リクエストを送信し、ユーザープールに新しいユーザーを作成します。

1. アプリケーションは、ユーザーに E メールの確認コードを求めます。ユーザーは、E メールメッセージで受け取ったコードを入力します。

1. アプリは、ユーザーの確認コードを含む [ConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html) API リクエストを送信します。

1. アプリケーションは、ユーザーにユーザー名とパスワードの入力を求め、情報を入力します。

1. アプリは [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API リクエストを送信し、ID トークン、アクセストークン、更新トークンを保存します。アプリは OIDC ライブラリを呼び出して、ユーザーのトークンを管理し、そのユーザーの永続セッションを維持します。

Amazon Cognito ユーザープール API では、IdP を介してフェデレートするユーザーをサインインすることはできません。これらのユーザーは、ユーザープールのエンドポイントを使用して認証する必要があります。マネージドログインを含むユーザープールエンドポイントの詳細については、「[ユーザープールのエンドポイントとマネージドログインのリファレンス](cognito-userpools-server-contract-reference.md)」を参照してください。

フェデレーションユーザーは、マネージドログインから開始して IdP を選択することも、マネージドログインをスキップしてユーザーを IdP に直接送信してサインインさせることもできます。[認可エンドポイント](authorization-endpoint.md) への API リクエストに IdP パラメータが含まれている場合、Amazon Cognito はユーザーを IdP サインインページにそのままリダイレクトします。

**マネージドログインページを使用したシナリオ例**

1. ユーザーは、アプリで作成した [Create an account] (アカウントを作成) ボタンを選択します。

1. マネージドログインでは、デベロッパーの認証情報を登録したソーシャル ID プロバイダーのリストをユーザーに提示します。ユーザーは Apple を選択します。

1. アプリは、プロバイダー名 `SignInWithApple` で [認可エンドポイント](authorization-endpoint.md) へのリクエストを開始します。

1. ユーザーのブラウザで Apple 認証ページが開きます。ユーザーはサインインし、Amazon Cognitoにプロファイル情報の読み取りを許可することを選択します。

1. Amazon Cognito は Apple アクセストークンを確認し、ユーザーの Apple プロファイルを照会します。

1. ユーザーは Amazon Cognito 認可コードをアプリケーションに提示します。

1. アプリケーション内の OIDC ライブラリは、認証コードを[トークンエンドポイント](token-endpoint.md)と交換し、ユーザープールから発行された ID トークン、アクセストークン、更新トークンを保存します。アプリケーションは、OIDC ライブラリを使用してユーザーのトークンを管理し、ユーザーの永続的なセッションを維持します。

ユーザープール API とマネージドログインページは、このガイド全体で説明しているさまざまなシナリオをサポートしています。次のセクションでは、ユーザープール API がサインアップ、サインイン、およびリソース管理の要件をサポートするクラスにさらにどのように分類されるかを見ていきます。

## 認可モデル別にグループ化された API オペレーションのリスト
<a name="user-pool-apis-auth-unauth"></a>

Amazon Cognito ユーザープール API は、リソース管理インターフェイスとユーザー向け認証および認可インターフェイスの両方であり、運用に続く承認モデルを組み合わせます。API オペレーションによっては、IAM 認証情報、アクセストークン、セッショントークン、クライアントシークレット、またはこれらの組み合わせを使用して認可を行う必要がある場合があります。多くのユーザー認証および認可操作では、リクエストの認証済みバージョンと認証されていないバージョンを選択できます。認証されていない操作は、モバイルアプリなど、ユーザーに配布するアプリのセキュリティ上のベストプラクティスです。コードにシークレットを含める必要はありません。

IAM ポリシーでは、[IAM で認可された管理オペレーション](#user-pool-apis-auth-unauth-sigv4-management) と [IAM で認可されたユーザーオペレーション](#user-pool-apis-auth-unauth-sigv4-user) にのみアクセス許可を割り当てることができます。

### IAM で認可された管理オペレーション
<a name="user-pool-apis-auth-unauth-sigv4-management"></a>

IAM で認可された管理オペレーションでは、 AWS マネジメントコンソールで行う場合と同様に、ユーザープールとアプリケーションクライアントの設定を変更および表示します。

例えば、[UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストでユーザープールを変更するには、リソースを更新するための AWS 認証情報と IAM アクセス許可を提示する必要があります。

 AWS Command Line Interface (AWS CLI) または AWS SDK でこれらのリクエストを承認するには、リクエストに IAM 認証情報を追加する環境変数またはクライアント設定を使用して環境を設定します。詳細については、『』の[AWS 「認証情報 AWS を使用した ](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)へのアクセス」を参照してください*AWS 全般のリファレンス*。Amazon Cognito ユーザープール API の[サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/cognito_identity.html)にリクエストを直接送信することもできます。リクエストのヘッダーに埋め込む AWS 認証情報を使用して、これらのリクエストを承認または*署名*する必要があります。詳細については、[AWS 「 API リクエストの署名](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)」を参照してください。


| IAM で認可された管理オペレーション | 
| --- |
| [AddCustomAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AddCustomAttributes.html) | 
| [CreateGroup](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateGroup.html) | 
| [CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html) | 
| [CreateResourceServer](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateResourceServer.html) | 
| [CreateUserImportJob](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserImportJob.html) | 
| [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) | 
| [CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) | 
| [CreateUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolDomain.html) | 
| [DeleteGroup](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteGroup.html) | 
| [DeleteIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteIdentityProvider.html) | 
| [DeleteResourceServer](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteResourceServer.html) | 
| [DeleteUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserPool.html) | 
| [DeleteUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserPoolClient.html) | 
| [DeleteUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserPoolDomain.html) | 
| [DescribeIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeIdentityProvider.html) | 
| [DescribeResourceServer](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeResourceServer.html) | 
| [DescribeRiskConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeRiskConfiguration.html) | 
| [DescribeUserImportJob](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserImportJob.html) | 
| [DescribeUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPool.html) | 
| [DescribeUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPoolClient.html) | 
| [DescribeUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPoolDomain.html) | 
| [GetCSVHeader](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetCSVHeader.html) | 
| [GetGroup](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetGroup.html) | 
| [GetIdentityProviderByIdentifier](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetIdentityProviderByIdentifier.html) | 
| [GetSigningCertificate](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetSigningCertificate.html) | 
| [GetUICustomization](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUICustomization.html) | 
| [GetUserPoolMfaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserPoolMfaConfig.html) | 
| [ListGroups](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListGroups.html) | 
| [ListIdentityProviders](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListIdentityProviders.html) | 
| [ListResourceServers](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListResourceServers.html) | 
| [ListTagsForResource](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListTagsForResource.html) | 
| [ListUserImportJobs](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUserImportJobs.html) | 
| [ListUserPoolClients](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUserPoolClients.html) | 
| [ListUserPools](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUserPools.html) | 
| [ListUsers](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html) | 
| [ListUsersInGroup](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsersInGroup.html) | 
| [SetRiskConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetRiskConfiguration.html) | 
| [SetUICustomization](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUICustomization.html) | 
| [SetUserPoolMfaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserPoolMfaConfig.html) | 
| [StartUserImportJob](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_StartUserImportJob.html) | 
| [StopUserImportJob](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_StopUserImportJob.html) | 
| [TagResource](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_TagResource.html) | 
| [UntagResource](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UntagResource.html) | 
| [UpdateGroup](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateGroup.html) | 
| [UpdateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html) | 
| [UpdateResourceServer](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateResourceServer.html) | 
| [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) | 
| [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) | 
| [UpdateUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolDomain.html) | 

### IAM で認可されたユーザーオペレーション
<a name="user-pool-apis-auth-unauth-sigv4-user"></a>

IAM で認可されたユーザーオペレーションは、ユーザーのサインアップ、サインイン、認証情報の管理、変更、表示を行います。

例えば、ウェブフロントエンドをバックアップするサーバー側のアプリケーション層を設定できます。これは、Amazon Cognito リソースへの特権アクセスで信頼する OAuth 機密クライアントです。ユーザーをアプリに登録するには、サーバーで [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html) API リクエストに AWS 認証情報を含めることができます。OAuth クライアントタイプの詳細については、「*The OAuth 2.0 Authorization Framework*」の「[Client Types](https://www.rfc-editor.org/rfc/rfc6749#section-2.1)」を参照してください。

 AWS CLI または AWS SDK でこれらのリクエストを認可するには、環境変数またはリクエストに IAM 認証情報を追加するクライアント設定を使用してサーバー側のアプリケーション環境を設定します。詳細については、『』の[AWS 「認証情報 AWS を使用した へのアクセス](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)」を参照してください*AWS 全般のリファレンス*。Amazon Cognito ユーザープール API の[サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/cognito_identity.html)にリクエストを直接送信することもできます。リクエストのヘッダーに埋め込む AWS 認証情報を使用して、これらのリクエストを承認または*署名*する必要があります。詳細については、[AWS 「 API リクエストの署名](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)」を参照してください。

アプリケーションクライアントにクライアントシークレットがある場合は、IAM 認証情報と、オペレーションによっては、`AuthParameters` で `SecretHash` パラメータまたは `SECRET_HASH` 値の両方を指定する必要があります。詳細については、「[シークレットハッシュ 値の計算](signing-up-users-in-your-app.md#cognito-user-pools-computing-secret-hash)」を参照してください。


| IAM で認可されたユーザーオペレーション | 
| --- |
| [AdminAddUserToGroup](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminAddUserToGroup.html) | 
| [AdminConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminConfirmSignUp.html) | 
| [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html) | 
| [AdminDeleteUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminDeleteUser.html) | 
| [AdminDeleteUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminDeleteUserAttributes.html) | 
| [AdminDisableProviderForUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminDisableProviderForUser.html) | 
| [AdminDisableUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminDisableUser.html) | 
| [AdminEnableUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminEnableUser.html) | 
| [AdminForgetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminForgetDevice.html) | 
| [AdminGetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminGetDevice.html) | 
| [AdminGetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminGetUser.html) | 
| [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) | 
| [AdminLinkProviderForUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminLinkProviderForUser.html) | 
| [AdminListDevices](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminListDevices.html) | 
| [AdminListGroupsForUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminListGroupsForUser.html) | 
| [AdminListUserAuthEvents](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminListUserAuthEvents.html) | 
| [AdminRemoveUserFromGroup](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRemoveUserFromGroup.html) | 
| [AdminResetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html) | 
| [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) | 
| [AdminSetUserMFAPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserMFAPreference.html) | 
| [AdminSetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html) | 
| [AdminSetUserSettings](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserSettings.html) | 
| [AdminUpdateAuthEventFeedback](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateAuthEventFeedback.html) | 
| [AdminUpdateDeviceStatus](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateDeviceStatus.html) | 
| [AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) | 
| [AdminUserGlobalSignOut](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUserGlobalSignOut.html) | 

### 認証されていないユーザーオペレーション
<a name="user-pool-apis-auth-unauth-unauth"></a>

認証されていないユーザーオペレーションでは、ユーザーのサインアップ、サインイン、およびパスワードのリセットが開始されます。インターネット上の誰でもがアプリケーションにサインアップしてサインインできるようにする場合は、認証されていない API オペレーション、または*パブリック* API オペレーションを使用します。

例えば、アプリケーションにユーザーを登録するには、シークレットへの特権アクセスを提供しない OAuth パブリッククライアントを配布できます。このユーザーは、認証されていない API オペレーション [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) で登録できます。

 AWS SDK で開発したパブリッククライアントでこれらのリクエストを送信するには、認証情報を設定する必要はありません。また、Amazon Cognito ユーザープール API の[サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/cognito_identity.html)に、追加の認可なしでリクエストを直接送信することもできます。

アプリケーションクライアントにクライアントシークレットがある場合は、オペレーションによっては、`AuthParameters` で `SecretHash` パラメータまたは `SECRET_HASH` 値を指定する必要があります。詳細については、「[シークレットハッシュ 値の計算](signing-up-users-in-your-app.md#cognito-user-pools-computing-secret-hash)」を参照してください。


| 認証されていないユーザーオペレーション | 
| --- |
| [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) | 
| [ConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html) | 
| [ResendConfirmationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html) | 
| [ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html) | 
| [ConfirmForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html) | 
| [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) | 

### トークン認証によるユーザーオペレーション
<a name="user-pool-apis-auth-unauth-token-auth"></a>

トークン認証によるユーザーオペレーションは、ユーザーがサインインしたか、サインインプロセスを開始した後に、ユーザーのサインアウト、認証情報の管理、変更、表示を行います。アプリケーション内でシークレットを配布しない場合や、ユーザー自身の認証情報でリクエストを認可する場合は、トークン認可による API オペレーションを使用してください。ユーザーがサインインを完了した場合、ユーザーのトークン認可された API リクエストをアクセストークンで認可する必要があります。ユーザーがサインインプロセス中である場合は、Amazon Cognito が前のリクエストへのレスポンスで返したセッショントークンを使用して、トークン認可による API リクエストを認可する必要があります。

例えば、パブリッククライアントでは、書き込みアクセスをユーザー自身のプロファイルのみに制限する方法でユーザーのプロファイルを更新する場合があります。この更新を行うには、クライアントが [UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html) API リクエストにユーザーのアクセストークンを含めることができます。

 AWS SDK で開発したパブリッククライアントでこれらのリクエストを送信するには、認証情報を設定する必要はありません。リクエストには `AccessToken` または `Session` パラメータを含めてください。Amazon Cognito ユーザープール API の[サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/cognito_identity.html)にリクエストを直接送信することもできます。サービスエンドポイントへのリクエストを承認するには、リクエストの POST 本文にアクセストークンまたはセッショントークンを含めます。

トークン認証オペレーションの API リクエストに署名するには、アクセストークンをリクエストの `Authorization` ヘッダーとして `Bearer <Base64-encoded access token>` 形式で含めます。


| トークン認証によるユーザーオペレーション | AccessToken | Session | 
| --- |--- |--- |
| [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) |  | ✓ | 
| [ChangePassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ChangePassword.html) | ✓ |  | 
| [GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) | ✓ |  | 
| [StartWebAuthnRegistration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_StartWebAuthnRegistration.html) | ✓ |  | 
| [CompleteWebAuthnRegistration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CompleteWebAuthnRegistration.html) | ✓ |  | 
| [DeleteWebAuthnCredential](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteWebAuthnCredential.html) | ✓ |  | 
| [ListWebAuthnCredentials](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListWebAuthnCredentials.html) | ✓ |  | 
| [UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html) | ✓ |  | 
| [DeleteUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserAttributes.html) | ✓ |  | 
| [DeleteUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUser.html) | ✓ |  | 
| [ConfirmDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmDevice.html) | ✓ |  | 
| [ForgetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgetDevice.html) | ✓ |  | 
| [GetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetDevice.html) | ✓ |  | 
| [ListDevices](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListDevices.html) | ✓ |  | 
| [UpdateDeviceStatus](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateDeviceStatus.html) | ✓ |  | 
| [GetUserAttributeVerificationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserAttributeVerificationCode.html) | ✓ |  | 
| [VerifyUserAttribute](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifyUserAttribute.html) | ✓ |  | 
| [SetUserSettings](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserSettings.html) | ✓ |  | 
| [SetUserMFAPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserMFAPreference.html) | ✓ |  | 
| [GlobalSignOut](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GlobalSignOut.html) | ✓ |  | 
| [UpdateAuthEventFeedback](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateAuthEventFeedback.html) |  | ✓ | 
| [AssociateSoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AssociateSoftwareToken.html) | ✓ | ✓ | 
| [VerifySoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifySoftwareToken.html) | ✓ | ✓ | 
| [RevokeToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RevokeToken.html)¹ |  |  | 
| [GetTokensFromRefreshToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetTokensFromRefreshToken.html)¹ |  |  | 

¹ `RevokeToken` と `GetTokensFromRefreshToken` は、更新トークンを認証パラメータとして受け取ります。更新トークンは、認証トークンとして、またターゲットリソースとして機能します。

# サードパーティーの ID プロバイダーを使用したユーザープールへのサインイン
<a name="cognito-user-pools-identity-federation"></a>

アプリケーションユーザーは、ユーザープール経由で直接サインインするか、またはサードパーティーの ID プロバイダー (IdP) 経由でフェデレーション方式で認証を行うことができます。ユーザープールは、Facebook、Google、Amazon、Apple 経由のソーシャルサインイン、および OpenID Connect (OIDC) と SAML IdP から返されるトークンの処理のオーバーヘッドを管理します。組み込みの Hosted Web UI では、Amazon Cognito がすべての認証済みユーザーに関するトークンの処理と管理を提供します。このように、バックエンドシステムは 1 セットのユーザープールトークンで標準化できます。

## Amazon Cognito ユーザープールでのフェデレーションサインインの仕組み
<a name="cognito-user-pools-identity-federation-how-it-works"></a>

サードパーティー (フェデレーション) 経由のサインインは、Amazon Cognito のユーザープールで使用できます。この機能は、Amazon Cognito ID プール (フェデレーティッド ID) 経由のフェデレーションとは無関係です。

![\[ソーシャルサインインの認証の概要\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/scenario-authentication-cup.png)


Amazon Cognito はユーザーディレクトリであり、OAuth 2.0 ID プロバイダー (IdP) です。Amazon Cognito ディレクトリに*ローカルユーザー*をサインインさせると、ユーザープールがアプリの IdP になります。ローカルユーザーは、外部 IdP を介したフェデレーションなしに、ユーザープールディレクトリにのみ存在します。

Amazon Cognito をソーシャル、SAML、または OpenID Connect (OIDC) IdP に接続すると、ユーザープールは複数のサービスプロバイダーとアプリ間のブリッジとして機能します。IdP にとって、Amazon Cognito はサービスプロバイダー (SP) です。IdP は、OIDC ID トークンまたは SAML アサーションを Amazon Cognito に渡します。Amazon Cognito は、トークンまたはアサーション内のユーザーに関するクレームを読み取り、それらのクレームをユーザープールディレクトリ内の新しいユーザープロファイルにマッピングします。

Amazon Cognito は、フェデレーションユーザーのユーザープロファイルを独自のディレクトリに作成します。Amazon Cognito は、IdP からのクレームと、OIDC およびソーシャル ID プロバイダーの場合は、IdP によるパブリック `userinfo` エンドポイントに基づいて、ユーザーに属性を追加します。マッピングされた IdP 属性が変更されると、ユーザーの属性はユーザープール内で変化します。さらに、IdP の属性から独立した属性を追加することもできます。

Amazon Cognito がフェデレーションユーザーのプロファイルを作成すると、その機能が変更され、SP となったアプリに IdP として表示されます。Amazon Cognito は OIDC と OAuth 2.0 IdP の組み合わせです。アクセストークン、ID トークン、およびリフレッシュトークンを生成します。トークンの詳細については、[ユーザープール JSON ウェブトークン (JWT) の理解](amazon-cognito-user-pools-using-tokens-with-identity-providers.md) を参照してください。

フェデレーションまたはローカルを問わず、ユーザーを認証して認可するために、Amazon Cognito と統合するアプリを設計する必要があります。

## Amazon Cognito のサービスプロバイダーとしてのアプリの責任
<a name="cognito-user-pools-identity-federation-how-it-works-app-responsibilities"></a><a name="cognito-user-pools-identity-federation-how-it-works-app-responsibilities"></a>

**トークンの情報を検証して処理する**  
ほとんどのシナリオでは、Amazon Cognito は認証されたユーザーを、認可コードを追加したアプリの URL にリダイレクトします。アプリは、アクセス、ID、およびリフレッシュの各トークンと[このコードを交換](https://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html)します。そして、[トークンの有効性を確認](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html)し、トークン内のクレームに基づいて、ユーザーに情報を提供する必要があります。

**Amazon Cognito API リクエストによる認証イベントへの応答**  
アプリは、[Amazon Cognito ユーザープール API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html) と[認証 API エンドポイント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-userpools-server-contract-reference.html)と統合する必要があります。認証 API は、ユーザーのサインインとサインアウトを行い、トークンを管理します。ユーザープール API には、ユーザープール、ユーザー、および認証環境のセキュリティを管理するさまざまなオペレーションがあります。アプリは。Amazon Cognito からの応答を受信したときに次に何をすべきかを知っている必要があります。

## Amazon Cognito ユーザープールサードパーティーサインインについて知っておくべきこと
<a name="cognito-user-pools-identity-federation-how-it-works-considerations"></a><a name="cognito-user-pools-identity-federation-how-it-works-considerations"></a>
+ フェデレーションプロバイダーでユーザーにサインインさせたい場合は、ドメインを選択する必要があります。これにより、[マネージドログイン](cognito-userpools-server-contract-reference.md)用のページが設定されます。詳細については、「[マネージドログインに独自のドメインを使用する](cognito-user-pools-add-custom-domain.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) のような API オペレーションを使用してフェデレーションユーザーでサインインすることはできません。フェデレーションユーザーは、[ログインエンドポイント](login-endpoint.md) または [認可エンドポイント](authorization-endpoint.md) でのみサインインできます。
+ [認可エンドポイント](authorization-endpoint.md) はリダイレクションエンドポイントです。リクエストに `idp_identifier` パラメータまたは `identity_provider` パラメータを指定すると、マネージドログインをバイパスして、IdP にサイレントにリダイレクトされます。それ以外の場合は、マネージドログインの[ログインエンドポイント](login-endpoint.md)にリダイレクトされます。
+ マネージドログインがセッションをフェデレーティッド IdP にリダイレクトすると、Amazon Cognito は、`Amazon/Cognito` リクエストに `user-agent` ヘッダーを含めます。
+ Amazon Cognito は、フェデレーションユーザープロファイルの `username` 属性を、固定識別子と IdP の名前の組み合わせから派生します。カスタム要件に一致するユーザー名を生成するには、`preferred_username` 属性へのマッピングを作成します。詳細については、「[マッピングについて知っておくべきこと](cognito-user-pools-specifying-attribute-mapping.md#cognito-user-pools-specifying-attribute-mapping-requirements)」を参照してください。

  例: `MyIDP_bob@example.com`
+ Amazon Cognito は、ユーザープールに追加する OIDC、SAMl、ソーシャル IdP ごとに[ユーザーグループ](cognito-user-pools-user-groups.md)を作成します。グループ名の形式は `[user pool ID]_[IdP name]` です (例: `us-east-1_EXAMPLE_MYSSO`、`us-east-1_EXAMPLE_Google`)。自動生成された一意の各 IdP ユーザープロファイルは、このグループに自動的に追加されます。[リンクされたユーザー](cognito-user-pools-identity-federation-consolidate-users.md)は、このグループに自動的に追加されませんが、そのプロファイルを別のプロセスでグループに追加できます。
+ Amazon Cognito は、フェデレーションユーザーの ID に関する情報を属性および `identities` と呼ばれる ID トークン内のクレームに記録します。このクレームには、ユーザーのプロバイダーと、プロバイダーからの一意の ID が含まれます。ユーザープロファイル内の `identities` 属性を直接変更することはできません。フェデレーションユーザーをリンクする方法の詳細については、「[フェデレーションユーザーを既存のユーザープロファイルにリンクする](cognito-user-pools-identity-federation-consolidate-users.md)」を参照してください。
+ [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html) API リクエストで IdP を更新する場合、変更がマネージドログインに反映されるまでに最大で 1 分かかることがあります。
+ Amazon Cognito は、自身と IdP との間で最大 20 の HTTP リダイレクトをサポートします。
+ ユーザーがマネージドログインを使用してサインインすると、ブラウザは、暗号化されたログインセッション Cookie を保存することで、サインインに使用したクライアントとプロバイダーを記録します。ユーザーが同じパラメータを使用して再度サインインしようとすると、マネージドログインは*有効期限が切れていない*既存のセッションをすべて再利用するため、ユーザーは認証情報を再入力することなく認証されます。ローカルユーザープールログインへの切り替えやローカルユーザープールログインからの切り替えなど、ユーザーが別の IdP で再度ログインする場合は、認証情報を入力して新しいログインセッションを生成する必要があります。

  ユーザープール IdPs は任意のアプリクライアントに割り当てることができ、ユーザーはアプリクライアントに割り当てた IdP でのみサインインできます。

**Topics**
+ [Amazon Cognito ユーザープールでのフェデレーションサインインの仕組み](#cognito-user-pools-identity-federation-how-it-works)
+ [Amazon Cognito のサービスプロバイダーとしてのアプリの責任](#cognito-user-pools-identity-federation-how-it-works-app-responsibilities)
+ [Amazon Cognito ユーザープールサードパーティーサインインについて知っておくべきこと](#cognito-user-pools-identity-federation-how-it-works-considerations)
+ [ユーザープールの ID プロバイダーの設定](cognito-user-pools-identity-provider.md)
+ [ユーザープールによるソーシャル ID プロバイダーの使用](cognito-user-pools-social-idp.md)
+ [ユーザープールによる SAML ID プロバイダーの使用](cognito-user-pools-saml-idp.md)
+ [ユーザープールでの OIDC ID プロバイダーの使用](cognito-user-pools-oidc-idp.md)
+ [IdP 属性をプロファイルとトークンにマッピングする](cognito-user-pools-specifying-attribute-mapping.md)
+ [フェデレーションユーザーを既存のユーザープロファイルにリンクする](cognito-user-pools-identity-federation-consolidate-users.md)

# ユーザープールの ID プロバイダーの設定
<a name="cognito-user-pools-identity-provider"></a>

ユーザープールを使用すると、さまざまな外部 ID プロバイダー (IdP) を通じてサインインを実装できます。ガイドのこのセクションには、Amazon Cognito コンソールでユーザープールを使用してこれらの ID プロバイダーを設定する手順が記載されています。または、ユーザープール API と AWS SDK を使用して、ユーザープール ID プロバイダーをプログラムで追加することもできます。詳細については、「[CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html)」を参照してください。

サポートされている ID プロバイダーのオプションには、Facebook、Google、Amazon などのソーシャルプロバイダー、OpenID Connect (OIDC)、SAML 2.0 プロバイダーなどがあります。開始する前に、IdP の管理認証情報を設定します。プロバイダーのタイプごとに、アプリケーションの登録、必要な認証情報の取得、ユーザープールでのプロバイダーの詳細の設定を行う必要があります。その後、ユーザーは、接続された ID プロバイダーの既存アカウントを使用して、アプリケーションへのサインアップとサインインができます。

**[認証]** の下にある **[ソーシャルプロバイダーと外部プロバイダー]** メニューで、ユーザープールの IdP を追加および更新します。詳細については、「[サードパーティーの ID プロバイダーを使用したユーザープールへのサインイン](cognito-user-pools-identity-federation.md)」を参照してください。

**Topics**
+ [ソーシャル IdP でユーザーサインインを設定する](#cognito-user-pools-facebook-provider)
+ [OIDC IdP でユーザーサインインを設定する](#cognito-user-pools-oidc-providers)
+ [SAML IdP でユーザーサインインを設定する](#cognito-user-pools-saml-providers)

## ソーシャル IdP でユーザーサインインを設定する
<a name="cognito-user-pools-facebook-provider"></a>

フェデレーションを使用して、Amazon Cognito のユーザープールを Facebook、Google、Login with Amazon などのソーシャル ID プロバイダーと統合することができます。

ソーシャル ID プロバイダーを追加するには、最初に ID プロバイダーでデベロッパーアカウントを作成します。デベロッパーアカウントが作成されたら、アプリを ID プロバイダーに登録します。ID プロバイダーがアプリ用のアプリ ID とアプリシークレットを作成するので、これらの値を Amazon Cognito ユーザープールで設定します。
+ [Google Identity Platform](https://developers.google.com/identity/)
+ [Facebook for Developers](https://developers.facebook.com/docs/facebook-login)
+ [Login with Amazon](https://developer.amazon.com/login-with-amazon)
+ [Apple でサインイン](https://developer.apple.com/sign-in-with-apple/)

**ユーザーサインインとソーシャル IdP を統合するには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)にサインインします。プロンプトが表示されたら、 AWS 認証情報を入力します。

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

1. **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択します。

1. **[Add an identity provider]** (ID プロバイダーを追加する) を選択、または、設定した **[Facebook]**、**[Google]**、**[Amazon]**、または **[Apple]** などを選択し、**[Identity provider information]** (ID プロバイダー情報) を検索し、**[Edit]** (編集) をクリックします。ソーシャル ID プロバイダーの追加の詳細については、「[ユーザープールによるソーシャル ID プロバイダーの使用](cognito-user-pools-social-idp.md)」を参照してください。

1. 選択した IdP に基づいて、次のいずれかの手順を実行して、ソーシャル ID プロバイダーの情報を入力します。  
**Facebook、Google、および Login with Amazon**  
クライアントアプリを作成したときに受け取ったアプリ ID とアプリシークレットを入力します。  
**Apple でサインイン**  
Apple に提供したサービス ID、およびアプリケーションクライアントを作成したときに受け取ったチーム ID、キー ID、プライベートキーを入力します。

1. **[Authorize scopes]** (承認スコープ) に、ユーザープール属性にマップするソーシャル ID プロバイダースコープの名前を入力します。スコープは、アプリケーションでアクセスするユーザー属性 (名前や E メールなど) を定義します。スコープを入力するときは、選択した IdP に基づいて、次のガイドラインに従ってください。
   + **Facebook** — スコープはカンマで区切ります。例:

     `public_profile, email`
   + **Google、Login with Amazon、Sign in with Apple** — スコープをスペースで区切ります。例:
     + **Google:** `profile email openid`
     + **Login with Amazon:** `profile postal_code`
     + **Sign In with Apple:** `name email`
**注記**  
Sign in with Apple (コンソール) の場合は、チェックボックスを使用してスコープを選択します。

1. **[Save changes]** (変更の保存) をクリックします。

1. **[アプリケーションクライアント]** メニューで、リストからアプリケーションクライアントを選択し、**[編集]** を選択します。**[Identity providers]** (ID プロバイダー) で、新しいソーシャル ID プロバイダーをアプリケーションクライアントに追加します。

1. **[Save changes]** (変更の保存) をクリックします。

ソーシャル IdP の詳細については、「[ユーザープールによるソーシャル ID プロバイダーの使用](cognito-user-pools-social-idp.md)」を参照してください。

## OIDC IdP でユーザーサインインを設定する
<a name="cognito-user-pools-oidc-providers"></a>

Salesforce や Ping Identity などの OpenID Connect (OIDC) ID プロバイダーとユーザーサインインを統合することができます。

**OIDC プロバイダーをユーザープールに追加するには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. ナビゲーションメニューから **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択し、**[ID プロバイダーを追加]** を選択します。

1. **[OpenID Connect]** (OpenID 接続) ID プロバイダーを選択します。

1. [**Provider name**] (プロバイダー名) に一意の名前を入力します。

1. プロバイダーから受け取ったクライアント ID を、**[Client ID]** (クライアント ID) へ入力します。

1. プロバイダーから受け取ったクライアントシークレットを、**[Client secret]** (クライアントシークレット) に入力します。

1. このプロバイダーの **[Authorized scopes]** (承認済みスコープ) を入力します。スコープは、アプリケーションがプロバイダーにリクエストするユーザー属性のグループ (`name` および `email` など) を定義します。[OAuth 2.0](https://tools.ietf.org/html/rfc6749#section-3.3) 仕様に従い、スコープはスペースで区切る必要があります。

   ユーザーはこれらの属性をアプリケーションに提供することに同意する必要があります。

1. **[Attribute request method]** (属性リクエストメソッド) を選択して、プロバイダーが操作する **[userInfo]** エンドポイントからユーザーの詳細をフェッチするために必要な HTTP メソッド（GET または POST）を Amazon Cognito に提供します。

1. **[Setup method]** (セットアップ方法) を選択して、OpenID Connect エンドポイントを、**[Auto fill through issuer URL]** (発行者 URL による自動入力) または **[Manual input]** (手動入力) で取得します。**[発行者 URL を通じた自動入力]** は、プロバイダーにパブリック `.well-known/openid-configuration` エンドポイントがあり、これを通じて Amazon Cognito が `authorization`、`token`、`userInfo`、`jwks_uri` エンドポイントの URL を取得できる場合に使用します。

1. 発行者の URL、または IdP からの `authorization`、`token`、`userInfo`、および `jwks_uri` エンドポイントの URL を入力します。
**注記**  
検出、自動入力、および手動で入力された URL には、ポート番号 443 と 80 のみを使用できます。OIDC プロバイダーが標準外の TCP ポートを使用している場合、ユーザーログインは失敗します。  
発行者の URL は `https://` で始まる必要があり、`/` 文字で終わらせることはできません。例えば、Salesforce では次の URL を使用します。  
`https://login.salesforce.com`   
発行者 URL に関連付けられている `openid-configuration` ドキュメントには、次の値の HTTPS URL を指定する必要があります: `authorization_endpoint`、`token_endpoint`、`userinfo_endpoint`、および `jwks_uri`。同様に、**[Manual input]** (手動入力) を選択する場合は、HTTPS URL のみを入力できます。

1. デフォルトで、OIDC クレームの **[sub]** (サブ) はユーザープール属性の **[Username]** (ユーザーネーム) にマッピングされます。他の OIDC [クレーム](https://openid.net/specs/openid-connect-basic-1_0.html#StandardClaims)をユーザープール属性にマッピングできます。OIDC クレームを入力し、対応するユーザープール属性をドロップダウンリストから選択します。例えば、通常、クレームの [**email**] はユーザープール属性の [**E メール**] にマッピングされます。

1. ID プロバイダーからユーザープールに追加の属性をマッピングします。詳細は、「[ユーザープール用 ID プロバイダー属性マッピングの特定](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-specifying-attribute-mapping.html)」を参照してください。

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

1. **[アプリケーションクライアント]** メニューで、リストからアプリケーションクライアントを選択します。新しい SAML ID プロバイダーをアプリケーションクライアントに追加するには、**[ログインページ]** タブに移動し、**[マネージドログインページ設定]** の **[編集]** を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

OIDC IdPs の詳細については、「[ユーザープールでの OIDC ID プロバイダーの使用](cognito-user-pools-oidc-idp.md)」を参照してください。

## SAML IdP でユーザーサインインを設定する
<a name="cognito-user-pools-saml-providers"></a>

Amazon Cognito ユーザープールのフェデレーションを使用して、SAML ID プロバイダー (IdP) と統合することができます。メタデータドキュメントを指定します。ファイルをアップロードするか、メタデータドキュメントのエンドポイント URL を入力します。サードパーティーの SAML IdP のメタデータドキュメントの取得については、「[サードパーティー SAML ID プロバイダーの設定](cognito-user-pools-integrating-3rd-party-saml-providers.md)」を参照してください。

**ユーザープールに SAML 2.0 ID プロバイダーを設定する**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択し、**[ID プロバイダーを追加]** を選択します。

1. **[SAML]** ID プロバイダーを選択します。

1. カンマで区切られた **[Identifiers]** (識別子) を入力します。識別子は Amazon Cognito に、ユーザーのサインイン E メールアドレスを確認し、ドメインに対応するプロバイダーに誘導する必要があることを伝えます。

1. ユーザーがログアウトしたときに、Amazon Cognito が署名されたサインアウト要求をプロバイダーに送信するためには、**[Add sign-out flow]** (サインアウトフローの追加) を選択します。マネージドログインの設定時に Amazon Cognito で作成した `https://mydomain.auth.us-east-1.amazoncognito.com/saml2/logout` エンドポイントにサインアウトレスポンスを送信するように、SAML 2.0 ID プロバイダーを設定します。`saml2/logout` エンドポイントでは、ポストバインディングを使用します。
**注記**  
このオプションを選択し、SAML ID プロバイダーが署名付きログアウトリクエストを期待する場合は、SAML IdP で Amazon Cognito が提供する署名証明書を設定する必要もあります。  
SAML IdP は署名されたログアウトリクエストを処理し、Amazon Cognito セッションからユーザーをログアウトさせます。

1. **[Metadata document source]** (メタデータドキュメントソース) を選択します。ID プロバイダーがパブリック URL で SAML メタデータを提供する場合は、**[Metadata document URL]** (メタデータドキュメント URL) を選択してそのパブリック URL を入力できます。それ以外の場合は、**[Upload metadata document]** (メタデータドキュメントをアップロード) を選択し、プロバイダーから以前ダウンロードしたメタデータファイルを選択します。
**注記**  
プロバイダーにパブリックエンドポイントがある場合は、ファイルをアップロードするのではなく、メタデータドキュメントの URL を入力することをお勧めします。URL を使用する場合、Amazon Cognito はメタデータを自動的に更新します。通常、メタデータの更新は 6 時間ごとまたはメタデータの有効期限が切れる前のいずれか早いタイミングで発生します。

1. **[Map attributes between your SAML provider and your app]** (SAML プロバイダーとアプリ間で属性をマッピング) をクリックして、SAML プロバイダーの属性をユーザープールのユーザープロファイルにマッピングします。ユーザープールの必須属性を属性マップに含めます。

   たとえば、**[User pool attribute]** (ユーザープール属性) `email` を選択する場合、ID プロバイダーからの SAML アサーションに表示される SAML 属性名を入力します。ID プロバイダーは、参考として SAML アサーションのサンプルを提供する場合があります。ID プロバイダーの中には、`email` などの単純な名前を使用するものもあれば、次のような URL 形式の属性名を使用するものもあります。

   ```
   http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
   ```

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

**注記**  
HTTPS メタデータエンドポイント URL を使用して SAML IdP を作成中に `InvalidParameterException` が表示される場合、メタデータエンドポイントの SSL が正しくセットアップされていること、および有効な SSL 証明書が関連付けられていることを確認してください。このような例外の例として、「Error retrieving metadata from *<metadata endpoint>*」が挙げられます。

**署名証明書を追加するために SAML IdP をセットアップする**
+ IdP が署名付きログアウトリクエストの検証に使用するパブリックキーを含む証明書を取得するには、次の手順を実行します。

  1. ユーザープールの **[ソーシャルプロバイダーと外部プロバイダー]** メニューに移動します。

  1. SAML プロバイダーを選択します。

  1. **[署名証明書を表示]** を選択します。

SAML IdP の詳細については、「[ユーザープールによる SAML ID プロバイダーの使用](cognito-user-pools-saml-idp.md)」を参照してください。

# ユーザープールによるソーシャル ID プロバイダーの使用
<a name="cognito-user-pools-social-idp"></a>

ウェブおよびモバイルアプリのユーザーは、Facebook、Google、Amazon、Apple などのソーシャル ID プロバイダー (IdP) 経由でサインインできます。組み込みの Hosted Web UI では、Amazon Cognito がすべての認証済みユーザーに関するトークンの処理と管理を提供します。このように、バックエンドシステムは 1 セットのユーザープールトークンで標準化できます。サポートされているソーシャル ID プロバイダーと統合するには、マネージドログインを有効にする必要があります。Amazon Cognito は、マネージドログインページの構築時に OAuth 2.0 エンドポイントを作成します。Amazon Cognito、OIDC IdP、ソーシャル IdP は、このエンドポイントを使用して情報を交換します。詳細については、[Amazon Cognito API リファレンス](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-userpools-server-contract-reference.html)を参照してください。

ソーシャル IdP を に追加するか AWS マネジメントコンソール、CLI または Amazon Cognito API AWS を使用できます。

**注記**  
サードパーティー (フェデレーション) 経由のサインインは、Amazon Cognito のユーザープールで使用できます。この機能は、Amazon Cognito ID プール (フェデレーティッド ID) 経由のフェデレーションとは無関係です。

**Topics**
+ [ソーシャル IdP デベロッパーのアカウントとアプリケーションを設定する](#cognito-user-pools-social-idp-step-1)
+ [ソーシャル IdP を使用してユーザープールを設定する](#cognito-user-pools-social-idp-step-2)
+ [ソーシャル IdP の設定をテストする](#cognito-user-pools-social-idp-step-3)

## ソーシャル IdP デベロッパーのアカウントとアプリケーションを設定する
<a name="cognito-user-pools-social-idp-step-1"></a>

Amazon Cognito でソーシャル IdP を作成する前に、アプリケーションをソーシャル IdP に登録して、クライアント ID とクライアントシークレットを取得する必要があります。

------
#### [ Facebook ]

Meta デベロッパーのアカウントと認証の設定に関する最新情報については、「[Meta でのアプリ開発](https://developers.facebook.com/docs/development)」を参照してください。

**アプリケーションを Facebook/Meta に登録する方法**

1. [Facebook の開発者アカウント](https://developers.facebook.com/docs/facebook-login)を作成します。

1. Facebook 認証情報を使用して[サインイン](https://developers.facebook.com/)します。

1. **[My Apps]** (マイアプリ) メニューから、**[新しいアプリを作成]** (新しいアプリを作成) を選択します。

1. Facebook アプリケーションの名前を入力し、**[Create App ID]** (アプリケーション ID の作成) を選択します。

1. 左のナビゲーションバーで、[**設定**]、[**ベーシック**] の順に選択します。

1. **[App ID]** (アプリ ID)] と **[App Secret** (アプリシークレット) を書き留めます。これらは次のセクションで使用します。

1. ページの下部で、[**\$1 プラットフォームを追加**] を選択します。

1. **[Website]** (ウェブサイト) を選択します。

1. **[Website]** (ウェブサイト) で、アプリケーションのサインインページへのパスを **[Site URL]** (サイト URL) に入力します。

   ```
   https://mydomain.auth.us-east-1.amazoncognito.com/login?response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com
   ```

1. **[Save changes]** (変更の保存) をクリックします。

1. ユーザープールドメインのルートへのパスを **[App Domains]** (アプリケーションドメイン) に入力します。

   ```
   https://mydomain.auth.us-east-1.amazoncognito.com
   ```

1. **[Save changes]** (変更の保存) をクリックします。

1. ナビゲーションバーで **[Add Product]** (プロダクトの追加) を選択し、**[Facebook Login]** (Facebook ログイン) の **[Set up]** (設定) を選択します。

1. ナビゲーションバーで [**Facebook ログイン**]、[**設定**] の順に選択します。

   ユーザープールドメインの `/oauth2/idpresponse` エンドポイントへのパスを **[Valid OAuth Redirect URIs]** (有効な OAuth リダイレクト URI) に入力します。

   ```
   https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/idpresponse
   ```

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ Login with Amazon ]

Login with Amazon デベロッパーのアカウントと認証の設定に関する最新情報については、[「Login with Amazon に関するドキュメント](https://developer.amazon.com/docs/login-with-amazon/documentation-overview.html)」を参照してください。

**アプリケーションを Login with Amazon に登録する方法**

1. [Amazon の開発者アカウント](https://developer.amazon.com/login-with-amazon)を作成します。

1. Amazon 認証情報を使用して[サインイン](https://developer.amazon.com/lwa/sp/overview.html)します。

1. Amazon クライアント ID およびクライアントシークレットを受け取るには、Amazon セキュリティプロファイルを作成する必要があります。

   ページの上部にあるナビゲーションバーで [**Apps and Services (アプリとサービス)**] を選択し、[**Login with Amazon**] を選択します。

1. [**Create a New Security Profile (新しいセキュリティプロファイルの作成)**] を選択します。

1. **[Security Profile Name]** (セキュリティプロファイル名)、**[Security Profile Description]** (セキュリティプロファイルの説明)、**[Consent Privacy Notice URL]** (プライバシー規約 URL の同意) に入力します。

1. **[保存]** を選択します。

1. [**クライアント ID**] および [**クライアントシークレット**] を選択して、クライアント ID およびシークレットを表示します。これらは次のセクションで使用します。

1. 歯車アイコンにマウスカーソルを合わせ、**[Web Settings]** (ウェブ設定)、**[Edit]** (編集) の順に選択します。

1. **[Allowed Origins]** (許可されたオリジン) にユーザープールのドメインを入力します。

   ```
   https://mydomain.auth.us-east-1.amazoncognito.com
   ```

1. `/oauth2/idpresponse` エンドポイントを使用するユーザープールドメインを [**Allowed Return URLs**] (許可されたリターン URL) に入力します。

   ```
   https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/idpresponse
   ```

1. **[保存]** を選択します。

------
#### [ Google ]

Google Cloud プラットフォームの OAuth 2.0 の詳細については、「Google Workspace デベロッパーガイド」ドキュメントの「[認証と認可の詳細](https://developers.google.com/workspace/guides/auth-overview)」を参照してください。

**アプリケーションを Google に登録する方法**

1. [Google の開発者アカウント](https://developers.google.com/identity)を作成します。

1. [Google Cloud Platform コンソール](https://console.cloud.google.com/home/dashboard)にサインインします。

1. 上部のナビゲーションバーから、**[Select a project]** (プロジェクトの選択) を選択します。Google プラットフォームにプロジェクトが既にある場合は、このメニューには代わりにデフォルトのプロジェクトが表示されます。

1. **[NEW PROJECT]** (新しいプロジェクト) を選択します。

1. 製品の名前を入力し、**[CREATE]** (作成) を選択します。

1. 左のナビゲーションバーで、**[APIs and Services]** (API とサービス) を選択し、**[Oauth consent screen]** (OAuth 同意画面) を選択します。

1. アプリ情報、**[App domain]** (アプリドメイン)、**[Authorized domains]** (承認済みドメイン)、**[Developer contact information]** (開発者の連絡先情報) を入力します。**[Authorized domains]** (承認済みドメイン) には、`amazoncognito.com` とカスタムドメインのルート (例: `example.com`) を含める必要があります。**[SAVE AND CONTINUE]** (保存して続行) を選択します。

1. 1. **[Scopes]** (スコープ) で、**[Add or remove scopes]** (スコープの追加または削除) を選択し、少なくとも、次の OAuth スコープを選択します。

   1. `.../auth/userinfo.email`

   1. `.../auth/userinfo.profile`

   1. openid

1. **[Test users]** (テストユーザー) で、**[Add users]** (ユーザーの追加) を選択します。E メールアドレスおよびその他の承認済みテストユーザーを入力して、**[SAVE AND CONTINUE]** (保存して続行) を選択します。

1. 左のナビゲーションバーを再度展開し、**[APIs and Services]** (API とサービス) を選択して、**[Credentials]** (認証情報) を選択します。

1. **[CREATE CREDENTIALS]** (認証情報の作成)、**[OAuth client ID]** (OAuth クライアント ID) の順に選択します。

1. **[Application type]** (アプリケーションタイプ) を選択し、クライアントに **[Name]** (名前) を入力します。

1. **[Authorized JavaScript origins]** (承認済みの JavaScript 生成元) で、**[ADD URI]** (URI の追加) を選択します。ユーザープールのドメインを入力します。

   ```
   https://mydomain.auth.us-east-1.amazoncognito.com
   ```

1. **[Authorized redirect URIs]** (承認済みのリダイレクト URI) で、**[ADD URI]** (URI の追加) を選択します。ユーザープールのドメインの `/oauth2/idpresponse` エンドポイントへのパスを入力します。

   ```
   https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/idpresponse
   ```

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

1. **[Your client ID]** (クライアント ID) と **[Your client secret]** (クライアントシークレット) の下に Google が表示する値を安全に保存します。Google IdP を追加するときに、Amazon Cognito にこれらの値を指定します。

------
#### [ Sign in with Apple ]

「Apple でサインイン」の設定に関する最新の情報については、Apple デベロッパー向けドキュメントの「[Apple でサインインの環境を設定する](https://developer.apple.com/documentation/signinwithapple/configuring-your-environment-for-sign-in-with-apple)」を参照してください。

**アプリケーションを Apple でサインイン (SIWA) に登録する方法**

1. [Apple の開発者アカウント](https://developer.apple.com/programs/enroll/)を作成します。

1. Apple 認証情報を使用して[サインイン](https://developer.apple.com/account/#/welcome)します。

1. 左のナビゲーションバーで、**[Certificates, Identifiers & Profiles]** (証明書、ID & プロファイル) を選択します。

1. 左のナビゲーションペインで、**[Identifiers]** (識別子) を選択します。

1. **[Identifiers]** (識別子) ページで、**[\$1]** アイコンを選択します。

1. **[Register a New Identifier]** (新しい識別子の登録) ページで、**[App IDs]** (アプリ ID)、**[Continue]** (続行) の順に選択します。

1. **[Select a type]** (種類の選択) ページで、**[App]** (アプリ) を選択し、**[Continue]** (続行) を選択します。

1. [**Register an App ID**] ページで、次の操作を行います。

   1. **[Description]** (説明) で、説明を入力します。

   1. **[App ID Prefix]** (アプリ ID プレフィックス) に、**[Bundle ID]** (バンドル ID) を入力します。**[App ID Prefix]** (アプリケーション ID プレフィックス) にある値を書き留めておきます。この値は、[ソーシャル IdP を使用してユーザープールを設定する](#cognito-user-pools-social-idp-step-2) で Apple を ID プロバイダーとして選択した後で使用します。

   1. **[Capabilities] ** (機能) で、**[Sign In with Apple]** (Apple でサインイン) を選択してから **[Edit]** (編集) を選択します。

   1. **[Sign in with Apple: App ID Configuration]** (Apple でサインイン: アプリ ID の設定) ページで、アプリをプライマリとして設定するか、他のアプリ ID とグループ化するかを選択し、次に **[Save]** (保存) を選択します。

   1. [**続行**] をクリックしてください。

1. [**Confirm your App ID**] ページで、[**登録**] を選択します。

1. **[Identifiers]** (識別子) ページで、**[\$1]** アイコンを選択します。

1. **[Register a New Identifier]** (新しい識別子の登録) ページで、**[Services IDs]** (サービス ID)、**[Continue]** (続行) の順に選択します。

1. [**Register a Services ID**] ページで、次の操作を行います。

   1. [**説明**] に、説明を入力します。

   1. [**Identifier**] に、識別子を入力します。このサービス ID をメモしておきます。この値は、[ソーシャル IdP を使用してユーザープールを設定する](#cognito-user-pools-social-idp-step-2) で Apple を ID プロバイダーとして選択した後で必要になります。

   1. **[Continue]** (続行) を選択し、**[Register]** (登録) を選択します。

1. [Identifiers] (識別子) ページから、先ほど作成した [Services ID] (サービス ID) を選択します。

   1. **[Sign In with Apple]** (Apple でサインイン) を選択後、**[Configure] **(設定) を選択します。

   1. **[Web Authentication Configuration]** (ウェブ認証の設定) ページで、**[Primary App ID]** (プライマリアプリ ID) として前に作成したアプリ ID を選択します。

   1. **[Website URLs]** (ウェブサイトの URL) の横の **[\$1]** アイコンを選択します。

   1. **[Domains and subdomains]** (ドメインとサブドメイン) で、`https://` プレフィックスなしでユーザープールのドメインを入力します。

      ```
      mydomain.auth.us-east-1.amazoncognito.com
      ```

   1. **[Return URLs]** (URL を返す) で、ユーザープールのドメインの `/oauth2/idpresponse` エンドポイントへのパスを入力します。

      ```
      https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/idpresponse
      ```

   1. **[Next]** (次へ) を選択し、**[Done]** (完了) を選択します。ドメインを検証する必要はありません。

   1. **[Continue]** (続行) を選択し、次に **[Save]** (保存) を選択します。

1. 左のナビゲーションペインで **[Keys]** (キー) を選択します。

1. [**Keys (キー)**] ページで、[**\$1**] アイコンを選択します。

1. [**Register a New Key**] ページで、次の操作を行います。

   1. **[Key Name]** (キー名) に、キー名を入力します。

   1. **[Sign In with Apple]** (Apple でサインイン) を選択後、**[Configure]** (設定) を選択します。

   1. **[Configure Key]** (キーの設定) ページで、**プライマリアプリ ID** として前に作成したアプリ ID を選択します。**[保存]** を選択します。

   1. **[Continue]** (続行) を選択し、**[Register]** (登録) を選択します。

1. **[Download Your Key]** (鍵のダウンロード) ページで、**[Download]** (ダウンロード) をクリックしてプライベートキーをダウンロードしてから、表示される **[Key ID]** (キー ID) を書き留め、**[Done]** (完了) を選択します。このプライベートキーと、このページに表示されている **[Key ID]** (キー ID) の値は、[ソーシャル IdP を使用してユーザープールを設定する](#cognito-user-pools-social-idp-step-2) で Apple を ID プロバイダーとして選択した後で必要になります。

------

## ソーシャル IdP を使用してユーザープールを設定する
<a name="cognito-user-pools-social-idp-step-2"></a>

**を使用してユーザープールソーシャル IdP を設定するには AWS マネジメントコンソール**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[ユーザープール]** を選択します。

1. リストから既存のユーザープールを選択するか、ユーザープールを新規作成します。

1. **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択し、**[ID プロバイダーを追加]** を選択します。

1. ソーシャル IdP (**[Facebook]**、**[Google]**、**[Login with Amazon]**、**[Sign in with Apple]**) を選択します。

1. ソーシャル IdP の選択に基づいて、次のステップから選択します。
   + **Google** と **Login with Amazon** (Amazon でのログイン) — 前のセクションで生成された **[app client ID]** (アプリケーションクライアント ID) と **[app client secret]** (アプリケーションクライアントシークレット) を入力します。
   + **Facebook** — 前のセクションで生成された **[app client ID]** (アプリケーションクライアント ID) と **[app client secret]** (アプリケーションクライアントシークレット) を入力し、API バージョン (例えば、バージョン 2.12) を選択します。Facebook API の各バージョンにはライフサイクルとサポート終了日があるため、可能な限り最新のバージョンを選択することをお勧めします。Facebook のスコープと属性は API バージョンによって異なる場合があります。Facebook でソーシャル ID ログインをテストして、フェデレーションが意図したとおりに機能することを確認することをお勧めします。
   + **Sign In with Apple** (Apple でのサインイン) — 以前のセクションで作成された **[Services ID]** (サービス ID)、**[Team ID]** (チーム ID)、**[Key ID]** (キー ID) および **[private key]** プライベートキーを入力します。

1. 使用したい **[Authorized scopes]** (承認するスコープ) の名前を入力します。スコープは、アプリでアクセスするユーザー属性 (`name` や `email` など) を定義します。Facebook の場合は、コンマで区切る必要があります。Google および Login with Amazon の場合は、スペースで区切って指定します。Sign in with Apple の場合は、アクセスするスコープのチェックボックスをオンにします。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-social-idp.html)

   アプリケーションユーザーは、これらの属性をアプリケーションに提供することに同意するよう求められます。ソーシャルプロバイダーのスコープの詳細については、Google、Facebook、Login with Amazon、および Sign in with Apple のドキュメントを参照してください。

   以下は、Sign in with Apple の場合にスコープが返らない可能性があるユーザーシナリオです。
   + エンドユーザーが Apple のサインインページを離れるとエラーが発生する (Amazon Cognito の内部障害またはデベロッパーが記述したプログラムが原因である可能性があります)
   + サービス ID 識別子がユーザープールや他の認証サービス全体で使用されている
   + エンドユーザーが以前にサインインしてから、デベロッパーによってさらにスコープが追加されている (新しい情報は取得されません)
   + デベロッパーによって削除されたユーザーが Apple ID プロファイルからアプリを削除せずに再度サインインしている

1. IdP からユーザープールに属性をマッピングします。詳細は、「[ユーザープール用 ID プロバイダー属性マッピングの特定](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-specifying-attribute-mapping.html)」を参照してください。

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

1. **[アプリケーションクライアント]** メニューで、リストからアプリケーションクライアントを選択します。新しいソーシャル ID プロバイダーをアプリケーションクライアントに追加するには、**[ログインページ]** タブに移動し、**[マネージドログインページの設定]** の **[編集]** を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

## ソーシャル IdP の設定をテストする
<a name="cognito-user-pools-social-idp-step-3"></a>

アプリケーションでは、ユーザーのクライアントでブラウザを起動し、ユーザーがソーシャルプロバイダーを使用してサインインできるようにする必要があります。前のセクションのセットアップ手順を完了したら、ソーシャルプロバイダーでのサインインをテストします。次の URL の例では、プレフィックスドメインを持つユーザープールのサインインページをロードします。

```
https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com
```

このリンクは、**[アプリケーションクライアント]** メニューに移動してアプリケーションクライアントを選択し、**[ログインページ]** タブに移動して **[ログインページを表示]** を選択したときに、Amazon Cognito に表示されるページです。ユーザープールドメインの詳細については、「[ユーザープールのドメインを設定する](cognito-user-pools-assign-domain.md)」を参照してください。クライアント ID とコールバック URL など、アプリケーションクライアントの詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。

次のリンク例では、`identity_provider` クエリパラメータを使用して、[認可エンドポイント](authorization-endpoint.md)からソーシャルプロバイダーへのサイレントリダイレクトを設定します。この URL は、マネージドログインによるインタラクティブなユーザープールのサインインをバイパスし、IdP サインインページに直接移動します。

```
https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?identity_provider=Facebook|Google|LoginWithAmazon|SignInWithApple&response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com
```

# ユーザープールによる SAML ID プロバイダーの使用
<a name="cognito-user-pools-saml-idp"></a>

ウェブアプリケーションおよびモバイルアプリケーションのユーザーに対して、[Microsoft Active Directory フェデレーションサービス (ADFS)](https://msdn.microsoft.com/en-us/library/bb897402.aspx) や [Shibboleth](http://www.shibboleth.net/) などの SAML ID プロバイダー (IdP) を通じてサインインすることを許可できます。[SAML 2.0 標準](http://saml.xml.org/saml-specifications)をサポートする SAML IdP を選択します。

マネージドログインを使用すると、Amazon Cognito はローカルおよびサードパーティの IdP ユーザーを認証し、JSON ウェブトークン (JWT) を発行します。Amazon Cognito が発行するトークンを使用すると、複数の ID ソースを、すべてのアプリケーションにわたるユニバーサル OpenID Connect (OIDC) 標準に統合できます。Amazon Cognito は、サードパーティープロバイダーからの SAML アサーションを、その SSO 標準に処理できます。SAML IdP は、、 AWS マネジメントコンソール、 AWS CLIまたは Amazon Cognito ユーザープール API を使用して作成および管理できます。で最初の SAML IdP を作成するには AWS マネジメントコンソール、「」を参照してください[ユーザープールでの SAML ID プロバイダーの追加と管理](cognito-user-pools-managing-saml-idp.md)。

![\[SAML サインインによる認証の概要\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/scenario-authentication-saml.png)


**注記**  
サードパーティー IdP を通じたサインインによるフェデレーションは、Amazon Cognito ユーザープールの機能です。Amazon Cognito フェデレーティッド ID と呼ばれる Amazon Cognito アイデンティティプールは、各アイデンティティプールで個別に設定する必要があるフェデレーションの実装です。ユーザープールは、アイデンティティプールへのサードパーティー IdP にすることができます。詳細については、「[Amazon Cognito アイデンティティプール](cognito-identity.md)」を参照してください。

## IdP 設定のクイックリファレンス
<a name="cognito-user-pools-saml-idp-reference"></a>

リクエストを受け入れ、ユーザープールにレスポンスを送信するように SAML IdP を設定する必要があります。ユーザープールを SAML 2.0 IdP の依拠しているパーティーまたはアプリケーションとして追加する方法に関する情報は、SAML IdP のドキュメントに含まれています。次のドキュメントでは、SP エンティティ ID とアサーションコンシューマーサービス (ACS) URL に対して指定する必要がある値を示します。ユーザープール SAML 値のクイックリファレンス

**SP エンティティ ID**  

```
urn:amazon:cognito:sp:us-east-1_EXAMPLE
```

**ACS URL**  

```
https://Your user pool domain/saml2/idpresponse
```

ID プロバイダーをサポートするためにユーザープールを設定する必要があります。外部 SAML IdP を追加する大まかなステップは次のとおりです。

1. IdP から SAML メタデータをダウンロードするか、メタデータエンドポイントへの URL を取得します。「[サードパーティー SAML ID プロバイダーの設定](cognito-user-pools-integrating-3rd-party-saml-providers.md)」を参照してください。

1. ユーザープールに新しい IdP を追加します。SAML メタデータをアップロードするか、メタデータ URL を指定します。「[ユーザープールでの SAML ID プロバイダーの追加と管理](cognito-user-pools-managing-saml-idp.md)」を参照してください。

1. IdP をアプリケーションクライアントに割り当てます。「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。

**Topics**
+ [IdP 設定のクイックリファレンス](#cognito-user-pools-saml-idp-reference)
+ [Amazon Cognito ユーザープールの SAML IdP について知っておくべきこと](cognito-user-pools-saml-idp-things-to-know.md)
+ [SAML ユーザー名の大文字と小文字の区別](#saml-nameid-case-sensitivity)
+ [サードパーティー SAML ID プロバイダーの設定](cognito-user-pools-integrating-3rd-party-saml-providers.md)
+ [ユーザープールでの SAML ID プロバイダーの追加と管理](cognito-user-pools-managing-saml-idp.md)
+ [Amazon Cognito ユーザープールでの SAML セッション開始](cognito-user-pools-SAML-session-initiation.md)
+ [シングルサインアウトで SAML ユーザーをサインアウトする](cognito-user-pools-saml-idp-sign-out.md)
+ [SAML 署名と暗号化](cognito-user-pools-SAML-signing-encryption.md)
+ [SAML ID プロバイダーの名前と識別子](cognito-user-pools-managing-saml-idp-naming.md)

# Amazon Cognito ユーザープールの SAML IdP について知っておくべきこと
<a name="cognito-user-pools-saml-idp-things-to-know"></a>

SAML 2.0 IdP の実装には、いくつかの要件と制限があります。IdP を実装する場合は、このセクションを参照してください。また、ユーザープールを使用した SAML フェデレーション中に生じるエラーのトラブルシューティングに役立つ情報もあります。

**Amazon Cognito は SAML アサーションを処理する**  
Amazon Cognito ユーザープールは、POST バインドエンドポイントで SAML 2.0 フェデレーションをサポートします。これにより、ユーザープールがユーザーエージェント経由で IdP から直接 SAML レスポンスを受信するため、アプリケーションで SAML アサーションレスポンスを受信して解析する必要がなくなります。ユーザープールはアプリケーションのためのサービスプロバイダー (SP) として機能します。Amazon Cognito は、「[SAML V2.0 Technical Overview](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html)」のセクション 5.1.2 と 5.1.4 で説明されている、SP または IdP によるシングルサインオン (SSO) をサポートしています。

**有効な IdP 署名証明書を提供する**  
ユーザープールで SAML IdP を設定するときに、SAML プロバイダーメタデータの署名証明書の有効期限が切れないようにする必要があります。

**ユーザープールが複数の署名証明書をサポートする**  
SAML IdP の SAML メタデータに複数の署名証明書が含まれている場合、サインイン時に、SAML アサーションが SAML メタデータ内のいずれかの証明書と一致すると、ユーザープールは SAML アサーションが有効であると判断します。各署名証明書の長さは 4,096 文字以下にする必要があります。

**リレー状態パラメータを維持する**  
Amazon Cognito と SAML IdP は、セッション情報を `relayState` パラメータで管理します。  

1. Amazon Cognito は、80 バイトを超える `relayState` 値をサポートします。SAML 仕様では、`relayState` の値は「長さが 80 バイトを超えてはならない」と規定されていますが、現在の業界の慣行はこの動作から外れていることがよくあります。その結果、80 バイトを超える `relayState` 値を拒否すると、多くの標準的な SAML プロバイダーの統合は壊れます。

1. `relayState` トークンは、Amazon Cognito が管理する状態情報への不透明な参照です。Amazon Cognito は `relayState` パラメータの内容を保証しません。その内容を解析してアプリケーションでその結果に依存することは避けてください。詳細については、「[SAML 2.0 の仕様](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)」を参照してください。

**ACS エンドポイントを特定する**  
SAML ID プロバイダーは、アサーションコンシューマーエンドポイントを設定することを要求します。IdP は、SAML アサーションを使用して、このエンドポイントにユーザーをリダイレクトします。SAML ID プロバイダーの SAML 2.0 POST バインド用に、ユーザープールドメインで次のエンドポイントを設定します。  

```
https://Your user pool domain/saml2/idpresponse
With an Amazon Cognito domain:
https://mydomain.auth.us-east-1.amazoncognito.com/saml2/idpresponse
With a custom domain:
https://auth.example.com/saml2/idpresponse
```
ユーザープールドメインの詳細については、「[ユーザープールのドメインを設定する](cognito-user-pools-assign-domain.md)」を参照してください。

**アサーションの再生ができない**  
Amazon Cognito の `saml2/idpresponse` エンドポイントに対して SAML アサーションを繰り返したり、*再生*したりすることはできません。SAML アサーションを作成すると、そのアサーション ID は以前の IdP レスポンスの ID と重複します。

**ユーザープール ID は SP エンティティ ID である**  
IdP については、*オーディエンス URI* または *SP エンティティ ID* とも呼ばれるサービスプロバイダー (SP) `urn` のユーザープール ID で指定する必要があります。ユーザープールのオーディエンス URI の形式は次のとおりです。  

```
urn:amazon:cognito:sp:us-east-1_EXAMPLE
```
ユーザープール ID は、[Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)の **[ユーザープールの概要]** で確認できます。

**必要なすべての属性をマッピングする**  
ユーザープールで必須として設定した属性の値を入力するように SAML IdP を設定します。例えば、`email` はユーザープールの一般的な必須属性です。ユーザーがサインインする前に、**ユーザープール属性** `email` にマッピングするクレームを SAML IdP アサーションに含める必要があります。属性のマッピングの詳細については、「[IdP 属性をプロファイルとトークンにマッピングする](cognito-user-pools-specifying-attribute-mapping.md)」を参照してください。

**アサーション形式には特定の要件がある**  
SAML IdP には、SAML アサーションに次のクレームを含める必要があります。  
+ `NameID` クレーム。Amazon Cognito は、`NameID` によって SAML アサーションを送信先ユーザーと関連付けます。`NameID` が変更になった場合、Amazon Cognito はアサーションを新しいユーザー用と見なします。IdP 設定で `NameID` に設定する属性には永続的な値が必要です。SAML ユーザーをユーザープール内の一貫したユーザープロファイルに割り当てるには、変更されない値を持つ属性からの `NameID` クレームを割り当てます。

  ```
  <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:persistent">
    carlos
  </saml2:NameID>
  ```

  IdP `NameID` クレームの `Format` で `urn:oasis:names:tc:SAML:1.1:nameid-format:persistent` は、IdP が変更のない値を渡していることを示します。Amazon Cognito は、この形式の宣言を必要とせず、IdP が `NameID` クレームの形式を指定しない場合、`urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified` の形式を割り当てます。この動作は、[SAML 2.0 仕様](https://groups.oasis-open.org/higherlogic/ws/public/download/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf/latest)のセクション 2.2.2 (*複合タイプ NameIDType*) に準拠しています。
+ ユーザープールの SP エンティティ ID をレスポンスのターゲットとして設定する値 `Audience` を含む `AudienceRestriction` クレーム。

  ```
  <saml:AudienceRestriction>
    <saml:Audience> urn:amazon:cognito:sp:us-east-1_EXAMPLE
  </saml:AudienceRestriction>
  ```
+ SP が開始したシングルサインオンの場合、元の SAML リクエスト ID の `InResponseTo` 値を持つ `Response` 要素。

  ```
  <saml2p:Response Destination="https://mydomain.auth.us-east-1.amazoncognito.com/saml2/idpresponse" ID="id123" InResponseTo="_dd0a3436-bc64-4679-a0c2-cb4454f04184" IssueInstant="Date-time stamp" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  ```
**注記**  
IdP が開始した SAML アサーションに `InResponseTo` 値を含めることは*できません*。
+ ユーザープール `saml2/idpresponse` エンドポイントの `Recipient` 値と、SP が開始した SAML の場合の、元の SAML リクエスト ID と一致する `InResponseTo` 値を含む `SubjectConfirmationData` 要素。

  ```
  <saml2:SubjectConfirmationData InResponseTo="_dd0a3436-bc64-4679-a0c2-cb4454f04184" NotOnOrAfter="Date-time stamp" Recipient="https://mydomain.auth.us-east-1.amazoncognito.com/saml2/idpresponse"/>
  ```

**SP が開始したサインインリクエスト**  
[認可エンドポイント](authorization-endpoint.md)がユーザーを IdP サインインページにリダイレクトすると、Amazon Cognito は `HTTP GET` リクエストの URL パラメータに *SAML リクエスト*を含めます。SAML リクエストには、ACS エンドポイントなどの、ユーザープールに関する情報が含まれます。オプションで、これらのリクエストに暗号化署名を適用できます。

**リクエストへの署名とレスポンスの暗号化**  
SAML プロバイダーを持つすべてのユーザープールは、Amazon Cognito が SAML リクエストに割り当てるデジタル署名の非対称キーペアと*署名証明書*を生成します。暗号化された SAML レスポンスをサポートするように設定したすべての外部 SAML IdP により、Amazon Cognito は、そのプロバイダーの新しいキーペアと*暗号化証明書*を生成します。パブリックキーを使用して証明書の表示とダウンロードを行うには、Amazon Cognito コンソールの **[ソーシャルプロバイダーと外部プロバイダー]** メニューで IdP を選択します。  
ユーザープールからの SAML リクエストとの信頼を確立するには、ユーザープールの SAML 2.0 署名証明書のコピーを IdP に提供します。署名付きリクエストを受け入れるように IdP を設定しない場合、IdP はユーザープールが署名した SAML リクエストを無視する可能性があります。  

1. Amazon Cognito は、ユーザーが IdP に渡す SAML リクエストにデジタル署名を適用します。ユーザープールは、すべてのシングルログアウト (SLO) リクエストに署名しますが、SAML 外部 IdP のシングルサインオン (SSO) リクエストに署名するようにユーザープールを設定できます。証明書のコピーを提供すると、IdP はユーザーの SAML リクエストの整合性を検証できます。

1. SAML IdP は、暗号化証明書を使用して SAML レスポンスを暗号化できます。SAML 暗号化を使用して IdP を設定する場合、IdP は、暗号化されたレスポンスのみを送信する必要があります。

**アルファベット以外の文字のエンコードを行う**  
Amazon Cognito では、IdP が属性値として渡す 4 バイトの UTF-8 文字 (😐 や 𠮷 など) は受け付けません。文字を Base 64 にエンコードしてテキストとして渡し、アプリでデコードできます。  
次の例では、属性のクレームは受け付けられません。  

```
<saml2:Attribute Name="Name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
  <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">😐</saml2:AttributeValue>
</saml2:Attribute>
```
上記の例とは対照的に、次の属性のクレームは受け付けられます。  

```
<saml2:Attribute Name="Name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
  <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">8J+YkA==</saml2:AttributeValue>
</saml2:Attribute>
```

**メタデータエンドポイントには、有効な Transport Layer Security (TLS) が必要である**  
HTTPS メタデータエンドポイント URL を使用して SAML IdP を作成中に `InvalidParameterException` (例えば「Error retrieving metadata from *<metadata endpoint>*」) が表示される場合、メタデータエンドポイントの SSL が正しくセットアップされていること、および有効な SSL 証明書が関連付けられていることを確認してください。詳細については、「[SSL/TLS 証明書とは何ですか?](https://aws.amazon.com/what-is/ssl-certificate/)」を参照してください。

**メタデータエンドポイントは HTTP または HTTPS の標準 TCP ポート上に存在する必要がある**  
Amazon Cognito は、HTTP の場合は標準 TCP ポート 80、HTTPS の場合は 443 でのみ、SAML プロバイダーのメタデータ URL を受け入れます。セキュリティのベストプラクティスとして、SAML メタデータは、`https://` プレフィックスを付けた TLS 暗号化 URL でホストします。メタデータ URL は、*`http://www.example.com/saml2/metadata.xml`* または *`https://www.example.com/saml2/metadata.xml`* の形式で入力します。Amazon Cognito コンソールは、`https://` プレフィックスが付いたメタデータ URL のみを受け入れます。[CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html) と [UpdateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html) を使用して IdP メタデータを設定することもできます。

**IdP が開始した SAML を持つアプリケーションクライアントは SAML でのみサインインできる**  
アプリケーションクライアントで、IdP が開始した署名をサポートする SAML 2.0 IdP のサポートを有効にすると、そのアプリケーションクライアントに追加できるのは他の SAML 2.0 IdP のみになります。この方法で設定されたアプリケーションクライアントには、ユーザープール内のユーザーディレクトリ*と*すべての非 SAML 外部 ID プロバイダーを追加することはできません。

**ログアウトレスポンスには POST バインディングを使用する必要がある**  
`/saml2/logout` エンドポイントは、`HTTP POST` リクエストとして `LogoutResponse` を受け入れます。ユーザープールは、`HTTP GET` バインディングによるログアウトレスポンスを受け入れません。

**メタデータ署名証明書のローテーション**  
URL でメタデータを提供すると、Amazon Cognito は、SAML メタデータを最大 6 時間キャッシュします。メタデータ署名証明書のローテーションを実行する場合は、元の証明書と新しい証明書の*両方*を少なくとも 6 時間公開するようにメタデータソースを設定します。Amazon Cognito がメタデータ URL からキャッシュを更新すると、各証明書は有効と見なされ、SAML IdP は新しい証明書を使用して SAML アサーションの署名を開始できます。この期間が経過したら、公開したメタデータから元の証明書を削除できます。

## SAML ユーザー名の大文字と小文字の区別
<a name="saml-nameid-case-sensitivity"></a>

フェデレーションユーザーがサインインしようとすると、SAML ID プロバイダー (IdP) はユーザーの SAML アサーションで Amazon Cognito に一意の `NameId` を渡します。Amazon Cognito は、SAML フェデレーティッドユーザーを `NameId` クレームによって識別します。ユーザープールの大文字と小文字の区別の設定にかかわらず、Amazon Cognito では、大文字と小文字を区別する一意の `NameId` クレームを渡すときに、SAML IdP の既存フェデレーションユーザーを認識します。`email` のような属性を `NameId` にマッピングし、ユーザーが E メールアドレスを変更すると、アプリケーションにサインインできません。

変更されない値を持つ IdP 属性から SAML アサーションに `NameId` をマッピングします。

例えば、Carlos は、`Carlos@example.com` の `NameId` 値を渡した Active Directory フェデレーションサービス (ADFS) SAML アサーションからの大文字と小文字を区別しないユーザープールにユーザープロファイルを持っているとします。次回 Carlos がサインインしようとすると、ADFS IdP は `carlos@example.com` の `NameId` 値を渡します。`NameId` は大文字と小文字が完全に一致する必要があるため、サインインは成功しません。

`NameID` を変更した後、ユーザーがログインできない場合は、ユーザープールからそのユーザーのプロファイルを削除してください。Amazon Cognito は、次回サインインしたときに新しいユーザープロファイルを作成します。

**Topics**
+ [IdP 設定のクイックリファレンス](#cognito-user-pools-saml-idp-reference)
+ [Amazon Cognito ユーザープールの SAML IdP について知っておくべきこと](cognito-user-pools-saml-idp-things-to-know.md)
+ [SAML ユーザー名の大文字と小文字の区別](#saml-nameid-case-sensitivity)
+ [サードパーティー SAML ID プロバイダーの設定](cognito-user-pools-integrating-3rd-party-saml-providers.md)
+ [ユーザープールでの SAML ID プロバイダーの追加と管理](cognito-user-pools-managing-saml-idp.md)
+ [Amazon Cognito ユーザープールでの SAML セッション開始](cognito-user-pools-SAML-session-initiation.md)
+ [シングルサインアウトで SAML ユーザーをサインアウトする](cognito-user-pools-saml-idp-sign-out.md)
+ [SAML 署名と暗号化](cognito-user-pools-SAML-signing-encryption.md)
+ [SAML ID プロバイダーの名前と識別子](cognito-user-pools-managing-saml-idp-naming.md)

# サードパーティー SAML ID プロバイダーの設定
<a name="cognito-user-pools-integrating-3rd-party-saml-providers"></a>

SAML ID プロバイダー (IdP) をユーザープールに追加する場合は、IdP の管理インターフェイスで設定を更新する必要があります。このセクションでは、IdP に提供する必要がある値をフォーマットする方法について説明します。また、IdP とそのユーザープールへの SAML クレームを識別する静的なまたはアクティブな URL メタデータドキュメントを取得する方法についても説明します。

Amazon Cognito ユーザープールのフェデレーションと連携するようにサードパーティー SAML 2.0 ID プロバイダー (IdP) ソリューションを設定するには、次のアサーションコンシューマーサービス (ACS) の URL にリダイレクトするように SAML IdP を設定する必要があります: `https://mydomain.auth.us-east-1.amazoncognito.com/saml2/idpresponse`。ユーザープールに Amazon Cognito ドメインがある場合は、[Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)のユーザープールの **[ドメイン]** メニューでユーザープールドメインのパスを見つけることができます。

一部の SAML IdP では、オーディエンス URI または SP エンティティ ID とも呼ばれる `urn` を `urn:amazon:cognito:sp:us-east-1_EXAMPLE`　の形式で指定する必要があります。ユーザープール ID は、Amazon Cognito コンソールの **[ユーザープールの概要]** で確認できます。

また、SAML IdP を設定して、ユーザープールの*必須属性*として指定した属性の値を指定する必要もあります。通常、`email` はユーザープールに必要な属性です。この場合、SAML IdP は、SAML アサーションに何らかの形式の `email` クレームを指定し、そのクレームをそのプロバイダーの属性にマッピングする必要があります。

サードパーティーの SAML 2.0 IdP ソリューションについての以下の設定情報は、Amazon Cognito ユーザープールでフェデレーションのセットアップを開始するのに適しています。最新情報については、プロバイダーのドキュメントを直接参照してください。

SAML リクエストに署名するには、ユーザープール署名証明書によって署名されたリクエストを信頼するように IdP を設定する必要があります。暗号化された SAML レスポンスを受け入れるには、ユーザープールへの*すべての* SAML レスポンスを暗号化するように IdP を設定する必要があります。プロバイダーは、これらの機能の設定に関するドキュメントを用意します。Microsoft の例については、「[Microsoft Entra の SAML トークン暗号化を構成する](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/howto-saml-token-encryption)」を参照してください。

**注記**  
Amazon Cognito では、ID プロバイダーのメタデータドキュメントのみが必要です。プロバイダーによっては、IAM または AWS IAM アイデンティティセンターとの SAML 2.0 フェデレーション用にカスタマイズした設定情報を提供している場合もあります。Amazon Cognito 統合を設定する方法については、メタデータに関するドキュメントを取得する一般的な手順を確認し、ユーザープールで残りの設定を管理してください。


| ソリューション | 詳細情報 | 
| --- | --- | 
| Microsoft Entra ID | [フェデレーションメタデータ](https://learn.microsoft.com/en-us/entra/identity-platform/federation-metadata) | 
| Okta | [SAML アプリケーション統合の IdP メタデータと SAML 署名証明書をダウンロードする方法](https://support.okta.com/help/s/article/Location-to-download-Okta-IDP-XML-metadata-for-a-SAML-app-in-the-new-Admin-User-Interface) | 
| Auth0 | [Auth0 を SAML ID プロバイダーとして設定する](https://auth0.com/docs/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider) | 
| Ping Identity (PingFederate) | [PingFederate からの SAML メタデータのエクスポート](https://docs.pingidentity.com/integrations/contentful/configuring_single_sign-on/pf_contentful_integration_exporting_saml_metadata_from_pf.html) | 
| JumpCloud | [SAML 設定に関する注意事項](https://jumpcloud.com/support/saml-configuration-notes) | 
| SecureAuth | [SAML アプリケーション統合](https://docs.secureauth.com/2104/en/saml-application-integration.html) | 

# ユーザープールでの SAML ID プロバイダーの追加と管理
<a name="cognito-user-pools-managing-saml-idp"></a>

Amazon Cognito を操作するように ID プロバイダーを設定したら、ユーザープールとアプリケーションクライアントに追加できます。次の手順は、Amazon Cognito ユーザープールで SAML プロバイダーの作成、変更、削除を行う方法を示しています。

------
#### [ AWS マネジメントコンソール ]

を使用して、SAML ID プロバイダー (IdPs AWS マネジメントコンソール を作成および削除できます。

SAML IdP を作成する前に、サードパーティー IdP から取得した SAML メタデータドキュメントが必要です。必要な SAML メタデータドキュメントの取得または生成方法については、「[サードパーティー SAML ID プロバイダーの設定](cognito-user-pools-integrating-3rd-party-saml-providers.md)」を参照してください。

**ユーザープールに SAML 2.0 IdP を設定するには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択し、**[ID プロバイダーを追加]** を選択します。

1. **[SAML]** IdP を選択します。

1. **プロバイダー名**を入力します。このわかりやすい名前を、`identity_provider` リクエストパラメータで [認可エンドポイント](authorization-endpoint.md) に渡すことができます。

1. カンマで区切られた **[Identifiers]** (識別子) を入力します。識別子は Amazon Cognito に、ユーザーがサインインしたときに入力したメールアドレスを確認し、ドメインに対応するプロバイダーに誘導する必要があることを伝えます。

1. ユーザーがログアウトしたときに、Amazon Cognito が署名されたサインアウト要求をプロバイダーに送信するためには、**[Add sign-out flow]** (サインアウトフローの追加) を選択します。マネージドログインの設定時に作成した `https://mydomain.auth.us-east-1.amazoncognito.com/saml2/logout` エンドポイントにサインアウトレスポンスを送信するよう、SAML 2.0 IdP を設定する必要があります。`saml2/logout` エンドポイントでは、ポストバインディングを使用します。
**注記**  
このオプションを選択し、SAML IdP が署名付きログアウトリクエストを期待する場合は、SAML IdP に対して、ユーザープールからの署名証明書を提供する必要もあります。  
SAML IdP は署名されたログアウトリクエストを処理し、Amazon Cognito セッションからユーザーをサインアウトさせます。

1. **[IdP が開始した SAML サインイン]** 設定を選択します。セキュリティのベストプラクティスとして、**[SP が開始した SAML アサーションのみを受け入れる]** を選択します。未承諾の SAML サインインセッションを安全に受け入れる環境を準備している場合は、**[SP が開始した/IdP が開始した SAML アサーションを受け入れる]** を選択します。詳細については、「[Amazon Cognito ユーザープールでの SAML セッション開始](cognito-user-pools-SAML-session-initiation.md)」を参照してください。

1. **[Metadata document source]** (メタデータドキュメントソース) を選択します。IdP がパブリック URL で SAML メタデータを提供する場合は、**[Metadata document URL]** (メタデータドキュメント URL) を選択してそのパブリック URL を入力できます。それ以外の場合は、**[Upload metadata document]** (メタデータドキュメントをアップロード) を選択し、プロバイダーから以前ダウンロードしたメタデータファイルを選択します。
**注記**  
プロバイダーにパブリックエンドポイントがある場合は、ファイルをアップロードするのではなく、メタデータドキュメントの URL を入力することをお勧めします。Amazon Cognito は、メタデータ URL からのメタデータを自動的に更新します。通常、メタデータの更新は 6 時間ごとまたはメタデータの有効期限が切れる前のいずれか早いタイミングで発生します。

1. **[SAML プロバイダーとユーザープール間で属性をマッピング]** をクリックして、SAML プロバイダーの属性をユーザープールのユーザープロファイルにマッピングします。ユーザープールの必須属性を属性マップに含めます。

   例えば、**[User pool attribute]** (ユーザープール属性) `email` を選択する場合、IdP からの SAML アサーションに表示される SAML 属性名を入力します。IdP がサンプル SAML アサーションを提供している場合は、これらのサンプルアサーションを使用して名前を見つけやすいかもしれません。`email` などの単純な名前を使用している IdP もあれば、次のような名前を使用している IdP もあります。

   ```
   http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
   ```

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

------
#### [ API/CLI ]

SAML ID プロバイダー (IdP) を作成して管理するには、以下のコマンドを使用します。

**IdP を作成し、メタデータドキュメントをアップロードする**
+ AWS CLI: `aws cognito-idp create-identity-provider`

  メタデータファイルの例: `aws cognito-idp create-identity-provider --user-pool-id us-east-1_EXAMPLE --provider-name=SAML_provider_1 --provider-type SAML --provider-details file:///details.json --attribute-mapping email=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`

  ここでは `details.json` に以下が含まれます。

  ```
  "ProviderDetails": { 
        "MetadataFile": "<SAML metadata XML>",
        "IDPSignout" : "true",
        "RequestSigningAlgorithm" : "rsa-sha256",
        "EncryptedResponses" : "true",
        "IDPInit" : "true"
  }
  ```
**注記**  
*<SAML メタデータ XML>* に文字 `"` のインスタンスが含まれている場合は、エスケープ文字の `\` を追加して、次のようにする必要があります: `\"`。

  メタデータ URL の例: `aws cognito-idp create-identity-provider --user-pool-id us-east-1_EXAMPLE --provider-name=SAML_provider_1 --provider-type SAML --provider-details MetadataURL=https://myidp.example.com/sso/saml/metadata --attribute-mapping email=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`
+ AWS API: [CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html)

**IdP の新規メタデータドキュメントをアップロードする**
+ AWS CLI: `aws cognito-idp update-identity-provider`

  メタデータファイルの例: `aws cognito-idp update-identity-provider --user-pool-id us-east-1_EXAMPLE --provider-name=SAML_provider_1 --provider-details file:///details.json --attribute-mapping email=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`

  ここでは `details.json` に以下が含まれます。

  ```
  "ProviderDetails": { 
        "MetadataFile": "<SAML metadata XML>",
        "IDPSignout" : "true",
        "RequestSigningAlgorithm" : "rsa-sha256",
        "EncryptedResponses" : "true",
        "IDPInit" : "true"
  }
  ```
**注記**  
*<SAML メタデータ XML>* に文字 `"` のインスタンスが含まれている場合は、エスケープ文字の `\` を追加して、次のようにする必要があります: `\"`。

  メタデータ URL の例: `aws cognito-idp update-identity-provider --user-pool-id us-east-1_EXAMPLE --provider-name=SAML_provider_1 --provider-details MetadataURL=https://myidp.example.com/sso/saml/metadata --attribute-mapping email=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`
+ AWS API: [UpdateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html)

**固有の IdP に関する情報を取得するには**
+ AWS CLI: `aws cognito-idp describe-identity-provider`

  `aws cognito-idp describe-identity-provider --user-pool-id us-east-1_EXAMPLE --provider-name=SAML_provider_1`
+ AWS API: [DescribeIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeIdentityProvider.html)

**すべての IdP に関する情報を一覧表示するには**
+ AWS CLI: `aws cognito-idp list-identity-providers`

  例: `aws cognito-idp list-identity-providers --user-pool-id us-east-1_EXAMPLE --max-results 3`
+ AWS API: [ListIdentityProviders](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListIdentityProviders.html)

**IdP を削除する**
+ AWS CLI: `aws cognito-idp delete-identity-provider`

  `aws cognito-idp delete-identity-provider --user-pool-id us-east-1_EXAMPLE --provider-name=SAML_provider_1`
+ AWS API: [DeleteIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteIdentityProvider.html)

------

**ユーザープールを証明書利用者として追加するために SAML IdP をセットアップする**
+ ユーザープールのサービスプロバイダー URN は `urn:amazon:cognito:sp:us-east-1_EXAMPLE` です。Amazon Cognito には、SAML レスポンスでこの URN に一致するオーディエンス制限値が必要です。お客様の IdP は、次の POST バインディングエンドポイントを IdP-to-SP 応答メッセージに使用します。

  ```
  https://mydomain.auth.us-east-1.amazoncognito.com/saml2/idpresponse
  ```
+ SAML IdP によって、SAML アサーションの `NameID` およびユーザープール必須属性が入力されている必要があります。`NameID` は、ユーザープールの SAML フェデレーションユーザーを一意に識別するために使用されます。IdP は、各ユーザーの SAML 名 ID を、大文字と小文字を区別する一貫した形式で渡す必要があります。ユーザー名 ID の値にバリエーションがあると、新しいユーザープロファイルが作成されます。

**SAML 2.0 IDP にデジタル署名用証明書を提供するには**
+ IdP が SAML ログアウトリクエストの検証に使用できるパブリックキーのコピーを Amazon Cognito からダウンロードするには、ユーザープールの **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択して IdP を選択し、**[署名用証明書を表示]** で **[.crt としてダウンロード]** を選択します。

Amazon Cognito コンソールを使用して、ユーザープールで設定した SAML プロバイダーを削除できます。

**SAML プロバイダーを削除する**

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

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

1. **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択します。

1. 削除する SAML IdP の横のラジオボタンを選択します。

1. **[Delete identity provider]** (ID プロバイダーの削除) のプロンプトが表示されたら、SAML プロバイダー名を入力して削除を確認し、**[Delete]** (削除) を選択します。

# Amazon Cognito ユーザープールでの SAML セッション開始
<a name="cognito-user-pools-SAML-session-initiation"></a>

Amazon Cognito は、サービスプロバイダーが開始した (SP が開始した) シングルサインオン (SSO) と IdP が開始した SSO をサポートしています。セキュリティのベストプラクティスとして、SP が開始した SSO をユーザープールに実装します。[SAML V2.0 技術概要](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html#5.1.2.SP-Initiated%20SSO:%20%20Redirect/POST%20Bindings|outline)のセクション 5.1.2 では、SP で開始される SSO について説明します。Amazon Cognito は、アプリケーションの ID プロバイダー (IdP) です。アプリケーションは、認証されたユーザーのトークンを取得するサービスプロバイダー (SP) です。ただし、サードパーティー IdP を使用してユーザーを認証する場合、Amazon Cognito は SP です。SAML 2.0 ユーザーが、SP が開始したフローで認証する場合、常に Amazon Cognito にリクエストを行い、認証のために IdP にリダイレクトする必要があります。

一部のエンタープライズユースケースでは、内部アプリケーションへのアクセスは Enterprise IdP がホストするダッシュボードのブックマークから始まります。ユーザーがブックマークを選択すると、IdP は SAML 応答を生成して SP に送信し、アプリケーションでユーザーを認証します。

IdP が開始した SSO をサポートするように、ユーザープールで SAML IdP を設定できます。IdP が開始した認証をサポートする場合、Amazon Cognito は SAML リクエストで認証を開始しないため、受信した SAML レスポンスを要請したことを検証できません。SP が開始した SSO では、Amazon Cognito は、元のリクエストに対して SAML レスポンスを検証する状態パラメータを設定します。SP が開始したサインインを使用すると、クロスサイトリクエストフォージェリ (CSRF) から保護することもできます。

**Topics**
+ [SP が開始した SAML サインインを実装する](#cognito-user-pools-saml-idp-authentication)
+ [IdP が開始した SAML サインインを実装する](#cognito-user-pools-SAML-session-initiation-idp-initiation)

## SP が開始した SAML サインインを実装する
<a name="cognito-user-pools-saml-idp-authentication"></a>

ベストプラクティスとして、ユーザープールに、サービスプロバイダーが開始した (SP が開始した) サインインを実装します。Amazon Cognito はユーザーのセッションを開始し、IdP にリダイレクトします。この方法を使用すると、サインインリクエストを提示するユーザーの制御が最大になります。特定の条件下で、IdP が開始したサインインを許可することもできます。

以下のプロセスは、ユーザーが SAML プロバイダーを介してユーザープールへの SP が開始したサインインを完了する方法を示しています。

![\[Amazon Cognito の SP が開始した SAML サインインの認証フロー図。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/scenario-authentication-saml-stepbystep.png)


1. ユーザーはサインインページで E メールアドレスを入力します。ユーザーを IdP にリダイレクトすることを決めるには、カスタム構築したアプリケーションで E メールアドレスを収集するか、ウェブビューでマネージドログインを呼び出すことができます。

   IdP を一覧表示するか、E メールアドレスの入力を求めて SAML IdP の識別子と照合するように、マネージドログインページを設定できます。E メールアドレスの入力を求めるには、マネージドログインのブランディングスタイルを編集し、**[基盤]** で **[認証動作]** を見つけ、**[プロバイダーの表示]** で **[表示スタイル]** を **[ドメイン検索入力]** に設定します。

1. アプリケーションは、ユーザープールリダイレクトエンドポイントを呼び出し、アプリケーションに対応するクライアント ID と、ユーザーに対応する IdP ID を持つセッションをリクエストします。

1. Amazon Cognito は、`AuthnRequest` 要素内の、[オプションで署名された](cognito-user-pools-SAML-signing-encryption.md#cognito-user-pools-SAML-signing.title)、SAML リクエストを使用して、ユーザーを IdP にリダイレクトします。

1. IdP は、インタラクティブに、またはブラウザ Cookie で記憶されたセッションを使用して、ユーザーを認証します。

1. IdP は、POST ペイロードで、[オプションで暗号化された](cognito-user-pools-SAML-signing-encryption.md#cognito-user-pools-SAML-signing-encryption.title) SAML アサーションを使用して、ユーザーをユーザープールの SAML レスポンスエンドポイントにリダイレクトします。
**注記**  
Amazon Cognito は、5 分以内にレスポンスを受信しないセッションをキャンセルし、ユーザーをマネージドログインにリダイレクトします。ユーザーにこの結果が生じると、`Something went wrong` エラーメッセージを受け取ります。

1. SAML アサーションが検証され、レスポンスのクレームから[ユーザー属性がマッピング](cognito-user-pools-specifying-attribute-mapping.md#cognito-user-pools-specifying-attribute-mapping.title)されると、Amazon Cognito がユーザープールのユーザープロファイルを内部で作成または更新します。通常、ユーザープールはユーザーのブラウザセッションに認可コードを返します。

1. ユーザーは、認可コードをアプリケーションに提示します。アプリケーションはコードを JSON ウェブトークン (JWT) と交換します。

1. アプリケーションは、ユーザーの ID トークンを認証として受け入れて処理し、アクセストークンを使用してリソースへの認可されたリクエストを生成し、更新トークンを保存します。

ユーザーが認証して、認可コード付与を受け取ると、ユーザープールは ID、アクセス、更新トークンを返します。ID トークンは、OIDC ベースの ID 管理用の認証オブジェクトです。アクセストークンは、[OAuth 2.0](https://oauth.net/2/) スコープを持つ認可オブジェクトです。更新トークンは、ユーザーの現在のトークンの有効期限が切れたときに新しい ID トークンとアクセストークンを生成するオブジェクトです。ユーザープールアプリケーションクライアントでユーザーのトークンの期間を設定できます。

更新トークンの期間を選択することもできます。ユーザーの更新トークンの有効期限が切れたら、再度サインインする必要があります。SAML IdP を介して認証された場合、ユーザーのセッション期間は、IdP とのセッションの有効期限ではなく、トークンの有効期限によって設定されます。アプリケーションは、各ユーザーの更新トークンを保存し、有効期限が切れたらセッションを更新する必要があります。マネージドログインは、1 時間有効なブラウザ Cookie でユーザーセッションを維持します。

## IdP が開始した SAML サインインを実装する
<a name="cognito-user-pools-SAML-session-initiation-idp-initiation"></a>

IdP が開始した SAML 2.0 サインイン用に ID プロバイダーを設定すると、[認可エンドポイント](authorization-endpoint.md) でセッションを開始することなく、ユーザープールドメインの `saml2/idpresponse` エンドポイントに SAML アサーションを提示できます。この設定を持つユーザープールは、リクエストされたアプリケーションクライアントがサポートするユーザープールの外部 ID プロバイダーから、IdP が開始した SAML アサーションを受け入れます。

![\[Amazon Cognito の IdP が開始した SAML サインインの認証フロー図。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/scenario-authentication-saml-idpinit.png)


1. ユーザーがアプリケーションで SAML サインインをリクエストします。

1. アプリケーションは、ブラウザを起動するか、SAML プロバイダーのサインインページにユーザーをリダイレクトします。

1. IdP は、インタラクティブに、またはブラウザ Cookie で記憶されたセッションを使用して、ユーザーを認証します。

1. IdP は、POST 本文の SAML アサーションまたはレスポンスを使用して、ユーザーをアプリケーションにリダイレクトします。

1. アプリケーションは、ユーザープールの `saml2/idpresponse` エンドポイントへのリクエストの POST 本文に SAML アサーションを追加します。

1. Amazon Cognito は、ユーザーに認証コードを発行します。

1. ユーザーは、認可コードをアプリケーションに提示します。アプリケーションはコードを JSON ウェブトークン (JWT) と交換します。

1. アプリケーションは、ユーザーの ID トークンを認証として受け入れて処理し、アクセストークンを使用してリソースへの認可されたリクエストを生成し、更新トークンを保存します。

次の手順では、IdP が開始した SAML 2.0 プロバイダーを使用した設定とサインインの全体的なプロセスについて説明します。

1. ユーザープールとアプリケーションクライアントを作成または指定します。

1. ユーザープールで SAML 2.0 IdP を作成します。

1. IdP の開始をサポートするように IdP を設定します。IdP が開始した SAML では、他の SSO プロバイダーには適用されないセキュリティ上の考慮事項が導入されています。このため、IdP が開始したサインインで SAML プロバイダーを使用するアプリケーションクライアントに、ユーザープール自体を含む非 SAML IdP を追加することはできません。

1. IdP が開始した SAML プロバイダーを、ユーザープール内のアプリケーションクライアントに関連付けます。

1. SAML IdP のサインインページにユーザーを誘導し、SAML アサーションを取得します。

1. SAML アサーションを使用して、ユーザーをユーザープール `saml2/idpresponse` エンドポイントに誘導します。

1. JSON ウェブトークン (JWT) を受け取ります。

ユーザープールで未承諾の SAML アサーションを受け入れるには、アプリケーションセキュリティへの影響を考慮する必要があります。リクエストスプーフィングと CSRF の試行は、IdP が開始したリクエストを受け入れるときに行われる可能性があります。ユーザープールは IdP が開始したサインインセッションを検証できませんが、Amazon Cognito はリクエストパラメータと SAML アサーションを検証します。

さらに、SAML アサーションに `InResponseTo` クレームが含まれておらず、過去 6 分以内に発行されている必要があります。

IdP が開始した SAML を使用してリクエストを `/saml2/idpresponse` に送信する必要があります。SP が開始した認可リクエストおよびマネージドログインの認可リクエストの場合、リクエストされたアプリケーションクライアント、スコープ、リダイレクト URI、その他の詳細を識別するパラメータを、`HTTP GET` リクエストのクエリ文字列パラメータとして指定する必要があります。ただし、IdP が開始した SAML アサーションの場合、リクエストの詳細は、`HTTP POST` リクエスト本文の `RelayState` パラメータとしてフォーマットする必要があります。また、リクエスト本文には、SAML アサーションを `SAMLResponse` パラメータとして含める必要もあります。

次に示すのは、IdP が開始した SAML プロバイダーのリクエストとレスポンスの例です。

```
POST /saml2/idpresponse HTTP/1.1
User-Agent: USER_AGENT
Accept: */*
Host: example.auth.us-east-1.amazoncognito.com
Content-Type: application/x-www-form-urlencoded

SAMLResponse=[Base64-encoded SAML assertion]&RelayState=identity_provider%3DMySAMLIdP%26client_id%3D1example23456789%26redirect_uri%3Dhttps%3A%2F%2Fwww.example.com%26response_type%3Dcode%26scope%3Demail%2Bopenid%2Bphone

HTTP/1.1 302 Found
Date: Wed, 06 Dec 2023 00:15:29 GMT
Content-Length: 0
x-amz-cognito-request-id: 8aba6eb5-fb54-4bc6-9368-c3878434f0fb
Location: https://www.example.com?code=[Authorization code]
```

------
#### [ AWS マネジメントコンソール ]

**IdP が開始した SAML の IdP を設定するには**

1. [ユーザープール](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)、[アプリケーションクライアント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-configuring-app-integration.html)、および SAML ID プロバイダーを作成します。

1. 関連付けられている場合、すべてのソーシャル ID プロバイダーと OIDC ID プロバイダーについてアプリケーションクライアントから関連付けを解除します。

1. ユーザープールの **[ソーシャルプロバイダーと外部プロバイダー]** メニューに移動します。

1. SAML プロバイダーを編集または追加します。

1. **[IdP が開始した SAML サインイン]** で、**[SP が開始した/IdP が開始した SAML アサーションを受け入れる]** を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ API/CLI ]

**IdP が開始した SAML の IdP を設定するには**

[CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html) API リクエストまたは [UpdateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html) API リクエストの `IDPInit` パラメータを使用して、IdP が開始した SAML を設定します。以下は、IdP が開始した SAML をサポートする IdP の `ProviderDetails` の例です。

```
"ProviderDetails": { 
      "MetadataURL" : "https://myidp.example.com/saml/metadata",
      "IDPSignout" : "true",
      "RequestSigningAlgorithm" : "rsa-sha256",
      "EncryptedResponses" : "true",
      "IDPInit" : "true"
}
```

------

# シングルサインアウトで SAML ユーザーをサインアウトする
<a name="cognito-user-pools-saml-idp-sign-out"></a>

Amazon Cognito は SAML 2.0 [シングルログアウト](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html#5.3.Single%20Logout%20Profile|outline) (SLO) をサポートしています。SLO を使用すると、アプリケーションはユーザープールからサインアウトするときに、SAML ID プロバイダー (IdP) からユーザーをサインアウトできます。これにより、ユーザーがアプリケーションに再度サインインする場合は、SAML IdP で認証する必要があります。そうしない場合は、認証情報を提供する要件なくアプリケーションに渡す、IdP またはユーザープールブラウザの Cookie が設置される可能性があります。

**サインアウトフロー**をサポートするように SAML IdP を設定すると、Amazon Cognito は、署名付き SAML ログアウトリクエストを使用してユーザーを IdP にリダイレクトします。Amazon Cognito は、IdP メタデータの `SingleLogoutService` URL からリダイレクト場所を決定します。Amazon Cognito は、ユーザープール署名証明書を使用してサインアウトリクエストに署名します。

![\[Amazon Cognito SAML サインアウトの認証フロー図。ユーザーはサインアウトをリクエストし、Amazon Cognito は SAML サインアウトリクエストを使用してプロバイダーにリダイレクトします。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/scenario-authentication-saml-sign-out.png)


SAML セッションを持つユーザーをユーザープール `/logout` エンドポイントに誘導すると、Amazon Cognito は、次のリクエストで、IdP メタデータで指定された SLO エンドポイントに SAML ユーザーをリダイレクトします。

```
https://[SingleLogoutService endpoint]?
SAMLRequest=[encoded SAML request]&
RelayState=[RelayState]&
SigAlg=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256&
Signature=[User pool RSA signature]
```

その後、ユーザーは IdP から `LogoutResponse` を使用して `saml2/logout` エンドポイントに戻ります。IdP は `HTTP POST` リクエストで `LogoutResponse` を送信する必要があります。その後、Amazon Cognito は、最初のサインアウトリクエストからリダイレクト先にリダイレクトします。

SAML プロバイダーは、複数の `AuthnStatement` を含む `LogoutResponse` を送信する場合があります。このタイプのレスポンスの最初の `AuthnStatement` の `sessionIndex` は、最初にユーザーを認証した SAML レスポンスの `sessionIndex` と一致する必要があります。`sessionIndex` が他の `AuthnStatement` にある場合、Amazon Cognito はセッションを認識せず、ユーザーはサインアウトされません。

------
#### [ AWS マネジメントコンソール ]

**SAML サインアウトを設定するには**

1. [ユーザープール](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)、[アプリケーションクライアント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-configuring-app-integration.html)、および SAML IdP を作成します。

1. SAML ID プロバイダーを作成または編集するときは、**[ID プロバイダーに関する情報]** で、**[サインアウトフローを追加]** というタイトルのチェックボックスをオンにします。

1. ユーザープールの **[ソーシャルプロバイダーと外部プロバイダー]** メニューで IdP を選択し、**[署名証明書]** を見つけます。

1. **[.crt としてダウンロード]** を選択します。

1. SAML シングルログアウトをサポートし、署名をサポートするように SAML プロバイダーを設定し、ユーザープール署名証明書をアップロードします。IdP は、ユーザープールドメインの `/saml2/logout` にリダイレクトする必要があります。

------
#### [ API/CLI ]

**SAML サインアウトを設定するには**

[CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html) API リクエストまたは [UpdateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html) API リクエストの `IDPSignout` パラメータを使用してシングルログアウトを設定します。以下は、SAML シングルログアウトをサポートする IdP の `ProviderDetails` の例です。

```
"ProviderDetails": { 
      "MetadataURL" : "https://myidp.example.com/saml/metadata",
      "IDPSignout" : "true",,
      "RequestSigningAlgorithm" : "rsa-sha256",
      "EncryptedResponses" : "true",
      "IDPInit" : "true"
}
```

------

# SAML 署名と暗号化
<a name="cognito-user-pools-SAML-signing-encryption"></a>

SAML 2.0 サインインは、認証フローのリクエストとレスポンスのベアラーとしてアプリケーションのユーザーを中心に構築されています。転送中にこれらの SAML ドキュメントについてユーザーによる読み取りや変更ができないようにしておきたい場合があります。これを実現するには、ユーザープールの SAML ID プロバイダー (IdP) に SAML 署名と暗号化を追加します。SAML 署名を使用すると、ユーザープールは SAML のサインインリクエストとサインアウトリクエストに署名を追加します。ユーザープールのパブリックキーを使用すると、IdP は、変更されていない SAML リクエストを受信していることを検証できます。次に、IdP が応答し、ユーザーのブラウザセッションに SAML アサーションを渡すと、IdP はそのレスポンスを暗号化して、ユーザーが独自の属性と権限を検査できないようにします。

SAML 署名と暗号化では、ユーザープール SAML オペレーション中のすべての暗号化オペレーションは、Amazon Cognito が生成するユーザープール提供のキーを使用して署名と暗号文を生成する必要があります。現在、外部キーを使用してリクエストに署名することや、暗号化されたアサーションを受け入れるようにユーザープールを設定することはできなくなっています。

**注記**  
ユーザープール証明書は 10 年間有効です。年に 1 回、Amazon Cognito はユーザープールの新しい署名証明書と暗号化証明書を生成します。Amazon Cognito は、署名証明書をリクエストするときに最新の証明書を返し、最新の署名証明書を使用してリクエストに署名します。IdP は、有効期限が切れていないユーザープール暗号化証明書を使用して SAML アサーションを暗号化できます。以前の証明書は、その有効期間の全期間にわたって引き続き有効であり、パブリックキーは、新旧の証明書で変更ありません。ベストプラクティスとしては、プロバイダー設定で証明書を毎年更新します。

**Topics**
+ [IdP からの暗号化された SAML レスポンスの受け入れ](#cognito-user-pools-SAML-encryption)
+ [SAML リクエストへの署名](#cognito-user-pools-SAML-signing)

## IdP からの暗号化された SAML レスポンスの受け入れ
<a name="cognito-user-pools-SAML-encryption"></a>

Amazon Cognito と IdP は、ユーザーによるサインインとサインアウトの際に、SAML レスポンスで機密性を確立できます。Amazon Cognito は、パブリック/プライベート RSA キーペアと証明書を、ユーザープールで設定した各外部 SAML プロバイダーに割り当てます。ユーザープール SAML プロバイダーのレスポンス暗号化を有効にする場合は、暗号化された SAML レスポンスをサポートする IdP に証明書をアップロードする必要があります。提供されたキーで IdP がすべての SAML アサーションの暗号化を開始する前は、SAML IdP へのユーザープール接続は機能しません。

以下は、暗号化された SAML サインインのフローの概要です。

1. ユーザーがサインインを開始し、SAML IdP を選択します。

1. ユーザープール [認可エンドポイント](authorization-endpoint.md) は、SAML サインインリクエストを使用してユーザーを SAML IdP にリダイレクトします。ユーザープールは、オプションとして、IdP による整合性の検証を可能にする署名に、このリクエストを添付できます。SAML リクエストに署名する場合は、署名証明書のパブリックキーを使用してユーザープールが署名したリクエストを受け入れるように IdP を設定する必要があります。

1. SAML IdP はユーザーに署名し、SAML レスポンスを生成します。IdP はパブリックキーでレスポンスを暗号化し、ユーザーをユーザープール `/saml2/idpresponse` エンドポイントにリダイレクトします。IdP は、SAML 2.0 仕様で定義されているようにレスポンスを暗号化する必要があります。詳細については、「[Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)」の「`Element <EncryptedAssertion>`」を参照してください。

1. ユーザープールは、SAML レスポンスの暗号文をプライベートキーで復号し、ユーザーに署名します。

**重要**  
ユーザープールで SAML IdP のレスポンス暗号化を有効にする場合、IdP は、プロバイダーに固有のパブリックキーを使用してすべてのレスポンスを暗号化する必要があります。Amazon Cognito は、暗号化をサポートするように設定した SAML 外部 IdP から、暗号化されていない SAML レスポンスを受け入れません。

ユーザープール内の外部 SAML IdP はレスポンス暗号化をサポートでき、各 IdP は独自のキーペアを受け取ります。

------
#### [ AWS マネジメントコンソール ]

**SAML レスポンスの暗号化を設定するには**

1. [ユーザープール](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)、[アプリケーションクライアント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-configuring-app-integration.html)、および SAML IdP を作成します。

1. SAML ID プロバイダーの作成または編集を行うときは、**[リクエストへの署名とレスポンスの暗号化]** で、**[暗号化された SAML アサーションをこのプロバイダーに要求]** というタイトルのチェックボックスをオンにします。

1. ユーザープールの **[ソーシャルプロバイダーと外部プロバイダー]** メニューで SAML IdP を選択し、**[暗号化証明書を表示]** を選択します。

1. **[.crt としてダウンロード]** を選択し、ダウンロードしたファイルを SAML IdP に提供します。証明書内のキーを使用して SAML レスポンスを暗号化するように SAML IdP を設定します。

------
#### [ API/CLI ]

**SAML レスポンスの暗号化を設定するには**

[CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html) API リクエストまたは [UpdateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html) API リクエストの `EncryptedResponses` パラメータを使用してレスポンス暗号化を設定します。以下は、リクエスト署名をサポートする IdP の `ProviderDetails` の例です。

```
"ProviderDetails": { 
      "MetadataURL" : "https://myidp.example.com/saml/metadata",
      "IDPSignout" : "true",
      "RequestSigningAlgorithm" : "rsa-sha256",
      "EncryptedResponses" : "true",
      "IDPInit" : "true"
}
```

ユーザープールから暗号化証明書を取得するには、[DescribeIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeIdentityProvider.html) API リクエストを行い、レスポンスパラメータ `ProviderDetails` の `ActiveEncryptionCertificate` 値を取得します。この証明書を保存し、ユーザープールからのサインインリクエストの暗号化証明書として、この証明書を IdP に提供します。

------

## SAML リクエストへの署名
<a name="cognito-user-pools-SAML-signing"></a>

IdP への SAML 2.0 リクエストの整合性を証明できる機能は、Amazon Cognito の SP が開始した SAML サインインのセキュリティ上のメリットです。ドメインを持つ各ユーザープールは、ユーザープール X.509 署名証明書を受け取ります。この証明書内のパブリックキーを使用すると、ユーザープールは、ユーザーが SAML IdP を選択したときにユーザープールが生成する*サインアウトリクエスト*に暗号化署名を適用します。オプションで、SAML *サインインリクエスト*に署名するようにアプリケーションクライアントを設定できます。SAML リクエストに署名すると、IdP は、リクエストの XML メタデータの署名が、指定したユーザープール証明書のパブリックキーと一致することを確認できます。

------
#### [ AWS マネジメントコンソール ]

**SAML リクエストの署名を設定するには**

1. [ユーザープール](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)、[アプリケーションクライアント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-configuring-app-integration.html)、および SAML IdP を作成します。

1. SAML ID プロバイダーの作成または編集を行うときは、**[リクエストへの署名とレスポンスの暗号化]** で、**[このプロバイダーへの SAML リクエストに署名する]** というタイトルのチェックボックスをオンにします。

1. ユーザープールの **[ソーシャルプロバイダーと外部プロバイダー]** メニューで、**[署名証明書を表示]** を選択します。

1. **[.crt としてダウンロード]** を選択し、ダウンロードしたファイルを SAML IdP に提供します。受信 SAML リクエストの署名を検証するように SAML IdP を設定します。

------
#### [ API/CLI ]

**SAML リクエストの署名を設定するには**

[CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html) API リクエストまたは [UpdateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html) API リクエストの `RequestSigningAlgorithm` パラメータを使用してリクエスト署名を設定します。以下は、リクエスト署名をサポートする IdP の `ProviderDetails` の例です。

```
"ProviderDetails": { 
      "MetadataURL" : "https://myidp.example.com/saml/metadata",
      "IDPSignout" : "true",
      "RequestSigningAlgorithm" : "rsa-sha256",
      "EncryptedResponses" : "true",
      "IDPInit" : "true"
}
```

------

# SAML ID プロバイダーの名前と識別子
<a name="cognito-user-pools-managing-saml-idp-naming"></a>

SAML ID プロバイダー (IdP) に名前を付け、IdP 識別子を割り当てると、そのプロバイダーへの、SP が開始したサインインリクエストとサインアウトリクエストのフローを自動化できます。プロバイダーの名前に対する文字列制約の詳細については、[CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html#CognitoUserPools-CreateIdentityProvider-request-ProviderName) の `ProviderName` プロパティを参照してください。

![\[IdP の識別子とマネージドログインを使用して Amazon Cognito の SP が開始した SAML サインインの認証フロー図。ユーザーは、マネージドログインに E メールアドレスを提供し、Amazon Cognito は、ユーザーを自動的にプロバイダーにリダイレクトします。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/scenario-authentication-saml-identifier.png)


SAML プロバイダーの識別子を 50 個まで選択することもできます。識別子は、ユーザープール内の IdP のわかりやすい名前であり、ユーザープール内で一意である必要があります。SAML 識別子がユーザーの E メールドメインと一致すると、マネージドログインは、各ユーザーの E メールアドレスをリクエストし、E メールアドレス内のドメインを評価して、ドメインに対応する IdP にユーザーをリダイレクトします。同じ組織で複数のドメインを所有することができるため、1 つの IdP が複数の識別子を持つことができます。

E メールドメイン識別子の使用の有無にかかわらず、マルチテナントアプリケーションの識別子を使用して、ユーザーを正しい IdP にリダイレクトできます。マネージドログインを完全にバイパスする場合は、ユーザーに提示するリンクをカスタマイズすることで、[認可エンドポイント](authorization-endpoint.md) を介してユーザーを IdP に直接リダイレクトできます。識別子を使用してユーザーにサインインし、IdP にリダイレクトするには、最初の認可リクエストのリクエストパラメータに `idp_identifier=myidp.example.com` 形式の識別子を含めます。

ユーザーを IdP に渡す別の方法は、IdP の名前を持つパラメータ `identity_provider` を、次の URL 形式で入力することです。

```
https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
identity_provider=MySAMLIdP&
client_id=1example23456789&
redirect_uri=https://www.example.com
```

ユーザーが SAML IdP でサインインすると、IdP は、`HTTP POST` 本文内の SAML レスポンスを使用して `/saml2/idpresponse` エンドポイントにリダイレクトします。Amazon Cognito は SAML アサーションを処理し、レスポンスのクレームが期待を満たしている場合、アプリケーションクライアントのコールバック URL にリダイレクトします。ユーザーがこの方法で認証を完了すれば、ユーザーが IdP とアプリケーションのためにのみウェブページを操作したことになります。

ドメイン形式の IdP 識別子を使用すると、マネージドログインは、サインイン時に E メールアドレスをリクエストし、E メールドメインが IdP 識別子と一致すると、ユーザーを IdP のサインインページにリダイレクトします。例えば、異なる 2 つの会社に所属する従業員によるサインインが必要となるアプリケーションを構築するとします。最初の会社、AnyCompany A は、`exampleA.com` および `exampleA.co.uk` を所有しています。2 番目の会社、AnyCompany B は、`exampleB.com` を所有しています。この例では、以下のように、1 社ごとに 2 つの IdP を設定します。
+ IdP A では、識別子 `exampleA.com` および `exampleA.co.uk` を定義します。
+ IdP B では、識別子 `exampleB.com` を定義します。

アプリケーションでは、アプリケーションクライアントのマネージドログインを呼び出し、各ユーザーに E メールアドレスの入力を求めます。Amazon Cognito は、E メールアドレスからドメインを取得し、ドメインを IdP とドメイン識別子に関連付け、`idp_identifier` リクエストパラメータを含む [認可エンドポイント](authorization-endpoint.md) へのリクエストを使用して、ユーザーを正しい IdP にリダイレクトします。例えば、ユーザーが `bob@exampleA.co.uk` を入力した場合、ユーザーが操作する次のページは、`https://auth.exampleA.co.uk/sso/saml` の IdP サインインページになります。

また、同じロジックを個別に実装することもできます。アプリケーションでは、ユーザー入力を収集したうえで独自のロジックに従って正しい IdP に関連付けるカスタムフォームを構築できます。アプリケーションテナントごとにカスタムポータルを生成すると、リクエストパラメータ内のテナントの識別子を使用して、各アプリケーションテナントを承認エンドポイントにリンクできます。

E メールアドレスを収集して、マネージドログインのドメインを解析するには、アプリケーションクライアントに割り当てた SAML IdP ごとに 1 つ以上の識別子を割り当てます。デフォルトでは、マネージドログインのサインイン画面に、アプリケーションクライアントに割り当てた IdP ごとにボタンが表示されます。ただし、識別子を正常に割り当てると、クラシックのホストされた UI のサインインページは、次の画像のようになります。

![\[Amazon Cognito のマネージドログインのサインインページに表示される、ローカルユーザーのサインインと、フェデレーションユーザーに E メールアドレスの入力を求めるプロンプト。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-saml-identifiers.png)


**注記**  
クラシックのホストされた UI では、IdP に識別子を割り当てると、アプリケーションクライアントのサインインページで自動的にメールアドレスの入力を求められます。マネージドログインのエクスペリエンスでは、この動作をブランディングエディタで有効にする必要があります。**[認証動作]** の設定カテゴリで、見出しの **[プロバイダーの表示]** の下にある **[ドメイン検索入力]** を選択します。

マネージドログインのドメイン解析では、ドメインを IdP 識別子として使用する必要があります。アプリケーションクライアントの SAML IdP ごとに任意のタイプの識別子を割り当てると、そのアプリケーションのマネージドログインには、IdP の選択ボタンが表示されなくなります。E メール解析やカスタムロジックを使用してリダイレクトを生成する場合は、SAML の IdP 識別子を追加します。サイレントリダイレクトを生成するとともに、マネージドログインに IdP のリストを表示する場合は、識別子を割り当てず、認可リクエストで `identity_provider` リクエストパラメータを使用します。
+ アプリケーションクライアントに SAML IdP を 1 つだけ割り当てると、マネージドログインのサインインページには、その IdP でサインインするためのボタンが表示されます。
+ アプリケーションクライアントでアクティブ化する SAML IdP ごとに識別子を割り当てると、マネージドログインサインインページには、E メールアドレスの入力をユーザーに求めるプロンプトが表示されます。
+ 複数の IdP があり、すべてには識別子を割り当てない場合、マネージドログインのサインインページには、割り当てた IdP ごとにサインインするためのボタンが表示されます。
+ IdP に識別子を割り当て、マネージドログインページに特定の IdP ボタンを表示する場合は、新しい IdP を識別子なしでアプリケーションクライアントに追加するか、新しいアプリケーションクライアントを作成します。既存の IdP を削除し、識別子を用いずにそれを再度追加することもできます。新しい IdP を作成すると、SAML ユーザーが新しいユーザープロファイルを作成します。このようにアクティブなユーザーが重複していると、IdP 設定を変更した月に請求に影響する可能性があります。

IdP セットアップの詳細については、「[ユーザープールの ID プロバイダーの設定](cognito-user-pools-identity-provider.md)」を参照してください。

# ユーザープールでの OIDC ID プロバイダーの使用
<a name="cognito-user-pools-oidc-idp"></a>

ユーザーは、OpenID Connect (OIDC) ID プロバイダー (IdP) の既存アカウントを使用してアプリケーションにサインインできます。OIDC プロバイダーを使用すると、独立したシングルサインオンシステムのユーザーは、アプリケーションがユーザープールの共有形式で OIDC トークンを受信する間、既存の認証情報を提供できます。OIDC IdP を設定するには、ユーザープールを RP として処理するように IdP を設定するとともに、ユーザープールを IdP として処理するようにアプリケーションを設定します。Amazon Cognito は、複数の OIDC IdP とアプリケーションの間の中間ステップとして機能します。ユーザープールは、プロバイダーがユーザープールに直接渡す ID トークンとアクセストークンのクレームに、属性マッピングルールを適用します。次に、Amazon Cognito は、マッピングされたユーザー属性と、[Lambda トリガー](cognito-user-pools-working-with-lambda-triggers.md#lambda-triggers-for-federated-users)を使用して認証フローに加えた追加の調整に基づいて、新しいトークンを発行します。

OIDC IdP でサインインするユーザーは、ユーザープールアプリケーションにアクセスするために、新しい認証情報や情報を提供する必要はありません。アプリケーションは、ユーザープールを使用して、サインインのために IdP にサイレントにリダイレクトできます。この場合、ユーザープールは、アプリケーションのトークン形式を標準化するバックグラウンドのツールとして使用されます。IdP リダイレクトの詳細については、「[認可エンドポイント](authorization-endpoint.md)」を参照してください。

他のサードパーティー ID プロバイダーと同様に、アプリケーションを OIDC プロバイダーに登録し、ユーザープールに接続する IdP アプリケーションに関する情報を取得する必要があります。ユーザープール OIDC IdP には、クライアント ID、クライアントシークレット、リクエストするスコープ、プロバイダーサービスエンドポイントに関する情報が必要です。ユーザープールが検出エンドポイントからプロバイダーの OIDC エンドポイントを検出すできますが、ユーザーが手動で入力することもできます。また、プロバイダー ID トークンを調べ、IdP とユーザープール内の属性に関して属性マッピングを作成する必要があります。

![\[OIDC ユーザープール IdP 認証フロー\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/flow-cup-oidc-endpoints.png)


この認証フローの詳細については、「[OIDC ユーザープール IdP 認証フロー](cognito-user-pools-oidc-flow.md)」を参照してください。

**注記**  
サードパーティー (フェデレーション) 経由のサインインは、Amazon Cognito のユーザープールで使用できます。この機能は、Amazon Cognito アイデンティティプールを使用した OIDC フェデレーションとは無関係です。

OIDC IdP は AWS マネジメントコンソール、、、またはユーザープール API メソッド [CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html) を使用して AWS CLI、ユーザープールに追加できます。

**Topics**
+ [前提条件](#cognito-user-pools-oidc-idp-prerequisites)
+ [アプリケーションを OIDC IdP に登録する](#cognito-user-pools-oidc-idp-step-1)
+ [ユーザープールに OIDC IdP を追加する](#cognito-user-pools-oidc-idp-step-2)
+ [OIDC IdP の設定をテストする](#cognito-user-pools-oidc-idp-step-3)
+ [OIDC ユーザープール IdP 認証フロー](cognito-user-pools-oidc-flow.md)

## 前提条件
<a name="cognito-user-pools-oidc-idp-prerequisites"></a>

開始するには、以下が必要です。
+ アプリケーションクライアントとユーザープールドメインを使用するユーザープール。詳細については、「[ユーザープールの作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)」を参照してください。
+ 次の設定を持つ OIDC IdP。
  + `client_secret_post` クライアント認証をサポートします。Amazon Cognito は、IdP の OIDC ディスカバリエンドポイントでの `token_endpoint_auth_methods_supported` クレームをチェックしません。Amazon Cognito は、`client_secret_basic` クライアント認証をサポートしていません。クライアント認証の詳細については、OpenID Connect ドキュメントの「[クライアント認証](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication)」を参照してください。
  + `openid_configuration`、`userInfo`、および `jwks_uri` などの OIDC エンドポイントにのみ HTTPS を使用します。
  + OIDC エンドポイントには TCP ポート 80 および 443 のみを使用します。
  + HMAC-SHA、ECDSA または RSA アルゴリズムで ID トークンにのみ署名します。
  + キー ID `kid` クレームを `jwks_uri`  で発行し、そのトークンに `kid` クレームをフックみます。
  + 有効なルート CA トラストチェーンを持つ、有効期限が切れていないパブリックキーを表示します。

## アプリケーションを OIDC IdP に登録する
<a name="cognito-user-pools-oidc-idp-step-1"></a>

OIDC IdP をユーザープール設定に追加してアプリケーションクライアントに割り当てる前に、OIDC クライアントアプリケーションを IdP に設定します。ユーザープールは、依拠しているパーティのアプリケーションとして、IdP を使用して認証を管理します。

**OIDC IdP に登録する**

1. OIDC IdP のデベロッパーアカウントを作成します。  
**OIDC IdP へのリンク**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-oidc-idp.html)

1. OIDC IdP を使用して、`/oauth2/idpresponse` エンドポイントを持つユーザープールドメインを登録します。そうすることで、OIDC IdP が後ほど、ユーザーの認証時に Amazon Cognito からこれを受け入れることが確実になります。

   ```
   https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/idpresponse
   ```

1. ユーザーディレクトリとユーザープールで共有する[スコープ](cognito-user-pools-define-resource-servers.md#cognito-user-pools-define-resource-servers-about-scopes)を選択します。OIDC IdP がユーザー情報を提供するには、スコープとして **openid** が必要です。`email` スコープは、`email` および `email_verified` の [クレーム](https://openid.net/specs/openid-connect-basic-1_0.html#StandardClaims)へのアクセスを付与するために必要です。OIDC 仕様のその他のスコープは、すべてのユーザー属性のための `profile` と、`phone_number` および `phone_number_verified` のための `phone` です。

1. OIDC IdP は、クライアント ID とクライアントシークレットを提供します。これらの値をメモし、後でユーザープールに追加する OIDC IdP の設定に追加します。

**例: Salesforce を OIDC IdP としてユーザープールで使用する**

 OIDC 互換 IdP (Salesforce など) とユーザープールの間で信頼性を確立するときに OIDC IdP を使用します。

1. Salesforce 開発者ウェブサイトで[アカウントを作成](https://developer.salesforce.com/signup)します。

1. 前のステップで設定した開発者アカウントを使用して[サインイン](https://developer.salesforce.com)します。

1. Salesforce ページで、次のいずれかの操作を行います。
   +  Lightning Experience を使用している場合は、歯車アイコンを選択してから、**[Setup Home]** (ホームの設定) を選択します。
   +  Salesforce Classic を使用しており、ユーザーインターフェイスのヘッダーに [**Setup (設定)**] が表示されている場合は、選択します。
   +  Salesforce Classic を使用しており、ヘッダーに [**Setup (設定)**] が表示されていない場合は、上部のナビゲーションバーで名前を選択し、ドロップダウンリストより [**Setup (設定)**] を選択します。

1. 左のナビゲーションバーで、[**Company Settings (組織の設定)**] を選択します。

1. ナビゲーションバーで、**[Domain]** (ドメイン) を選択してドメインを入力し、**[Create]** (作成) を入力します。

1. 左のナビゲーションバーで、**[Platform Tools]** (プラットフォームツール) に移動し、**[Apps]** (アプリケーション) を選択します。

1. [**アプリケーションマネージャ**] を選択します。

1. 

   1. **[New connected app]** (新規接続アプリケーション) を選択します。

   1. 必須フィールドに入力します。

      **[Start URL]** (開始 URL) で、Salesforce IdP でサインインするユーザープールドメインの `/authorize` エンドポイントの URL を入力します。ユーザーが接続アプリケーションにアクセスすると、Salesforce はこの URL に誘導してサインインを完了します。次に、Salesforce はユーザーをアプリクライアントに関連付けたコールバック URL にリダイレクトします。

      ```
      https://mydomain.auth.us-east-1.amazoncognito.com/authorize?response_type=code&client_id=<your_client_id>&redirect_uri=https://www.example.com&identity_provider=CorpSalesforce
      ```

   1. **OAuth 設定**を有効にし、**コールバック URL** にユーザープールドメインの `/oauth2/idpresponse` エンドポイントの URL を入力します。これは、Amazon Cognito が OAuth トークンと交換する認可コードを Salesforce が発行する URL です。

      ```
      https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/idpresponse
      ```

1. [スコープ](https://openid.net/specs/openid-connect-basic-1_0.html#Scopes)を選択します。スコープ **openid** を含める必要があります。**email** および **email\$1verified** の [クレーム](https://openid.net/specs/openid-connect-basic-1_0.html#StandardClaims)へのアクセスを許可するには、**email** スコープを追加します。スコープはスペースで区切ります。

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

   Salesforce では、クライアント ID は [**コンシューマーキー**]、クライアントシークレットは [**コンシューマーシークレット**] と呼ばれます。クライアント ID とクライアントシークレットを書き留めます。これらは次のセクションで使用します。

## ユーザープールに OIDC IdP を追加する
<a name="cognito-user-pools-oidc-idp-step-2"></a>

IdP を設定したら、OIDC IdP で認証リクエストを処理するようにユーザープールを設定できます。

------
#### [ Amazon Cognito console ]

**コンソールで OIDC IdP を追加する**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. ナビゲーションメニューから **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択し、**[ID プロバイダーを追加]** を選択します。

1. [**OpenID Connect**] IdP を選択します。

1. **[プロバイダー名]** に一意の名前を入力します。

1. IdP の **[クライアント ID]** を入力します。これは、OIDC IdP で構築するアプリケーションクライアントの ID です。指定するクライアント ID は、`https://[your user pool domain]/oauth2/idpresponse` のコールバック URL で設定した OIDC プロバイダーである必要があります。

1. IdP の **[クライアントシークレット]** を入力します。これは、前のステップで入力したのと同じアプリケーションクライアントのクライアントシークレットである必要があります。

1. <a name="cognito-user-pools-oidc-step-2-substep-9"></a>このプロバイダーの **[Authorized scopes]** (承認済みスコープ) を入力します。スコープは、アプリケーションがプロバイダーにリクエストするユーザー属性のグループ (`name` および `email` など) を定義します。[OAuth 2.0](https://tools.ietf.org/html/rfc6749#section-3.3) 仕様に従い、スコープはスペースで区切る必要があります。

   IdP は、ユーザーがサインインするときに、これらの属性をアプリケーションに提供することに同意するようユーザーに求める場合があります。

1. **[属性のリクエストメソッド]** を選択します。IdP は、`userInfo` エンドポイントへのリクエストを `GET` または `POST` の形式にするよう求める場合があります。例えば、Amazon Cognito の `userInfo` エンドポイントには `HTTP GET` リクエストが必要です。

1. **[セットアップ方法]** で、IdP の主要な OIDC フェデレーションエンドポイントへのパスを、ユーザープールで決定する方法を選択します。通常、IdP は、発行者のベース URL で `/well-known/openid-configuration` エンドポイントをホストします。これが該当するプロバイダーの場合、**[発行者 URL を通じた自動入力]** オプションは、そのベース URL の入力を求め、そこから `/well-known/openid-configuration` パスへのアクセスを試み、表示されたエンドポイントを読み取ります。エンドポイントパスが通常とは異なっていたり、代替プロキシを介して 1 つ以上のエンドポイントにリクエストを渡したりする場合があります。その場合は、**[手動入力]** を選択し、`authorization`、`token`、`userInfo`、`jwks_uri` エンドポイントのパスを指定します。
**注記**  
URL は、`https://` で始める必要があり、末尾にスラッシュ (`/`) を使用することはできません。この URL では、ポート番号 443 および 80 のみを使用できます。例えば、Salesforce では次の URL を使用します。  
`https://login.salesforce.com`   
自動入力を選択した場合、検出ドキュメントは `authorization_endpoint`、`token_endpoint`、`userinfo_endpoint`、および `jwks_uri` の値に HTTPS を使用する必要があります。そうしない場合は、ログインが失敗します。

1. **[OpenID Connect プロバイダーとユーザープール間の属性をマッピングする]** で属性マッピングルールを設定します。**ユーザープール属性**は Amazon Cognito ユーザープロファイルの*送信先*属性であり、**OpenID Connect 属性**は ID トークンのクレームまたは `userInfo` レスポンスで Amazon Cognito が検索する*ソース*属性です。Amazon Cognito は、OIDC クレーム **sub** を送信先ユーザープロファイルの `username` に自動的にマッピングします。

   詳細については、「[IdP 属性をプロファイルとトークンにマッピングする](cognito-user-pools-specifying-attribute-mapping.md)」を参照してください。

1. **[ID プロバイダーを追加]** を選択します。

1. **[アプリケーションクライアント]** メニューで、リストからアプリケーションクライアントを選択します。**[ログインページ]** タブに移動し、**[マネージドログインページの設定]** で **[編集]** を選択します。**[ID プロバイダー]** を見つけ、新しい OIDC IdP を追加します。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ API/CLI ]

[CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html#API_CreateIdentityProvider_Example_2) の例 2 の OIDC 設定を参照してください。この構文を変更して、`CreateIdentityProvider` と `UpdateIdentityProvider` のリクエスト本文として使用するか、[create-identity-provider](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-identity-provider.html) の `--cli-input-json` 入力ファイルとして使用できます。

------

## OIDC IdP の設定をテストする
<a name="cognito-user-pools-oidc-idp-step-3"></a>

アプリケーションでは、ユーザーが OIDC プロバイダーでサインインできるように、ユーザーのクライアントでブラウザを起動する必要があります。前のセクションのセットアップ手順を完了したら、プロバイダーを使用したサインインをテストします。次の URL の例では、プレフィックスドメインを持つユーザープールのサインインページをロードします。

```
https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com
```

このリンクは、**[アプリケーションクライアント]** メニューに移動してアプリケーションクライアントを選択し、**[ログインページ]** タブに移動して **[ログインページを表示]** を選択したときに、Amazon Cognito に表示されるページです。ユーザープールドメインの詳細については、「[ユーザープールのドメインを設定する](cognito-user-pools-assign-domain.md)」を参照してください。クライアント ID とコールバック URL など、アプリケーションクライアントの詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。

次のリンク例では、`identity_provider` クエリパラメータを使用して、[認可エンドポイント](authorization-endpoint.md) から `MyOIDCIdP` プロバイダーへのサイレントリダイレクトを設定します。この URL は、マネージドログインによるインタラクティブなユーザープールのサインインをバイパスし、IdP サインインページに直接移動します。

```
https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?identity_provider=MyOIDCIdP&response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com
```

# OIDC ユーザープール IdP 認証フロー
<a name="cognito-user-pools-oidc-flow"></a>

OpenID Connect (OIDC) サインインを使用すると、ユーザープールは ID プロバイダー (IdP) による認可コードサインインフローを自動化します。ユーザーが IdP でサインインを完了すると、Amazon Cognito は外部プロバイダーの `oauth2/idpresponse` エンドポイントでコードを収集します。結果として得られたアクセストークンを使用して、ユーザープールは、IdP `userInfo` エンドポイントにクエリを実行してユーザー属性を取得します。その後、ユーザープールは、受信した属性を、設定済みの属性マッピングルールと比較し、それに応じてユーザーのプロファイルと ID トークンを入力します。

OIDC プロバイダー設定でリクエストする OAuth 2.0 スコープは、IdP が Amazon Cognito に提供するユーザー属性を定義します。セキュリティのベストプラクティスとしては、ユーザープールにマッピングする属性に対応するスコープのみをリクエストします。例えば、ユーザープールが `openid profile` をリクエストすると、考えられる属性がすべて取得されますが、`openid email phone_number` をリクエストすると、ユーザーの E メールアドレスと電話番号のみが取得されます。[OIDC IdP にリクエスト](cognito-user-pools-oidc-idp.md#cognito-user-pools-oidc-step-2-substep-9)するスコープについては、[アプリケーションクライアント](user-pool-settings-client-apps.md#user-pool-settings-client-apps-scopes)とユーザープール認証リクエストで認可とリクエストを行うスコープとは異なるものとして設定できます。

ユーザーが OIDC IdP を使用してアプリケーションにサインインする場合、ユーザープールは、以下の認証フローはを実行します。

1. ユーザーはマネージドログインのサインインページにアクセスし、OIDC IdP でサインインすることを選択します。

1. アプリケーションは、ユーザーのブラウザを、ユーザープールの承認エンドポイントに誘導します。

1. ユーザープールは、OIDC IdP の承認エンドポイントにリクエストをリダイレクトします。

1. IdP にログインプロンプトが表示されます。

1. アプリケーションでは、ユーザーのセッションに OIDC IdP のサインインプロンプトが表示されます。

1. ユーザーは IdP の認証情報を入力するか、認証済みセッションの Cookie を提示します。

1. ユーザーが認証を行うと、OIDC IdP が認可コードを使用して Amazon Cognito にリダイレクトします。

1. ユーザープールは、認証コードを ID トークンおよびアクセストークンと交換します。IdP にスコープ `openid` を設定すると、Amazon Cognito はアクセストークンを受け取ります。ID トークンのクレームと `userInfo` レスポンスは、IdP 設定のその他のスコープ (`profile` や `email` など) によって決まります。

1. IdP はリクエストされたトークンを発行します。

1. ユーザープールは、IdP 設定の発行者 URL から IdP の `jwks_uri` エンドポイントへのパスを決定し、JSON ウェブキーセット (JWKS) エンドポイントに対してトークン署名キーをリクエストします。

1. IdP は JWKS エンドポイントから署名キーを返します。

1. ユーザープールは、トークン内の署名と有効期限のデータから IdP トークンを検証します。

1. ユーザープールは、アクセストークンを使用して IdP の `userInfo` エンドポイントへのリクエストを承認します。IdP は、アクセストークンのスコープに基づいて、ユーザーデータを返します。

1. ユーザープールは、IdP からの ID トークンと `userInfo` レスポンスを、ユーザープール内の属性マッピングルールと比較します。マッピングされた IdP 属性をユーザープールのプロファイル属性に書き込みます。

1. Amazon Cognito がアプリケーションのベアラートークンを発行します。これには ID トークン、アクセストークン、および更新トークンが含まれる場合があります。

1. アプリケーションは、ユーザープールのトークンを処理し、ユーザーをサインインさせます。

![\[OIDC ユーザープール IdP 認証フロー\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/flow-cup-oidc-endpoints.png)


**注記**  
Amazon Cognito は 5 分以内に完了しない認証リクエストをキャンセルし、ユーザーをマネージドログインにリダイレクトします。ページには、`Something went wrong` というエラーメッセージが表示されます。

OIDC は、OAuth 2.0 の上に位置する ID レイヤーです。OAuth 2.0 は、IdP から OIDC クライアントアプリ (証明書利用者) に発行される JSON 形式 (JWT) の ID トークンを指定します。Amazon Cognito の OIDC Relying Party としての追加に関する情報は、OIDC IdP のドキュメントを参照してください。

ユーザーが認可コード付与を使用して認証すると、ユーザープールは ID、アクセス、更新トークンを返します。ID トークンは ID 管理用の [OIDC](http://openid.net/specs/openid-connect-core-1_0.html) 標準トークンです。アクセストークンは [OAuth 2.0](https://oauth.net/2/) 標準トークンです。ユーザープールのアプリケーションクライアントがサポートできる付与タイプの詳細については、「[認可エンドポイント](authorization-endpoint.md)」を参照してください。

## ユーザープールが OIDC プロバイダーからのクレームを処理する方法
<a name="how-a-cognito-user-pool-processes-claims-from-an-oidc-provider"></a>

ユーザーがサードパーティの OIDC プロバイダーでサインインを完了すると、マネージドログインは IdP から認証コードを取得します。ユーザープールは、アクセストークンと ID トークンの認可コードを IdP の `token` エンドポイントと交換します。ユーザープールはこれらのトークンをユーザーやアプリに渡すのではなく、これらを使って独自のトークンのクレームで提示するデータを使用してユーザープロファイルを構築します。

 Amazon Cognito はアクセストークンを個別に検証しません。代わりに、`userInfo`プロバイダーの エンドポイントにユーザー属性情報をリクエストし、トークンが有効でない場合はリクエストが拒否されることを想定しています。

Amazon Cognito は、以下のチェックを行ってプロバイダー ID トークンを検証します。

1. プロバイダーが RSA、HMAC、Elliptic Curve というセットのアルゴリズムを使用してトークンに署名したことをチェックします。

1. プロバイダーが非対称署名アルゴリズムを使用してトークンに署名した場合は、トークンの `kid` クレームの署名キー ID がプロバイダーの `jwks_uri` エンドポイントに表示されていることを確認します。Amazon Cognito は、処理する IdP ID トークンごとに、IdP 設定の JWKS エンドポイントから署名キーを更新します。

1. ID トークンの署名を、プロバイダーのメタデータに基づいて想定される署名と比較します。

1. `iss` クレームを IdP に設定された OIDC 発行者と比較します。

1. `aud` クレームが IdP で設定されているクライアント ID と一致するか、または `aud` クレームに複数の値がある場合は設定されたクライアント ID が含まれているかを比較します。

1. `exp` クレームのタイムスタンプが現在の時刻より前でないことをチェックします。

ユーザープールは ID トークンを検証し、プロバイダーアクセストークンを使用してプロバイダーの `userInfo` エンドポイントへのリクエストを試みます。アクセストークンのスコープによって読み取りが許可されたユーザープロファイル情報がすべて取得されます。次にユーザープールはユーザープールの要求に従って設定したユーザー属性を検索します。プロバイダー設定で、必要な属性の属性マッピングを作成する必要があります。ユーザープールはプロバイダー ID トークンと `userInfo` レスポンスをチェックします。ユーザープールは、マッピングルールに一致するすべてのクレームをユーザープールのユーザープロファイルのユーザー属性に書き込みます。ユーザープールは、マッピングルールに一致するが必須ではなく、プロバイダーのクレームにも含まれていない属性を無視します。

# IdP 属性をプロファイルとトークンにマッピングする
<a name="cognito-user-pools-specifying-attribute-mapping"></a>

Amazon Cognito を含む ID プロバイダー (IdP) サービスは、通常、ユーザーに関する詳細情報を記録できます。ユーザーの勤務先の会社、連絡方法、その他の識別情報を把握しておきたい場合があります。しかしながら、これらの属性の形式はプロバイダーによって違いがあります。例えば、ユーザープールを使用して 3 つの異なるベンダーから 3 つの IdP をセットアップし、各ベンダーの SAML アサーション、ID トークン、`userInfo` ペイロードの例を調べるとします。ユーザーの E メールアドレスの表記は、ある IdP では `email`、別の IdP では `emailaddress`、もう 1 つの IdP では `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` となります。

IdP ユーザープールと統合することで得られる主なメリットは、さまざまな属性名を、一貫性のある予測可能な共有属性名を持つ単一の OIDC トークンスキーマにマッピングできることです。これにより、デベロッパーは複雑なさまざまなシングルサインオンイベントを処理するためのロジックを維持する必要がなくなります。こうした形式の統合が属性マッピングです。ユーザープール属性マッピングは、IdP 属性名を、対応するユーザープール属性名に割り当てます。例えば、`emailaddress` クレームの値を標準ユーザープール属性 `email` に書き込むようにユーザープールを設定できます。

各ユーザープール IdP には、個別の属性マッピングスキーマがあります。IdP の属性マッピングを指定するには、Amazon Cognito コンソール、 AWS SDK、またはユーザープール REST API でユーザープール ID プロバイダーを設定します。

## マッピングについて知っておくべきこと
<a name="cognito-user-pools-specifying-attribute-mapping-requirements"></a>

ユーザー属性マッピングの設定を開始する前に、以下の重要な詳細事項を確認します。
+ フェデレーションユーザーがアプリケーションにサインインする際、マッピングは、ユーザープールが必要とする各ユーザープール属性に存在している必要があります。例えば、サインアップするためにユーザープールで `email` 属性が必要となる場合には、この属性を IdP から該当するものにマッピングします。
+ デフォルトで、マップされた E メールアドレスは未検証です。ワンタイムコードを使用してマップされた E メールアドレスを検証することはできません。その代わりに IdP からの属性をマップして、検証ステータスを取得します。例えば、Google とほとんどの OIDC プロバイダーには `email_verified` 属性が含まれています。
+ ID プロバイダー (IdP) のトークンをユーザープールのカスタム属性にマッピングできます。ソーシャルプロバイダーはアクセストークンを提示し、OIDC プロバイダーはアクセストークンと ID トークンを提示します。トークンをマッピングするには、最大長さ 2,048 文字のカスタム属性を追加し、アプリクライアントにその属性への書き込みアクセス許可を付与し、IdP からの `access_token` または `id_token` をカスタム属性にマッピングします。
+ マッピングされた各ユーザープールの属性では、値の最大長 さである 2048 文字が、Amazon Cognito が IdP から取得する値に対して十分な長さである必要があります。そうではない場合は、ユーザーがアプリケーションにサインインするときに Amazon Cognito がエラーを報告します。Amazon Cognito は、トークンの長さが 2,048 文字を超える場合、IdP トークンのカスタム属性へのマッピングをサポートしていません。
+ Amazon Cognito は、フェデレーション IdP がパスする特定のクレームから、フェデレーションユーザーのプロファイル内の `username` 属性を、次の表に示すように派生します。Amazon Cognito は、この属性値の先頭に、`MyOIDCIdP_[sub]` などの IdP の名前を追加します。フェデレーションユーザーについて、外部ユーザーディレクトリ内の属性と完全に一致する属性を持たせる場合は、その属性を `preferred_username` などの Amazon Cognito サインイン属性にマッピングします。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-specifying-attribute-mapping.html)
+ ユーザープールが[大文字と小文字を区別しない](user-pool-case-sensitivity.md)ものである場合、Amazon Cognito は、フェデレーションユーザーの自動生成されたユーザー名におけるユーザー名ソース属性を小文字に変換します。大文字と小文字を区別するユーザープールのユーザー名の例は次のとおりです: `MySAML_TestUser@example.com`。大文字と小文字を*区別しない*ユーザープールでは同じユーザー名が次のようになります: `MySAML_testuser@example.com`。

  大文字と小文字を区別しないユーザープールでは、ユーザー名を処理する Lambda トリガーは、ユーザー名ソース属性について大文字と小文字が混在するクレームに対して、この変更を考慮する必要があります。IdP を、現在のユーザープールとは異なる大文字と小文字の区別設定を持つユーザープールにリンクするには、新しいユーザープールを作成します。
+ Amazon Cognito は、ユーザーがアプリケーションにサインインするときにマップされたユーザープール属性を更新できる必要があります。ユーザーが IdP 経由でサインインすると、Amazon Cognito は IdP からの最新情報でマップされた属性を更新します。Amazon Cognito は、値が変更された場合にのみマッピングされた属性を更新します。Amazon Cognito が属性を更新できることを確実にするため、以下の要件をチェックしてください。
  + IdP からマッピングするユーザープールのカスタム属性は、すべて*変更可能*である必要があります。変更可能なカスタム属性はいつでも更新できます。一方、ユーザーの*イミュータブル* (変更不可) カスタム属性は、ユーザープロファイルの初回作成時を除き、値を設定できません。Amazon Cognito コンソールで変更可能なカスタム属性を作成するには、**[サインアップエクスペリエンス]** メニューの **[カスタム属性を追加]** を選択して追加した属性の **[変更可能]** チェックボックスをオンにします。または、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API オペレーションを使用してユーザープールを作成した場合、これらの各属性の `Mutable` パラメータを `true` に設定できます。IdP が、マッピングされたイミュータブルな属性の値を送信すると、Amazon Cognito はエラーを返し、サインインは失敗します。
  + アプリケーションのアプリクライアントの設定では、マッピングされた属性を*書き込み可能*にする必要があります。書き込み可能な属性は、Amazon Cognito コンソールの **[App clients]** (アプリクライアント) ページで設定できます。また、[https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) API を使用してアプリクライアントを作成する場合、これらの属性を `WriteAttributes` 配列に追加できます。IdP が、マッピングされた書き込み不可の属性の値を送信する場合、Amazon Cognito は属性値を設定せず、認証に進みます。
+ IdP 属性に複数の値が含まれている場合、Amazon Cognito はすべての値を角括弧文字 `[` および `]` で囲まれた 1 つのカンマ区切り文字列にフラット化します。Amazon Cognito は、`.`、`-`、`*`、`_` を除く、英数字以外の文字を含む値を URL フォームエンコードします。値は、アプリでの使用前にデコードおよび解析しておく必要があります。
+ 送信先属性は、サインインまたは管理アクションによって変更されない限り、属性マッピングルールによって割り当てられた値を保持します。プロバイダートークンまたは SAML アサーションでソース属性が送信されなくなった場合でも、Amazon Cognito はユーザーから属性を削除しません。以下のアクションでは、フェデレーションユーザーのユーザープールプロファイルから属性の値を削除します。

  1. IdP はソース属性に空白の値を送信し、マッピングルールによって空白の値を送信先属性に適用します。

  1. [DeleteUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserAttributes.html) リクエストまたは [AdminDeleteUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminDeleteUserAttributes.html) リクエストを使用して、マッピングされた属性の値をクリアします。

## ユーザープールの ID プロバイダー属性マッピングを指定する (AWS マネジメントコンソール)
<a name="cognito-user-pools-specifying-attribute-mapping-console"></a>

を使用して AWS マネジメントコンソール 、ユーザープールの IdP の属性マッピングを指定できます。

**注記**  
Amazon Cognito は、着信トークンに着信クレームが存在する場合に限り、そのクレームをユーザープール属性にマップします。以前にマッピングされたクレームが着信トークンに存在しなくなった場合、そのクレームは削除または変更されません。削除されたクレームのマッピングがアプリケーションで必要な場合は、事前認証 Lambda トリガーを使用して認証中にカスタム属性を削除し、それらの属性を着信トークンから再入力できます。

**ソーシャル IdP 属性マッピングを指定するには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)にサインインします。プロンプトが表示されたら、 AWS 認証情報を入力します。

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

1. **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択します。

1. **[ID プロバイダーを追加]** を選択するか、設定した **[Facebook]**、**[Google]**、**[Amazon]**、または **[Apple]** の IdP を選択します。**[Attribute mapping]** (属性マッピング) を検索し、 **[Edit]** (編集) を選択します。

   ソーシャル IdP の追加の詳細については、「[ユーザープールによるソーシャル ID プロバイダーの使用](cognito-user-pools-social-idp.md)」を参照してください。

1. マッピングする必要のある各属性について、以下のステップを完了してください。

   1. **[User pool attribute]** (ユーザープール属性) 列から属性を選択します。これは、ユーザープール内のユーザープロファイルに割り当てられる属性です。カスタム属性は、標準属性の後にリストされます。

   1. **[*<provider>* attribute]** (<プロバイダー> 属性) 列から属性を選択します。これは、プロバイダーディレクトリから渡される属性になります。ソーシャルプロバイダーの既知の属性は、ドロップダウンリストに表示されます。

   1. IdP と Amazon Cognito の間に追加の属性をマッピングするには、**[Add another attribute]** (その他の属性を追加) を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

**SAML プロバイダー属性マッピングを指定する**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)にサインインします。プロンプトが表示されたら、 AWS 認証情報を入力します。

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

1. **[ソーシャルプロバイダーと外部プロバイダー]** メニューを選択します。

1. **[Add an identity provider]** (ID プロバイダーの追加) を選択するか、設定した SAML IdP を選択します。**[Attribute mapping]** (属性マッピング) を探し、**[Edit]** (編集) を選択します。SAML IdP の詳細については、「[ユーザープールによる SAML ID プロバイダーの使用](cognito-user-pools-saml-idp.md)」を参照してください。

1. マッピングする必要のある各属性について、以下のステップを完了してください。

   1. **[User pool attribute]** (ユーザープール属性) 列から属性を選択します。これは、ユーザープール内のユーザープロファイルに割り当てられる属性です。カスタム属性は、標準属性の後にリストされます。

   1. **[SAML attribute]** (SAML 属性) 列から属性を選択します。これは、プロバイダーディレクトリから渡される属性になります。

      IdP は、参考として SAML アサーションのサンプルを提供する場合があります。IdP の中には、`email` などの単純な名前を使用するものもあれば、次のような URL 形式の属性名を使用するものもあります。

      ```
      http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
      ```

   1. IdP と Amazon Cognito の間に追加の属性をマッピングするには、**[Add another attribute]** (その他の属性を追加) を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

## ユーザープール (AWS CLI および AWS API) の ID プロバイダー属性マッピングの指定
<a name="cognito-user-pools-specifying-attribute-mapping-cli-api"></a>

次の [CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html) または [UpdateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html) のリクエスト本文は、SAML プロバイダーの「MyIdP」属性 `emailaddress`、`birthdate`、`phone` を、ユーザープール属性 `email`、`birthdate`、`phone_number` に (この順序で) マッピングします。これは SAML 2.0 プロバイダーの完全なリクエスト本文です。リクエスト本文は IdP タイプと特定の詳細によって異なります。属性マッピングは `AttributeMapping` パラメータにあります。

```
{
   "AttributeMapping": { 
      "email" : "emailaddress",
      "birthdate" : "birthdate",
      "phone_number" : "phone"
   },
   "IdpIdentifiers": [ 
      "IdP1",
      "pdxsaml"
   ],
   "ProviderDetails": { 
      "IDPInit": "true", 
      "IDPSignout": "true", 
      "EncryptedResponses" : "true", 
      "MetadataURL": "https://auth.example.com/sso/saml/metadata", 
      "RequestSigningAlgorithm": "rsa-sha256"
   },
   "ProviderName": "MyIdP",
   "ProviderType": "SAML",
   "UserPoolId": "us-west-2_EXAMPLE"
}
```

以下のコマンドを使用して、ユーザープールの IdP 属性マッピングを指定します。

**プロバイダーの作成時に属性マッピングを指定する**
+ AWS CLI: `aws cognito-idp create-identity-provider`

  メタデータファイルの例: `aws cognito-idp create-identity-provider --user-pool-id <user_pool_id> --provider-name=SAML_provider_1 --provider-type SAML --provider-details file:///details.json --attribute-mapping email=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`

  ここでは `details.json` に以下が含まれます。

  ```
  { 
      "MetadataFile": "<SAML metadata XML>"
  }
  ```
**注記**  
*<SAML メタデータ XML>* に引用符が (`"`) 含まれる場合は、エスケープ (`\"`) する必要があります。

  メタデータ URL の例:

  ```
  aws cognito-idp create-identity-provider \
  --user-pool-id us-east-1_EXAMPLE \
  --provider-name=SAML_provider_1 \
  --provider-type SAML \
  --provider-details MetadataURL=https://myidp.example.com/saml/metadata \
  --attribute-mapping email=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  ```
+ API/SDK: [CreateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateIdentityProvider.html)

**既存の IdP の属性マッピングを指定するには**
+ AWS CLI: `aws cognito-idp update-identity-provider`

  例: `aws cognito-idp update-identity-provider --user-pool-id <user_pool_id> --provider-name <provider_name> --attribute-mapping email=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`
+ API/SDK: [UpdateIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateIdentityProvider.html)

**特定の IdP の属性マッピングに関する情報を取得するには**
+ AWS CLI: `aws cognito-idp describe-identity-provider`

  例: `aws cognito-idp describe-identity-provider --user-pool-id <user_pool_id> --provider-name <provider_name>`
+ API/SDK: [DescribeIdentityProvider](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeIdentityProvider.html)

# フェデレーションユーザーを既存のユーザープロファイルにリンクする
<a name="cognito-user-pools-identity-federation-consolidate-users"></a>

多くの場合、同じユーザーが、ユーザープールに接続している複数の ID プロバイダー (IdP) にプロファイルを持っています。Amazon Cognito では、ユーザーが出現するたびにディレクトリ内の同じユーザープロファイルにリンクできます。このようにして、複数の IdP ユーザーを持つ 1 人のユーザーが、アプリで一貫したエクスペリエンスを持つことができます。[AdminLinkProviderForUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminLinkProviderForUser.html) は、フェデレーションディレクトリ内のユーザーの一意の ID をユーザープール内のユーザーとして認識するように Amazon Cognito に指示します。ユーザープール内のユーザーは、ユーザープロファイルに関連付けられているフェデレーション ID が 0 個以上ある場合、[課金](https://aws.amazon.com/cognito/pricing/)の目的で 1 人の月間アクティブユーザー (MAU) としてカウントされます。

フェデレーションユーザーが初めてユーザープールにサインインすると、Amazon Cognito はその ID にリンクされたローカルプロファイルを探します。リンクされたプロファイルが存在しない場合、ユーザープールは新しいプロファイルを作成します。ローカルプロファイルを作成して、`AdminLinkProviderForUser` API リクエストで、計画されたプリステージタスクまたは [サインアップ前の Lambda トリガー](user-pool-lambda-pre-sign-up.md) のいずれかで初めてサインインする前に、フェデレーションユーザーにいつでもリンクできます。ユーザーがサインインし、Amazon Cognito がリンクされたローカルプロファイルを検出すると、ユーザープールはユーザーのクレームを読み取り、IdP のマッピングルールと比較します。次に、ユーザープールは、ログイン時にマッピングされたクレームを反映して、リンクされたローカルプロファイルを更新します。これにより、アクセスクレームを使用してローカルプロファイルを設定し、ID クレームをプロバイダーとの間で最新の状態に保つことができます。Amazon Cognito により、フェデレーションユーザーとリンクされたプロファイルがマッチングされると、フェデレーションユーザーは常にそのプロファイルにサインインします。次に、ユーザーの他のプロバイダー ID を同じプロファイルにリンクして、ユーザーのアプリエクスペリエンスを一貫させることができます。以前にサインインしたフェデレーションユーザーをリンクするには、まず既存のプロファイルを削除する必要があります。既存のプロファイルは、`[Provider name]_identifier` という形式で識別できます。例えば、`LoginWithAmazon_amzn1.account.AFAEXAMPLE`。ユーザーを作成してサードパーティーユーザー ID にリンクした場合、そのユーザーは、作成時につけられたユーザー名と、リンクされた ID の詳細を含む `identities` 属性を持つことになります。

**重要**  
`AdminLinkProviderForUser` は、外部フェデレーション ID を持つユーザーが、ユーザープール内の既存のユーザーとしてサインインすることを許可するため、アプリケーション所有者によって信頼されている外部 IdP およびプロバイダー属性でのみ使用されることが重要です。

例えば、複数のお客様と共有するアプリを使用するマネージドサービスプロバイダー (MSP) の場合です。お客様はそれぞれ、Active Directory Federation Services (ADFS) を使用してアプリにサインインします。IT 管理者 Carlos は、各お客様のドメインにアカウントを持っています。IdP に関係なく、Carlos がサインインするたびにアプリ管理者として認識されるようにします。

ADFS IdP は、Carlos の SAML アサーションの `email` クレームで Carlos の E メールアドレス `msp_carlos@example.com` を Amazon Cognito に提示します。ユーザー名 `Carlos` を使用してユーザープールにユーザーを作成します。以下の AWS Command Line Interface (AWS CLI) コマンドは、IdPs ADFS1、ADFS2、ADFS3 から Carlos の ID をリンクします。

**注記**  
特定の属性クレームに基づいてユーザーをリンクできます。この機能は OIDC と SAML IdP に固有のものです。他のプロバイダータイプでは、固定ソース属性に基づいてリンクする必要があります。詳細については、「[AdminLinkProviderForUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminLinkProviderForUser.html)」を参照してください。ソーシャル IdP をユーザープロファイルにリンクするとき、`ProviderAttributeName` に `Cognito_Subject` を設定する必要があります。`ProviderAttributeValue` は、IdP のユーザーの一意の識別子でなければなりません。

```
aws cognito-idp admin-link-provider-for-user \
--user-pool-id us-east-1_EXAMPLE \
--destination-user ProviderAttributeValue=Carlos,ProviderName=Cognito \
--source-user ProviderName=ADFS1,ProviderAttributeName=email,ProviderAttributeValue=msp_carlos@example.com

aws cognito-idp admin-link-provider-for-user \
--user-pool-id us-east-1_EXAMPLE \
--destination-user ProviderAttributeValue=Carlos,ProviderName=Cognito \
--source-user ProviderName=ADFS2,ProviderAttributeName=email,ProviderAttributeValue=msp_carlos@example.com

aws cognito-idp admin-link-provider-for-user \
--user-pool-id us-east-1_EXAMPLE \
--destination-user ProviderAttributeValue=Carlos,ProviderName=Cognito \
--source-user ProviderName=ADFS3,ProviderAttributeName=email,ProviderAttributeValue=msp_carlos@example.com
```

ユーザープールのユーザープロファイル `Carlos` は、次の `identities` 属性を持つようになりました。

```
[{
    "userId": "msp_carlos@example.com",
    "providerName": "ADFS1",
    "providerType": "SAML",
    "issuer": "http://auth.example.com",
    "primary": false,
    "dateCreated": 111111111111111
}, {
    "userId": "msp_carlos@example.com",
    "providerName": "ADFS2",
    "providerType": "SAML",
    "issuer": "http://auth2.example.com",
    "primary": false,
    "dateCreated": 111111111111111
}, {
    "userId": "msp_carlos@example.com",
    "providerName": "ADFS3",
    "providerType": "SAML",
    "issuer": "http://auth3.example.com",
    "primary": false,
    "dateCreated": 111111111111111
}]
```

**フェデレーションユーザーのリンクについて知っておくべきこと**
+ 各ユーザープロファイルに最大 5 人のフェデレーションユーザーをリンクできます。
+ `AdminLinkProviderForUser` API リクエストにおける `SourceUser` の `ProviderAttributeName` パラメータで定義されているように、最大 5 つの IdP 属性クレームから各 IdP にユーザーをリンクできます。例えば、少なくとも 1 人のユーザーをソース属性 `email`、`phone`、`department`、`given_name`、`location` にリンクしている場合、これらの 5 つの属性のいずれかにおいてのみ追加ユーザーをリンクできます。
+ フェデレーションユーザーは、既存のフェデレーションユーザープロファイルまたはローカルユーザーにリンクできます。
+ のユーザープロファイルにプロバイダーをリンクすることはできません AWS マネジメントコンソール。
+ ユーザーの ID トークンには、`identities` クレームに関連するすべてのプロバイダーが含まれます。
+ [AdminSetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html) API リクエストで、自動的に作成されたフェデレーションユーザープロファイルのパスワードを設定できます。その後、そのユーザーのステータスは `EXTERNAL_PROVIDER` から `CONFIRMED` に変わります。この状態のユーザーは、フェデレーションユーザーとしてサインインし、リンクされたローカルユーザーのように API で認証フローを開始できます。また、[ChangePassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ChangePassword.html) や [UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html) などのトークン認証された API リクエストでパスワードや属性を変更することもできます。セキュリティのベストプラクティスとして、またユーザーを外部 IdP と同期した状態を維持するため、フェデレーションユーザープロファイルにパスワードを設定しないでください。代わりに、`AdminLinkProviderForUser` でユーザーをローカルプロファイルにリンクしてください。
+ Amazon Cognito は、ユーザーが IdP からサインインするときに、リンクされたローカルユーザープロファイルにユーザー属性を入力します。Amazon Cognito は OIDC IdP からの ID トークン内のアイデンティティ要求を処理し、OAuth 2.0 プロバイダーと OIDC プロバイダー両方の `userInfo` エンドポイントもチェックします。Amazon Cognito では、ID トークン内の情報は `userInfo` からの情報よりも優先されます。

プロファイルにリンクした外部ユーザーアカウントをユーザーが使用しなくなった場合は、ユーザーアカウントとユーザープールユーザーとの関連付けを解除できます。ユーザーをリンクしたときに、ユーザーの属性名、属性値、プロバイダー名をリクエストに入力しました。ユーザーに不要となったプロファイルを削除するには、同じパラメータを指定して [AdminDisableProviderForUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminDisableProviderForUser.html) API リクエストを行います。

 AWS SDK での追加のコマンド構文と例については、「[AdminLinkProviderForUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminLinkProviderForUser.html)」を参照してください。

# ユーザープールのマネージドログイン
<a name="cognito-user-pools-managed-login"></a>

ユーザープールのサービスをホストするウェブドメインを選択できます。ドメインを追加すると、Amazon Cognito ユーザープールで、以下の機能が利用可能になります。これらの機能を総称して*マネージドログイン*と呼びます。
+ [認可サーバー](https://datatracker.ietf.org/doc/html/rfc6749#section-1.1)。OAuth 2.0 および OpenID Connect (OIDC) と連携するアプリケーションに対して ID プロバイダー (IdP) として機能します。認可サーバーは、[リクエストのルーティング](authorization-endpoint.md)、[JSON ウェブトークン (JWT) の発行と管理](token-endpoint.md)、[ユーザー属性情報の配信](userinfo-endpoint.md)を行います。
+ すぐに使用できるユーザーインターフェイス (UI)。サインイン、サインアウト、パスワード管理などの認証オペレーション用です。*マネージドログインページ*は、認証サービスのウェブフロントエンドとして機能します。
+ サービスプロバイダー (SP) または依拠しているパーティ (RP)。SAML 2.0 IdP、OIDC IdP、Facebook、Amazon でログイン、Apple でサインイン、Google に役立ちます。

マネージドログインと一部の機能を共有する追加のオプションとして、クラシックの*ホストされた UI* があります。クラシックのホストされた UI は、マネージドログインサービスの第 1 世代バージョンです。ホストされた UI の IdP および RP サービスは、通常、マネージドログインと同じ特性を備えていますが、ログインページの設計がよりシンプルで、機能数も少なくなっています。例えば、パスキーサインインは、クラシックのホストされた UI では利用できません。ライト[機能プラン](cognito-sign-in-feature-plans.md)の場合、クラシックのホストされた UI は、ユーザープールドメインサービスの唯一のオプションです。

マネージドログインページは、ユーザープールでの基本的なサインアップ、サインイン、多要素認証、およびパスワードリセットの各アクティビティを実行するためのウェブインターフェイスの集合です。また、ユーザーにサインインオプションの選択肢を提供する際に、ユーザーを 1 つ以上のサードパーティ ID プロバイダー (IdP) に接続します。アプリケーションは、ユーザーの認証と認可が必要なときに、ユーザーのブラウザでマネージドログインページを起動できます。

マネージドログインのユーザーエクスペリエンスは、カスタムロゴ、背景、スタイルを使用してブランディングに合わせることができます。マネージドログイン UI に適用できるブランディングの 2 つのオプションとして、マネージドログイン用の*ブランディングエディタ*と、ホストされた UI 用の*ホステッド UI (クラシック) ブランディング*があります。

**ブランディングエディタ**  
Amazon Cognito コンソールの最新の認証オプションとビジュアルエディタを反映して更新されたユーザーエクスペリエンス。

**ホステッド UI ブランディング**  
Amazon Cognito ユーザープールの従来の利用者には、使い慣れたユーザーエクスペリエンスです。ホステッド UI ブランディングは、ファイルベースのシステムです。ホストされた UI ページにブランディングを適用するには、ロゴイメージファイルと、いくつかの事前定義された CSS スタイルオプションの値を設定するファイルをアップロードします。

ブランディングエディタは、ユーザープールのすべての機能プランで利用できるわけではありません。詳細については、「[ユーザープールの機能プラン](cognito-sign-in-feature-plans.md)」を参照してください。

マネージドログインおよびホストされた UI のサービスへのリクエストを構築する方法の詳細については、「[ユーザープールのエンドポイントとマネージドログインのリファレンス](cognito-userpools-server-contract-reference.md)」を参照してください。

**注記**  
Amazon Cognito マネージドログインは、[カスタム認証チャレンジの Lambda トリガー](user-pool-lambda-challenge.md)を使用したカスタム認証をサポートしていません。

**Topics**
+ [マネージドログインのローカリゼーション](#managed-login-localization)
+ [規約ドキュメント](#managed-login-terms-documents)
+ [を使用したマネージドログインの設定 AWS Amplify](#cognito-user-pools-app-integration-amplify)
+ [Amazon Cognito コンソールでのマネージドログインの設定](#set-up-managed-login)
+ [サインインページの表示](#view-login-pages)
+ [認証ページのカスタマイズ](#cognito-user-pools-app-integration-customize-hosted-ui)
+ [マネージドログインとホストされた UI について知っておくべきこと](#managed-login-things-to-know)
+ [ユーザープールのドメインを設定する](cognito-user-pools-assign-domain.md)
+ [マネージドログインページにブランディングを適用する](managed-login-branding.md)

## マネージドログインのローカリゼーション
<a name="managed-login-localization"></a>

マネージドログインでは、ユーザーインタラクティブページのデフォルト言語が英語になっています。マネージドログインページは、希望する言語にローカライズして表示できます。利用可能な言語は、 AWS マネジメントコンソールで利用できる言語です。ユーザーに配信するリンクに、次の例に示すように、`lang` クエリパラメータを追加してください。

```
https://<your domain>/oauth2/authorize?lang=es&response_type=code&client_id=<your app client id>&redirect_uri=<your relying-party url>
```

Amazon Cognito は、`lang` パラメータを含む最初のリクエストを受け取ると、その言語設定を Cookie としてユーザーのブラウザに設定します。Cookie が設定されると、言語の選択は保持されるため、以降のリクエストではパラメータを表示したり、含めたりする必要がなくなります。例えば、サインインリクエストに `lang=de` パラメータを含めると、Cookie をクリアするか、`lang=en` などの新しいローカリゼーションパラメータを使用して新しいリクエストを行うまで、マネージドログインページはドイツ語で表示されます。

ローカリゼーションはマネージドログインでのみ可能です。[マネージドログインブランディング](managed-login-branding.md)を使用するには、[機能プラン](cognito-sign-in-feature-plans.md)がエッセンシャルまたはプラスであり、ドメインを割り当てている必要があります。

ユーザーがマネージドログインで行った選択は、[カスタム E メールまたは SMS 送信者トリガー](user-pool-lambda-custom-sender-triggers.md)では使用できません。これらのトリガーを実装するときは、他のメカニズムを使用してユーザーの希望する言語を特定する必要があります。サインインフローでは、`locale` 属性により、ユーザーの所在地に応じた言語が示される場合があります。サインアップフローでは、ユーザープールのリージョンまたはアプリケーションクライアント ID により、言語設定が示される場合があります。

以下の言語を使用できます。


**マネージドログインの言語**  

| Language | コード | 
| --- | --- | 
| German | de | 
| 英語 | en | 
| Spanish | es | 
| French | fr | 
| バハサインドネシア語 | id | 
| イタリア語 | これ | 
| 日本語 | ja | 
| 韓国語 | ko | 
| ポルトガル語 (ブラジル) | pt-BR | 
| 簡体字中国語 | zh-CN | 
| 繁体字中国語 | zh-TW | 

## 規約ドキュメント
<a name="managed-login-terms-documents"></a>

ユーザーのサインアップ時に、**利用規約**や**プライバシーポリシー**ドキュメントへのリンクを表示するように、マネージドログインページを設定できます。アプリケーションクライアントで両方の規約ドキュメントを設定すると、ユーザーのサインアップ時に「**サインアップすることで、利用規約とプライバシーポリシーに同意したものとみなされます**」というテキストが表示されます。マネージドログインページに **[利用規約]** と **[プライバシーポリシー]** の文字が表示され、ドキュメントにハイパーリンクされます。

規約ドキュメントは、マネージドログインのローカリゼーションに対応した言語固有の URL をサポートしています。ユーザーが `lang` クエリパラメータを使用して言語を選択すると、Amazon Cognito はその言語の規約ドキュメントへのリンクを表示します。特定の言語の URL を設定していない場合、Amazon Cognito はアプリケーションクライアント用に設定したデフォルトの URL を使用します。

アプリケーションクライアントの規約ドキュメントを設定するには、ユーザープールの **[マネージドログイン]** メニューに移動します。**[規約ドキュメント]** で **[規約ドキュメントを作成]** を選択します。

------
#### [ Amazon Cognito console ]

**規約ドキュメントを作成するには**

1. ユーザープールに移動し、**[マネージドログイン]** メニューを選択します。**[規約ドキュメント]** を見つけます。

1. **[規約ドキュメントを作成]** を選択します。

1. 規約ドキュメントを割り当てる先のアプリケーションクライアントを選択します。

1. **[規約名]** に入力します。コンソールでドキュメントを識別するために使用します。

1. **[リンク]** の下の **[言語]** で言語を選択し、**[URL]** にその言語で規約ドキュメントをホストする URL を入力します。

1. 他の言語の URL を追加するには、**[別のものを追加]** を選択します。

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

------
#### [ Amazon Cognito user pools API ]

[CreateTerms](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateTerms.html) リクエスト本文の例を次に示します。これにより、マネージドログインが該当言語にローカライズされている場合、アプリケーションクライアント `1example23456789` のサインアップページには、フランス語とポルトガル語 (ブラジル) バージョンのプライバシーポリシーへのリンクが表示されます。マネージドログインのサインアップページにリンクを表示するには、事前に `terms-of-use` の URL を設定するための別のリクエストが必要です。

```
{
   "ClientId": "1example23456789",
   "Enforcement": "NONE",
   "Links": { 
      "cognito:default" : "https://example.com/privacy/",
      "cognito:french" : "https://example.com/fr/privacy/",
      "cognito:portuguese-brazil" : "https://example.com/pt/privacy/"
   },
   "TermsName": "privacy-policy",
   "TermsSource": "LINK",
   "UserPoolId": "us-east-1_EXAMPLE"
}
```

------

**注記**  
Amazon Cognito のマネージドログインページに規約ドキュメントを表示するには、事前にアプリケーションクライアントの利用規約とプライバシーポリシードキュメントの両方を作成する必要があります。

## を使用したマネージドログインの設定 AWS Amplify
<a name="cognito-user-pools-app-integration-amplify"></a>

 AWS Amplify を使用してウェブまたはモバイルアプリに認証を追加する場合は、Amplify コマンドラインインターフェイス (CLI) のマネージドログインページと Amplify フレームワークのライブラリを設定できます。アプリケーションに認証を追加するには、`Auth` カテゴリをプロジェクトに追加します。次に、アプリケーションで Amplify クライアントライブラリを使用してユーザープールユーザーを認証します。

認証のためにマネージドログインページを呼び出すことも、IdP にリダイレクトする承認エンドポイントを介してユーザーをフェデレーションすることもできます。ユーザーがプロバイダーで正常に認証されると、Amplify は、ユーザープールに新しいユーザーを作成し、ユーザーのトークンをアプリケーションに渡します。

次の例は、 AWS Amplify を使用してアプリでソーシャルプロバイダーによるマネージドログインを設定する方法を示しています。
+ [React](https://docs.amplify.aws/react/build-a-backend/auth/concepts/external-identity-providers/)
+ [Swift](https://docs.amplify.aws/swift/build-a-backend/auth/concepts/external-identity-providers/)
+ [Flutter](https://docs.amplify.aws/flutter/build-a-backend/auth/concepts/external-identity-providers/)
+ [Android](https://docs.amplify.aws/android/build-a-backend/auth/concepts/external-identity-providers/)

## Amazon Cognito コンソールでのマネージドログインの設定
<a name="set-up-managed-login"></a>

マネージドログインとホストされた UI の最初の要件は、ユーザープールドメインです。ユーザープールコンソールで、ユーザープールの**[ドメイン]** タブに移動し、**Cognito ドメイン**または**カスタムドメイン**を追加します。新しいユーザープールを作成するプロセス中にドメインを選択することもできます。詳細については、「[ユーザープールのドメインを設定する](cognito-user-pools-assign-domain.md)」を参照してください。ユーザープールでドメインがアクティブな場合、すべてのアプリケーションクライアントは、そのドメインでパブリック認証ページを提供します。

ユーザープールドメインを作成または変更するときに、ドメインの**ブランディングバージョン**を設定します。ブランディングバージョンとして、**[マネージドログイン]** または **[ホストされた UI (クラシック)]** のいずれかを選択できます。選択したブランディングバージョンは、ドメインでサインインサービスを使用するすべてのアプリケーションクライアントに適用されます。

次のステップでは、ユーザープールの [[アプリケーションクライアント]](user-pool-settings-client-apps.md) タブで **[アプリケーションクライアント]** を作成します。アプリケーションクライアントを作成するプロセスで、Amazon Cognito はアプリケーションに関する情報の入力と、**リターン URL** の選択を求めます。リターン URL は、依拠しているパーティ(RP) の URL、リダイレクト URI、コールバック URL とも呼ばれます。これは、`https://www.example.com` や `myapp://example` など、アプリケーションの実行元の URL です。

ユーザープールでブランディングスタイルを使用してドメインとアプリケーションクライアントを設定すると、マネージドログインページがインターネットで利用可能になります。

## サインインページの表示
<a name="view-login-pages"></a>

Amazon Cognito コンソールの **[アプリケーションクライアント]** メニューで、アプリケーションクライアントの **[ログインページ]** タブにある **[ログインページを表示]** ボタンを選択します。このボタンを選択すると、ユーザープールドメインのサインインページに移動し、以下の基本パラメータが表示されます。
+ アプリクライアント ID
+ 認可コード付与リクエスト
+ 現在のアプリクライアント用に有効にしたすべてのスコープのリクエスト
+ 現在のアプリクライアントのリストにある最初のコールバック URL

**[ログインページを表示]** ボタンは、マネージドログインページの基本機能をテストする場合に便利です。ログインページは、[ユーザープールドメイン](cognito-user-pools-assign-domain.md)に割り当てた**ブランディングバージョン**と一致します。パラメータを追加または変更して、サインイン URL をカスタマイズできます。ほとんどの場合、**[ログインページを表示]** リンクの自動生成されたパラメータは、アプリのニーズに完全には一致しません。このような場合は、ユーザーのサインイン時にアプリが呼び出す URL をカスタマイズする必要があります。サインインパラメータのキーと値の詳細については、「[ユーザープールのエンドポイントとマネージドログインのリファレンス](cognito-userpools-server-contract-reference.md)」を参照してください。

サインインウェブページでは、次の URL 形式を使用します。この例では、`response_type=code` パラメーターを使って認可コードの付与をリクエストしています。

```
https://<your domain>/oauth2/authorize?response_type=code&client_id=<your app client id>&redirect_uri=<your relying-party url>
```

ユーザープールの **[ドメイン]** メニューでは、ユーザープールドメイン文字列を検索できます。**[アプリケーションクライアント]** メニューでは、アプリクライアント ID、コールバック URL、許可されているスコープ、その他の設定を確認できます。

カスタムパラメータを使用して `/oauth2/authorize` エンドポイントに移動すると、Amazon Cognito は `/oauth2/login` エンドポイントにリダイレクトするか、`identity_provider` または `idp_identifier` パラメータがある場合は、IdP サインインページにそのままリダイレクトします。

**暗黙的な付与のリクエスト例**  
`response_type=token` を使用した暗黙的なコード付与で、次の URL により、サインインウェブページを表示できます。サインインが正常に行われると、Amazon Cognito がユーザープールトークンをウェブブラウザのアドレスバーに返します。

```
            https://mydomain.auth.us-east-1.amazoncognito.com/authorize?response_type=token&client_id=1example23456789&redirect_uri=https://mydomain.example.com
```

ID トークンとアクセストークンは、リダイレクト URL に追加されるパラメーターとして表示されます。

ここでは、暗黙的な許可リクエストからのレスポンス例を示します。

```
            https://auth.example.com/#id_token=eyJraaBcDeF1234567890&access_token=eyJraGhIjKlM1112131415&expires_in=3600&token_type=Bearer  
```

## 認証ページのカスタマイズ
<a name="cognito-user-pools-app-integration-customize-hosted-ui"></a>

Amazon Cognito は、これまでクラシックの*ホストされた UI* のみを使用して、ログインページをホストしていました。ホストされた UI は、シンプルなデザインであり、認証ウェブページは一般的な外観でした。Amazon Cognito ユーザープールをカスタマイズするためにロゴイメージを使用したり、ファイルでいくつかの CSS スタイル値を指定して一部のスタイルを微調整したりすることができました。その後、Amazon Cognito は、ホストされた認証サービスを更新して、*マネージドログイン*を導入しました。マネージドログインは、*ブランディングエディタ*を備え、外観と操作感が更新されています。ブランディングエディタはノーコードのビジュアルエディタであり、ホストされた UI のカスタマイズエクスペリエンスよりも多くのオプションで構成されています。マネージドログインでは、カスタム背景画像とダークモードのテーマも導入されました。

ユーザープールでは、マネージドログインとホストされた UI 間でブランディングエクスペリエンスを切り替えることができます。マネージドログインページのカスタマイズの詳細については、「[マネージドログインページにブランディングを適用する](managed-login-branding.md)」を参照してください。

## マネージドログインとホストされた UI について知っておくべきこと
<a name="managed-login-things-to-know"></a>

**マネージドログインとホストされた UI の １ 時間のセッション Cookie**  
ユーザーがログインページまたはサードパーティプロバイダーからサインインすると、Amazon Cognito はユーザーのブラウザに Cookie を設定します。この Cookie を使用すると、1 時間以内なら、ユーザーは同じ認証方法で再度サインインできます。ブラウザ Cookie を使用してサインインすると、アプリケーションクライアント設定で指定した期間にわたり、ユーザーは新しいトークンを付与されます。ユーザー属性または認証要素を変更しても、ブラウザ Cookie を使用して再度サインインする機能には影響しません。

セッション Cookie による認証では、Cookie の期間は別の 1 時間にリセットされません。最後に成功したインタラクティブ認証から 1 時間を超えてサインインページにアクセスする場合、ユーザーは再度サインインする必要があります。

**ユーザーアカウントの確認とユーザー属性の検証**  
ユーザープールの[ローカルユーザー](cognito-terms.md#terms-localuser)の場合、マネージドログインとホストされた UI は、ユーザープールを **[Cognito が検証と確認のためにメッセージを自動的に送信することを許可]** に設定したときに最も効果的です。この設定を有効にすると、Amazon Cognito は、サインアップしたユーザーに確認コードを含むメッセージを送信します。代わりにユーザーをユーザープール管理者として確認すると、サインアップ後にログインページにエラーメッセージが表示されます。この状態で、Amazon Cognito は新しいユーザーを作成しましたが、検証メッセージを送信できませんでした。引き続きユーザーを管理者として確認することはできますが、エラーが発生すると、ユーザーはサポートデスクに連絡する可能性があります。管理者の確認の詳細については、「[ユーザーにアプリケーションへのサインアップを許可するがユーザープール管理者として確認する](signing-up-users-in-your-app.md#signing-up-users-in-your-app-and-confirming-them-as-admin)」を参照してください。

**マネージドログインのオペレーションの範囲**  
マネージドログインとクラシックのホストされた UI は、サインアップ、サインイン、パスワード管理をサポートしています。これには、多要素認証 (MFA) によるサインインの完了と WebAuthn 認証子の登録が含まれます。マネージドログインは、属性の変更や MFA の設定構成など、ユーザーによるセルフサービスのプロファイル管理をサポートしていません。プロファイル管理は、独自のアプリケーションコードに実装する必要があります。また、マネージドログインでは、[AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) API オペレーションを使用して管理者として E メールアドレスと電話番号を更新するときに、属性の変更を確認する機能も提供されていません。

**設定の変更の表示**  
ページのスタイルを変更しても、変更がすぐに反映されない場合は、数分間待ってから、ページを更新してください。

**ユーザープールトークンのデコード**  
Amazon Cognito ユーザープールトークンは、RS256 アルゴリズムを使用して署名されます。を使用して、ユーザープールトークンをデコードおよび検証できます AWS Lambda。GitHub の「[Amazon Cognito JWT トークンのデコードと検証](https://github.com/awslabs/aws-support-tools/tree/master/Cognito/decode-verify-jwt)」を参照してください。

**TLS バージョン**  
マネージドログインページとホストされた UI ページには、転送中の暗号化が必要です。Amazon Cognito が提供するユーザープールドメインでは、ユーザーのブラウザが TLS バージョン 1.2 以上をネゴシエートする必要があります。カスタムドメインは、TLS バージョン 1.2 でのブラウザ接続をサポートしています。ホストされた UI (クラシック) では、カスタムドメインに TLS 1.2 は**不要**ですが、新しいマネージドログインでは、カスタムドメインとプレフィックスドメインの両方に TLS バージョン 1.2 が**必要**です。ドメインサービスの設定は、Amazon Cognito が管理するため、ユーザープールドメインの TLS 要件を変更することはできません。

**CORS ポリシー**  
マネージドログインとホストされた UIは、どちらも、カスタムのクロスオリジンリソース共有 (CORS) オリジンポリシーをサポートしていません。CORS ポリシーにより、ユーザーがリクエストで認証パラメータを渡すことは許可されません。代わりに、アプリケーションのフロントエンドに CORS ポリシーを実装してください。Amazon Cognito は、以下のエンドポイントへのリクエストに対して `Access-Control-Allow-Origin: *` レスポンスヘッダーを返します。

1. [トークンエンドポイント](token-endpoint.md)

1. [エンドポイントの取り消し](revocation-endpoint.md)

1. [userInfo エンドポイント](userinfo-endpoint.md)

**cookie**  
マネージドログインとホストされた UI は、ユーザーのブラウザに Cookie を設定します。Cookie は、サイトがサードパーティーの Cookie を設定しない一部のブラウザの要件に準拠しています。これらはユーザープールエンドポイントのみを対象とし、以下が含まれます。
+ 各リクエストの `XSRF-TOKEN` Cookie。
+ ユーザーがリダイレクトされたときのセッション整合性のための `csrf-state` Cookie。
+ セッション整合性のための `csrf-state-legacy` Cookie。ブラウザが `SameSite` 属性をサポートしていない場合に Amazon Cognito がフォールバックとして読み取ります。
+ 成功したサインイン試行を 1 時間保持する `cognito` セッション Cookie。
+ マネージドログインでユーザーが選択した[言語ローカリゼーション](#managed-login-localization)を保持する `lang` Cookie。
+ ユーザーがマネージドログインページ間を移動するときに必須データを保持する `page-data` Cookie。

iOS では、[すべての Cookie をブロック](https://support.apple.com/en-us/105082)できます。この設定は、マネージドログインまたはホストされた UI とは互換性がありません。この設定を有効にする可能性のあるユーザーと連携するには、 AWS SDK を使用してユーザープール認証をネイティブ iOS アプリに構築します。このシナリオでは、Cookie ベースではない独自のセッションストレージを構築できます。

**マネージドログインのバージョン変更の影響**  
ドメインを追加し、マネージドログインのバージョンを設定する場合、以下の影響を考慮してください。
+ マネージドログインまたはホストされた UI (クラシック) のいずれかのブランディングを使用してプレフィックスドメインを追加した場合、ログインページが使用可能になるまでに最大 60 秒かかることがあります。
+ マネージドログインまたはホストされた UI (クラシック) のブランディングを使用してカスタムドメインを追加した場合、ログインページが使用可能になるまでに最大 5 分かかることがあります。
+ ドメインのブランディングバージョンを変更した場合、ログインページが新しいブランディングバージョンで利用可能になるまでに最大 4 分かかることがあります。
+ マネージドログインとホストされた UI (クラシック) のブランディングを切り替えると、Amazon Cognito はユーザーセッションを維持しません。ユーザーは、新しいインターフェイスで再度サインインする必要があります。

**デフォルトのスタイル**  
でアプリクライアントを作成すると AWS マネジメントコンソール、Amazon Cognito はアプリクライアントにブランドスタイルを自動的に割り当てます。[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) オペレーションを使用してプログラムでアプリケーションクライアントを作成した場合、ブランディングスタイルは作成されません。マネージドログインは、[CreateManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateManagedLoginBranding.html) リクエストでアプリケーションクライアントを作成するまで、 AWS SDK で作成されたアプリケーションクライアントでは使用できません。

**マネージドログイン認証プロンプトのタイムアウト**  
Amazon Cognito は認証リクエストが 5 分以内に完了しない場合にこれをキャンセルし、ユーザーをマネージドログインにリダイレクトします。ページには、`Something went wrong` というエラーメッセージが表示されます。

# ユーザープールのドメインを設定する
<a name="cognito-user-pools-assign-domain"></a>

ドメインの設定は、ユーザープールを設定するオプションです。ユーザープールドメインは、ユーザー認証、サードパーティープロバイダーとのフェデレーション、および OpenID Connect (OIDC) フローについての機能をホストします。*マネージドログイン*は、サインアップ、サインイン、パスワード復旧など、主要なオペレーション用の事前構築済みのインターフェイスです。また、Machine to Machine (M2M) 認可、その他の OIDC や OAuth 2.0 の認証と認可フローのために、[承認](authorization-endpoint.md)、[ユーザー情報](userinfo-endpoint.md)、[トークン](token-endpoint.md)など、OpenID Connect (OIDC) の標準エンドポイントもホストします。

ユーザーは、ユーザープールに関連付けられたドメインでマネージドログインページを使用して認証します。このドメインを設定するには、次の 2 つのオプションがあります。デフォルトの Amazon Cognito ホストドメインを使用することも、所有するカスタムドメインを設定することもできます。

カスタムドメインオプションには、柔軟性、セキュリティ、制御のためのオプションが多数用意されています。例えば、使い慣れた組織所有のドメインは、ユーザーの信頼を高めて、サインインプロセスが直感的にできます。ただし、カスタムドメインアプローチには、SSL 証明書の管理や DNS 設定など、追加のオーバーヘッドが必要です。

OIDC 検出エンドポイント (エンドポイント URL 用の `/.well-known/openid-configuration`、およびトークン署名キー用の `/.well-known/jwks.json`) はドメインでホストされません。詳細については、「[ID プロバイダーと依拠しているパーティーエンドポイント](federation-endpoints.md)」を参照してください。

ユーザープールのドメインを設定および管理する方法を理解することは、認証をアプリケーションに統合するための重要なステップです。ユーザープール API と AWS SDK を使用してサインインすることは、ドメインを設定する代わりに使用できます。API ベースのモデルは API レスポンスに直接トークンを配信しますが、ユーザープールの拡張機能を OIDC IdP として使用する実装の場合は、ドメインを設定する必要があります。ユーザープールで使用できる認証モデルの詳細については、「[API、OIDC、マネージドログインページの認証についての理解](authentication-flows-public-server-side.md#user-pools-API-operations)」を参照してください。

**Topics**
+ [ユーザープールドメインについて知っておくべきこと](#cognito-user-pools-assign-domain-things-to-know)
+ [マネージドログインに Amazon Cognito プレフィックスドメインを使用する](cognito-user-pools-assign-domain-prefix.md)
+ [マネージドログインに独自のドメインを使用する](cognito-user-pools-add-custom-domain.md)

## ユーザープールドメインについて知っておくべきこと
<a name="cognito-user-pools-assign-domain-things-to-know"></a>

ユーザープールドメインは、アプリケーション内の OIDC の依拠しているパーティー向け、および UI 向けのサービスポイントです。ユーザープールのドメインの実装を計画する場合は、次の詳細を考慮してください。

**予約済みの用語**  
Amazon Cognito プレフィックスドメイン名で `aws`、`amazon`、または `cognito` というテキストを使用することはできません。

**検出エンドポイントが別のドメインにある**  
ユーザープール[検出エンドポイント](federation-endpoints.md)の `.well-known/openid-configuration` および `.well-known/jwks.json` は、ユーザープールのカスタムドメインまたはプレフィックスドメインにはありません。これらのエンドポイントへのパスは次のとおりです。
+ `https://cognito-idp.Region.amazonaws.com/your user pool ID/.well-known/openid-configuration`
+ `https://cognito-idp.Region.amazonaws.com/your user pool ID/.well-known/jwks.json`

**ドメイン変更の所要時間**  
Amazon Cognito がプレフィックスドメインのブランディングバージョンを起動または更新するまでに最大 1 分かかる場合があります。カスタムドメインへの変更は、反映されるまでに最大 5 分かかる場合があります。新しいカスタムドメインは、反映されるまで最大 1 時間かかる場合があります。

**カスタムドメインとプレフィックスドメインを同時に**  
カスタムドメインと が所有するプレフィックスドメインの両方を使用してユーザープールを設定できます AWS。ユーザープール[検出エンドポイント](federation-endpoints.md)は別のドメインでホストされるため、*カスタムドメイン*にのみ対応します。例えば、`openid-configuration` は `"https://auth.example.com/oauth2/authorize"` の `"authorization_endpoint"` に 1 つの値を提供します。

ユーザープールにカスタムドメインとプレフィックスドメインの両方がある場合、OIDC プロバイダーのすべての機能でカスタムドメインを使用できます。この設定を持つユーザープールのプレフィックスドメインには検出エンドポイントやトークン署名キーエンドポイントがないため、それに応じて使用する必要があります。

**パスキーの依拠しているパーティの ID として優先されるカスタムドメイン**  
[パスキー](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passkey)でユーザープール認証を設定するときは、依拠しているパーティ (RP) の ID を設定する必要があります。カスタムドメインとプレフィックスドメインがある場合、RP ID はカスタムドメインとしてのみ設定できます。Amazon Cognito コンソールでプレフィックスドメインを RP ID として設定するには、カスタムドメインを削除するか、プレフィックスドメインの完全修飾ドメイン名 (FQDN) を**サードパーティのドメイン**として入力します。

**ドメイン階層の異なるレベルでカスタムドメインを使用しない**  
*auth.example.com* や *auth2.example.com* など、同じ最上位ドメイン (TLD) にカスタムドメインを持つように個別のユーザープールを設定できます。マネージドログインのセッション Cookie は、カスタムドメインと、*\$1.auth.example.com* などのすべてのサブドメインに対して有効です。このため、アプリケーションのユーザーは、親ドメイン*および*サブドメインでマネージドログインにアクセスできません。カスタムドメインが同じ TLD を使用している場合は、同じサブドメインレベルで保持します。

カスタムドメイン *auth.example.com* を持つユーザープールがあるとします。次に、別のユーザープールを作成し、カスタムドメイン *uk.auth.example.com* を割り当てるとします。ユーザーは *auth.example.com* でサインインし、ワイルドカードパス *\$1.auth.example.com* でブラウザが任意のウェブサイトに提示する Cookie を取得します。その後、*uk.auth.example.com* へのサインインを試みます。ユーザープールドメインに無効な Cookie が渡され、サインインプロンプトの代わりにエラーが返されます。対照的に、*\$1.auth.example.com* 用の Cookie を持つユーザーは、*auth2.example.com* でサインインセッションを開始しても問題ありません。

**ブランディングバージョン**  
ドメインを作成するときは、**ブランディングバージョン**を設定します。オプションは、新しいマネージドログインエクスペリエンスとクラシックのホストされた UI エクスペリエンスです。この選択は、ドメインでサービスをホストするすべてのアプリケーションクライアントに適用されます。

# マネージドログインに Amazon Cognito プレフィックスドメインを使用する
<a name="cognito-user-pools-assign-domain-prefix"></a>

マネージドログインのデフォルトのエクスペリエンスは、 AWS が所有するドメインでホストされます。このアプローチでは、プレフィックス名を選択してアクティブにできるので、エントリに対する障壁は低くなりますが、カスタムドメインの信頼感を高める機能はありません。Amazon Cognito ドメインオプションとカスタムドメインオプションの間でコスト差はありません。唯一の違いは、ユーザーに指示するウェブアドレスのドメインです。サードパーティーの IdP リダイレクトとクライアント認証情報フローの場合、ホストされたドメインはほとんど表示されません。ユーザーがマネージドログインを使用してサインインし、アプリケーションドメインと一致しない認証ドメインとやり取りする場合は、カスタムドメインの方が適しています。

ホストされた Amazon Cognito ドメインには、選択したプレフィックスがありますが、ルートドメイン `amazoncognito.com` でホストされます。以下に例を示します。

```
https://cognitoexample.auth.ap-south-1.amazoncognito.com
```

すべてのプレフィックスドメインは、次の形式に従います: `prefix`.`auth`.*`AWS リージョン code`*.`amazoncognito`.`com`。[カスタムドメイン](cognito-user-pools-add-custom-domain.md) ユーザープールは、マネージドログインまたはホストされた UI ページを、所有している任意のドメインでホストできます。

**注記**  
Amazon Cognito アプリケーションのセキュリティを強化するために、ユーザープールエンドポイントの親ドメインは[パブリックサフィックスリスト (PSL)](https://publicsuffix.org/) に登録されます。PSL は、ユーザーのウェブブラウザが、ユーザーが設定するユーザープールエンドポイントと Cookie を一貫して把握するのに役立ちます。  
ユーザープールの親ドメインは、以下の形式になります。  

```
auth.Region.amazoncognito.com
auth-fips.Region.amazoncognito.com
```

でアプリケーションクライアントとユーザープールドメインを追加するには AWS マネジメントコンソール、「」を参照してください[アプリクライアントの作成](user-pool-settings-client-apps.md#cognito-user-pools-app-idp-settings-console-create)。

**Topics**
+ [前提条件](#cognito-user-pools-assign-domain-prefix-prereq)
+ [Amazon Cognito ドメインプレフィックスを設定する](#cognito-user-pools-assign-domain-prefix-step-1)
+ [サインインページを検証する](#cognito-user-pools-assign-domain-prefix-verify)

## 前提条件
<a name="cognito-user-pools-assign-domain-prefix-prereq"></a>

開始するには、以下が必要です。
+ アプリクライアントを持つユーザープール。詳細については、「[ユーザープールの開始方法](getting-started-user-pools.md)」を参照してください。

## Amazon Cognito ドメインプレフィックスを設定する
<a name="cognito-user-pools-assign-domain-prefix-step-1"></a>

ユーザープールドメインを設定するには、 AWS マネジメントコンソール または AWS CLI または API を使用できます。

------
#### [ Amazon Cognito console ]

**ドメインを設定する**

1. **[ブランディング]** の下にある **[ドメイン]** メニューに移動します。

1. **[ドメイン]** の横で **[アクション]**、**[Cognito ドメインを作成]** の順に選択します。ユーザープールのプレフィックスドメインを設定済みである場合は、新しいカスタムドメインを作成する前に、**[Cognitoドメインの削除]** を選択します。

1. **Amazon Cognito ドメイン**で使用するための使用可能なドメインプレフィックスを入力します。**カスタムドメイン**の設定方法については、「[マネージドログインに独自のドメインを使用する](cognito-user-pools-add-custom-domain.md)」を参照してください。

1. **[ブランディングバージョン]** を選択します。ブランディングバージョンは、そのドメインのすべてのユーザーインタラクティブページに適用されます。ユーザープールは、すべてのアプリケーションクライアントでマネージドログインブランディングまたはホステッド UI ブランディングのいずれかをホストできます。
**注記**  
カスタムドメインとプレフィックスドメインを持つことができますが、Amazon Cognito は*カスタム*ドメイン用の `/.well-known/openid-configuration` エンドポイントのみを提供します。

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

------
#### [ CLI/API ]

ドメインプレフィックスを作成してユーザープールに割り当てるには、次のコマンドを使用します。

**ユーザープールのドメインを設定する**
+ AWS CLI: `aws cognito-idp create-user-pool-domain`

  **例**: `aws cognito-idp create-user-pool-domain --user-pool-id <user_pool_id> --domain <domain_name> --managed-login-version 2`
+ ユーザープールの API オペレーション: [CreateUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolDomain.html)

**ドメインに関する情報を取得する**
+ AWS CLI: `aws cognito-idp describe-user-pool-domain`

  **例**: `aws cognito-idp describe-user-pool-domain --domain <domain_name>`
+ ユーザープールの API オペレーション: [DescribeUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPoolDomain.html)

**ドメインを削除する**
+ AWS CLI: `aws cognito-idp delete-user-pool-domain`

  **例**: `aws cognito-idp delete-user-pool-domain --domain <domain_name>`
+ ユーザープールの API オペレーション: [DeleteUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserPoolDomain.html)

------

## サインインページを検証する
<a name="cognito-user-pools-assign-domain-prefix-verify"></a>
+ Amazon Cognito でホストされるドメインから、サインインページが利用可能であることを検証します。

  ```
  https://<your_domain>/login?response_type=code&client_id=<your_app_client_id>&redirect_uri=<your_callback_url>
  ```

ドメインは、Amazon Cognito コンソールの **[ドメイン名]** ページに表示されます。アプリクライアント ID およびコールバック URL は [**アプリクライアントの設定**] ページに表示されています。

# マネージドログインに独自のドメインを使用する
<a name="cognito-user-pools-add-custom-domain"></a>

アプリケーションクライアントをセットアップしたら、[マネージドログイン](cognito-user-pools-managed-login.md)のドメインサービスでカスタムドメインのユーザープールを設定できます。カスタムドメインを使用すると、ユーザーはデフォルトの[プレフィックスドメイン](cognito-user-pools-assign-domain-prefix.md) `amazoncognito.com` の代わりに、独自のウェブアドレスを使用してアプリケーションにサインインできます。カスタムドメインは、特にルートドメインがアプリケーションをホストするドメインと一致する場合、よく知られているドメイン名を使用してアプリケーションのユーザー信頼を向上させます。カスタムドメインは、組織のセキュリティ要件へのコンプライアンスを強化できます。

カスタムドメインには、ユーザープール、アプリケーションクライアント、所有するウェブドメインなど、いくつかの前提条件があります。カスタムドメインには、米国東部 (バージニア北部) の AWS Certificate Manager (ACM) で管理されるカスタムドメインの SSL 証明書も必要です。Amazon Cognito は、ACM 証明書によって転送中に保護される Amazon CloudFront ディストリビューションを作成します。ドメインを所有している場合、カスタムドメインの CloudFront ディストリビューションにトラフィックを誘導する DNS レコードを作成する必要があります。

これらの要素の準備ができたら、Amazon Cognito のコンソールまたは API を使用してカスタムドメインをユーザープールに追加できます。これには、ドメイン名と SSL 証明書を指定したうえで、指定したエイリアスターゲットで DNS 設定を更新する必要があります。これらの変更を行った後、サインインページがカスタムドメインでアクセス可能であることを検証できます。

カスタムドメインを作成する最も簡単な方法は、Amazon Route 53 のパブリックホストゾーンを使用することです。Amazon Cognito コンソールでは、適切な DNS レコードを数ステップで作成できます。開始する前に、所有しているドメインまたはサブドメイン用の [Route 53 ホストゾーンを作成する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html)ことを検討してください。

**Topics**
+ [ユーザープールへのカスタムドメインの追加](#cognito-user-pools-add-custom-domain-adding)
+ [前提条件](#cognito-user-pools-add-custom-domain-prereq)
+ [ステップ 1: カスタムドメイン名を入力する](#cognito-user-pools-add-custom-domain-console-step-1)
+ [ステップ 2: エイリアスターゲットとサブドメインを追加する](#cognito-user-pools-add-custom-domain-console-step-2)
+ [ステップ 3: サインインページを検証する](#cognito-user-pools-add-custom-domain-console-step-3)
+ [カスタムドメインの SSL 証明書を変更する](#cognito-user-pools-add-custom-domain-changing-certificate)

## ユーザープールへのカスタムドメインの追加
<a name="cognito-user-pools-add-custom-domain-adding"></a>

カスタムドメインをユーザープールに追加するには、Amazon Cognito コンソールでドメイン名を指定し、[AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/) (ACM) を使用してユーザー管理の証明書を提供します。ドメインを追加したら、Amazon Cognito がエイリアスターゲットを提供するので、これを DNS 設定に追加します。

## 前提条件
<a name="cognito-user-pools-add-custom-domain-prereq"></a>

開始するには、以下が必要です。
+ アプリクライアントを持つユーザープール。詳細については、「[ユーザープールの開始方法](getting-started-user-pools.md)」を参照してください。
+ 所有するウェブドメイン。その*親ドメイン*には、DNS に有効な **A レコード**が必要です。このレコードには任意の値を割り当てることができます。親は、ドメインのルート、またはドメイン階層の 1 つ上の子ドメインです。例えば、カスタムドメインが *auth.xyz.example.com* である場合、Amazon Cognito は *xyz.example.com* を IP アドレスに解決できることが必要です。お客様のインフラストラクチャへの偶発的な影響を防ぐため、Amazon Cognito は、最上位ドメイン (TLD) のカスタムドメインへの使用をサポートしていません。詳細については、「[ドメイン名](https://tools.ietf.org/html/rfc1035)」を参照してください。
+ カスタムドメインのサブドメインを作成する機能。サブドメイン名としては、**auth** をお勧めします。たとえば、「*auth.example.com*」を使用します。
**注記**  
「[ワイルドカード証明書](https://en.wikipedia.org/wiki/Wildcard_certificate)」がない場合は、カスタムドメインのサブドメイン用に新しい証明書の取得が必要な場合があります。
+ 米国東部 (バージニア北部) の ACM によって管理されるパブリック SSL/TLS 証明書。証明書はグローバルサービスである CloudFront のディストリビューションに関連付けられるため、証明書は us-east-1 に配置する必要があります。
+ Server Name Indication (SNI) をサポートするブラウザクライアント。Amazon Cognito がカスタムドメインに割り当てる CloudFront ディストリビューションには SNI が必要です。この設定は変更できません。CloudFront ディストリビューションの SNI の詳細については、「*Amazon CloudFront デベロッパーガイド*」の「[SNI を使用して HTTPS リクエストを処理する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-https-dedicated-ip-or-sni.html#cnames-https-sni)」を参照してください。
+ ユーザープール認可サーバーがユーザーセッションに Cookie を追加することを許可するアプリケーション。Amazon Cognito は、マネージドログインページに必要ないくつかの Cookie を設定します。`cognito`、`cognito-fl`、`XSRF-TOKEN` などです。個々の Cookie はブラウザのサイズ制限に適合していますが、ユーザープールの設定を変更すると、マネージドログインの Cookie のサイズが大きくなる可能性があります。カスタムドメインの前の Application Load Balancer (ALB) などの中間サービスでは、ヘッダーの最大サイズまたは Cookie の合計サイズが適用される場合があります。アプリケーションが独自の Cookie も設定している場合、ユーザーのセッションはこれらの制限を超える可能性があります。サイズ制限の競合を避けるため、アプリケーションでは、ユーザープールのドメインサービスをホストするサブドメインに Cookie を設定しないようお勧めします。
+ Amazon CloudFront ディストリビューションを更新するアクセス許可。そのためには、次の IAM ポリシーステートメントを AWS アカウントのユーザーにアタッチします。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
           {
              "Sid": "AllowCloudFrontUpdateDistribution",
              "Effect": "Allow",
              "Action": [
                  "cloudfront:updateDistribution"
              ],
              "Resource": [
                  "*"
              ]
          }
      ]
  }
  ```

------

  CloudFront でのアクションの承認の詳細については、「[CloudFront でのアイデンティティベースのポリシー (IAM ポリシー) の使用](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/access-control-managing-permissions.html)」を参照してください。

  Amazon Cognito は、最初に IAM アクセス許可を使用して CloudFront ディストリビューションを設定しますが、ディストリビューションは AWSによって管理されます。Amazon Cognito がユーザープールに関連付けた CloudFront ディストリビューションの設定を変更することはできません。例えば、セキュリティポリシーでサポートされている TLS バージョンを更新することはできません。

## ステップ 1: カスタムドメイン名を入力する
<a name="cognito-user-pools-add-custom-domain-console-step-1"></a>

ドメインは、Amazon Cognito コンソールまたは API を使用することでユーザープールに追加できます。

------
#### [ Amazon Cognito console ]

**Amazon Cognito コンソールからユーザープールにドメインを追加する。**

1. **[ブランディング]** の下にある **[ドメイン]** メニューに移動します。

1. **[ドメイン]** の横で、**[アクション]** を選択し、**[カスタムドメインの作成]** または **[Amazon Cognito ドメインの作成]** のどちらかを選択します。ユーザープールのカスタムドメインを設定済みである場合は、新しいカスタムドメインを作成する前に、**[カスタムドメインを削除]** を選択します。

1. **[ドメイン]** の横にある **[アクション]** を選択し、**[カスタムドメインを作成]** を選択します。カスタムドメインを設定済みである場合は、新しいカスタムドメインを作成する前に、**[カスタムドメインを削除]** を選択して既存のドメインを削除します。

1. **[Custom domain]** (カスタムドメイン) には、Amazon Cognito で使用するドメインの URL を入力します。ドメイン名で使用できるのは、小文字の英文字、数字、およびハイフンのみです。最初または最後の文字にハイフンを使用しないでください。サブドメイン名は、ピリオドで区切ります。

1. **[ACM certificate]** (ACM 証明書) には、ドメインに使用する SSL 証明書を選択します。ユーザープールの に関係なく、Amazon Cognito カスタムドメインで使用できるのは、米国東部 (バージニア北部) AWS リージョン の ACM 証明書のみです。

   利用可能な証明書がない場合は、ACM を使用して米国東部 (バージニア北部) にプロビジョニングできます。詳細については、*AWS Certificate Manager ユーザーガイド*の「[使用開始](https://docs.aws.amazon.com/acm/latest/userguide/gs.html)」を参照してください。

1. **[ブランディングバージョン]** を選択します。ブランディングバージョンは、そのドメインのすべてのユーザーインタラクティブページに適用されます。ユーザープールは、すべてのアプリケーションクライアントでマネージドログインブランディングまたはホステッド UI ブランディングのいずれかをホストできます。
**注記**  
カスタムドメインとプレフィックスドメインを持つことができますが、Amazon Cognito は*カスタム*ドメイン用の `/.well-known/openid-configuration` エンドポイントのみを提供します。

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

1. Amazon Cognito は **[ドメイン]** メニューに戻ります。メッセージ「**Create an alias record in your domain's DNS**」(ドメインの DNS にエイリアスレコードを作成する) が表示されます。コンソールに表示される **[Domain]** (ドメイン) と **[Alias target]** (エイリアスターゲット) を書き留めます。これらは、次のステップでカスタムドメインにトラフィックを転送するために使用します。

------
#### [ API ]

次の [CreateUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolDomain.html) リクエスト本文では、カスタムドメインを作成します。

```
{
   "Domain": "auth.example.com",
   "UserPoolId": "us-east-1_EXAMPLE",
   "ManagedLoginVersion": 2,
   "CustomDomainConfig": {
    "CertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
   }
}
```

------

## ステップ 2: エイリアスターゲットとサブドメインを追加する
<a name="cognito-user-pools-add-custom-domain-console-step-2"></a>

このステップでは、ドメイン名サーバー (DNS) サービスプロバイダーを使用して、前のステップのエイリアスターゲットを指すエイリアスを設定します。DNS アドレスの解決に Amazon Route 53 を使用している場合は、**Route 53 を使用してエイリアスターゲットとサブドメインを追加する**セクションを選択します。

### エイリアスターゲットおよびサブドメインを現在の DNS 設定に追加する
<a name="cognito-user-pools-add-custom-domain-console-step-2a"></a>
+ DNS アドレス解決に Route 53 を使用していない場合は、DNS サービスプロバイダーの設定ツールを使用して、前のステップで設定したエイリアスターゲットをドメインの DNS レコードに追加する必要があります。また、DNS プロバイダーで、カスタムドメインのサブドメインを設定する必要があります。

### Route 53 を使用してエイリアスターゲットとサブドメインを追加する
<a name="cognito-user-pools-add-custom-domain-console-step-2b"></a>

1. [Route 53 コンソール](https://console.aws.amazon.com/route53/)にサインインします。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. Route 53 にパブリックホストゾーンがない場合は、カスタムドメインの親であるルートでパブリックホストゾーンを作成します。詳細については、「*Amazon Route 53 デベロッパーガイド*」の「[Creating a public hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html)」を参照してください。

   1. **[ホストゾーンの作成]** を選択します。

   1. **ドメイン名**のリストから、カスタムドメイン *myapp.auth.example.com* の親ドメイン *auth.example.com* を入力します。

   1. ホストゾーンの**説明**を入力します。

   1. **パブリックホストゾーン**のホストゾーン **[Type]** (タイプ) を選択して、パブリッククライアントがカスタムドメインを解決できるようにします。**Private hosted zone** (プライベートホストゾーン) はサポートされていません。

   1. 必要に応じて**タグ**を適用します。

   1. [**ホストゾーンの作成**] を選択します。
**注記**  
また、サブドメインのホストゾーンにクエリを送信する親ホストゾーン内の委任セットを持つ、カスタムドメインの新しいホストゾーンを作成することもできます。それ以外の場合は、A レコードを作成します。この方法により、ホストゾーンの柔軟性とセキュリティが向上します。詳細については、「[Amazon Route 53 を通してホストされるドメインのサブドメインの作成](https://aws.amazon.com/premiumsupport/knowledge-center/create-subdomain-route-53/)」をご覧ください。

1. [**ホストゾーン**] ページで、ホストゾーンの名前を選択します。

1. カスタムドメインの親ドメインに DNS レコードがまだない場合は、DNS レコードを追加します。次のプロパティを使用して、親ドメインの DNS レコードを作成します。
   + **レコード名**: 空白のままにします。
   + **レコードタイプ**: `A`。
   + **エイリアス**: 有効にしないでください。
   + **値**: 選択したターゲットを入力します。このレコードは*何らかの値*に解決される必要がありますが、レコードの値は Amazon Cognito にとって重要ではありません。
   + **TTL**: 任意の TTL に設定するか、デフォルトのままにします。
   + **ルーティングポリシー**: **[シンプルルーティング]** を選択します。

1. **[レコードを作成]** を選択します。以下に、ドメイン *example.com* のレコードの例を示します。

   `example.com. 60 IN A 198.51.100.1`
**注記**  
Amazon Cognito は、本番ドメインの予想外の乗っ取りから保護するために、カスタムドメインの親ドメインで使用する DNS レコードがあることを確認します。親ドメインの DNS レコードがない場合、カスタムドメインを設定しようとすると、 Amazon Cognito はエラーを返します。Start of Authority (SOA) レコードは、親ドメインの検証のために十分な DNS レコードではありません。

1. 次のプロパティを使用して、カスタムドメインに別の DNS レコードを追加します。
   + **レコード名**: カスタムドメインプレフィックス。例えば、`auth.example.com` のレコードを作成するための `auth`。
   + **レコードタイプ**: `A`。
   + **エイリアス**: 有効にします。
   + **トラフィックのルーティング先**: **[Cloudfront ディストリビューションへのエイリアス]** を選択します。前に記録した**エイリアスターゲット** (例えば、`123example.cloudfront.net`) を入力します。
   + **ルーティングポリシー**: **[シンプルルーティング]** を選択します。

1. **[レコードを作成]** を選択します。
**注記**  
新しいレコードがすべての Route 53 の DNS サーバーに伝播されるまでに約 60 秒かかる場合があります。Route 53 の [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API メソッドを使用して、変更が反映されていることが確認できます。

## ステップ 3: サインインページを検証する
<a name="cognito-user-pools-add-custom-domain-console-step-3"></a>
+ カスタムドメインでサインインページが表示できることを確認します。

  このアドレスをブラウザに入力して、カスタムドメインとサブドメインでサインインします。以下は、サブドメイン *auth* を使用したカスタムドメイン *example.com* のサンプル URL です。

  ```
  https://myapp.auth.example.com/login?response_type=code&client_id=<your_app_client_id>&redirect_uri=<your_callback_url>
  ```

## カスタムドメインの SSL 証明書を変更する
<a name="cognito-user-pools-add-custom-domain-changing-certificate"></a>

必要な場合は、Amazon Cognito を使用して、カスタムドメインに適用した証明書を変更することができます。

通常、これは ACM での定期的な証明書更新後には不要です。ACM で既存の証明書を更新するときは、証明書の ARN がそのまま維持され、カスタムドメインは自動的に新しい証明書を使用します。

ただし、既存の証明書を新しい証明書に置き換える場合は、ACM が新しい証明書に新しい ARN を提供します。新しい証明書をカスタムドメインに適用するには、この ARN を Amazon Cognito に提供する必要があります。

新しい証明書の提供後、Amazon Cognito では、それがカスタムドメインに配布されるまで最大 1 時間かかります。

**開始する前に**  
Amazon Cognito で証明書を変更する前に、証明書を ACM に追加する必要があります。詳細については、*AWS Certificate Manager ユーザーガイド*の「[使用開始](https://docs.aws.amazon.com/acm/latest/userguide/gs.html)」を参照してください。  
証明書を ACM に追加するときは、 AWS リージョンとして米国東部 (バージニア北部) を選択する必要があります。

証明書は、Amazon Cognito コンソールまたは API を使用して変更できます。

------
#### [ AWS マネジメントコンソール ]

**Amazon Cognito コンソールで証明書を更新する**

1. にサインイン AWS マネジメントコンソール し、 で Amazon Cognito コンソールを開きます[https://console.aws.amazon.com/cognito/home](https://console.aws.amazon.com/cognito/home)。

1. **[User Pools]** (ユーザープール) を選択します。

1. 証明書を更新するユーザープールを選択します。

1. **[ドメイン]** メニューを選択します。

1. **[Actions]** (アクション) 、**[Edit ACM certificate]** (ACM 証明書の編集) を選択します。

1. カスタムドメインに関連付ける新しい証明書を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ API ]

**証明書を更新する (Amazon Cognito API)**
+ [UpdateUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolDomain.html) アクションを使用します。

------

# マネージドログインページにブランディングを適用する
<a name="managed-login-branding"></a>

認証サービスとアプリケーションの間で一貫したユーザーエクスペリエンスを提供できます。この目標は、 AWS SDK のカスタムフォームとバックエンド API オペレーション、またはマネージドログインを使用して達成できます。マネージドログインとクラシックのホストされた UI は、ユーザープールによる認証を提供するアプリケーションコンポーネントのウェブフロントエンドです。マネージド認証サービスをアプリケーション UX と同期するには、2 つのカスタマイズオプションとして、ブランディングエディタとホステッド UI ブランディングがあります。Amazon Cognito コンソールとユーザープール API オペレーションで、好みのエクスペリエンスを選択できます。

**ブランディングエディタ**  
[ブランディングエディタ](managed-login-brandingeditor.md)は、最新のユーザープール UI エクスペリエンスである[マネージドログイン](cognito-user-pools-managed-login.md)用の最新のカスタマイズオプションです。ブランディングエディタは、マネージドログインのアセットおよびスタイル用のノーコードビジュアルエディタであり、一連の API オペレーションを使用して多くの設定オプションをプログラムで設定できます。ユーザープールを[ドメイン](cognito-user-pools-assign-domain.md)とマネージドログインを使用して設定すると、ログインページのブランディングデザイナーバージョンが自動的にレンダリングされます。

**ホステッド UI (クラシック) ブランディング**  
[ホストテッド UI (クラシック) ブランディングエクスペリエンス](hosted-ui-classic-branding.md)には、固定されたスタイルオプションセットを使用してカスケーディングスタイルシート (CSS) ファイルを変更するオプションと、カスタムロゴイメージを追加するオプションの 2 つがあります。これらのオプションは、Amazon Cognito コンソールまたは [SetUICustomization](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUICustomization.html) API オペレーションで設定できます。サービスを開始した時点では、Amazon Cognito にはこのオプションしかありませんでした。ユーザープールを[ドメイン](cognito-user-pools-assign-domain.md)とホステッド UI ブランディングバージョンで設定すると、ログインページのクラシックバージョンが自動的にレンダリングされます。[機能プラン](cognito-sign-in-feature-plans.md)によっては、ホストされた UI のみをサポートする場合があります。

**注記**  
ブランディングエディタとクラシックブランディングエクスペリエンスは、ホストされた認証サービスのビジュアルプロパティを変更します。現在、複数の言語のいずれかにローカライズする場合を除き、マネージドログインページに表示されるテキストを変更することはできません。ローカライズの詳細については、「[マネージドログインのローカリゼーション](cognito-user-pools-managed-login.md#managed-login-localization)」を参照してください。

## ブランディングエクスペリエンスを選択してスタイルを割り当てる
<a name="managed-login-branding-choose"></a>

Amazon Cognito コンソールでは、新しいユーザープールにデフォルトで**マネージドログイン**のブランディングエクスペリエンスが適用されます。マネージドログインが利用可能になる前に設定したユーザープールには、**ホステッド UI (クラシック)** ブランディングが適用されます。マネージドログインブランディングとホステッド UI ブランディングは切り替えることができます。**ブランディングバージョン**を変更すると、Amazon Cognito は、その変更をユーザープールドメインのユーザーインタラクティブページに直ちに反映します。マネージドログインとホステッド UI を使用すると、ユーザープールはアプリケーションクライアントごとに独自のスタイルを持つことができます。

アプリケーションクライアントごとに独自のブランディング*スタイル*を持つことができますが、ユーザープールドメインは、マネージドログインまたはホステッド UI のいずれかとして機能します。スタイルは、アプリケーションクライアントに適用される一連のカスタマイズ設定です。ユーザープールごとに 1 つの[カスタムドメイン](cognito-user-pools-add-custom-domain.md)と 1 つの[プレフィックスドメイン](cognito-user-pools-assign-domain-prefix.md)を設定できます。カスタムドメインとプレフィックスドメインに異なるブランディングバージョンを割り当てることができます。ただし、カスタムドメインを同時に設定している場合、プレフィックスドメインは完全には機能しません。`.well-known` OIDC 検出エンドポイントは、カスタムドメインパス*のみ*を提示します。プレフィックスドメインは、この設定のユーザープールでは、エンドポイント検出 (`openid-configuration`) を必要としないオペレーションにのみ使用できます。ユーザープールのこれらの特性により、ユーザープールごとに 1 つのブランディングバージョンを効果的に選択できます。

マネージドログインのブランディングバージョンに設定されているドメインがユーザープールにあると、ユーザープール内のアプリケーションクライアントにスタイルを割り当てることができます。スタイルは、イメージファイル、表示オプション、CSS 値で構成される一連のビジュアル設定です。アプリケーションクライアントにスタイルを割り当てると、Amazon Cognito はすぐに更新内容をユーザーインタラクティブログインページにプッシュします。選択したブランディングバージョンとこれに適用したカスタマイズが、ユーザーインタラクティブページに反映されます。

### スタイルの更新と削除
<a name="managed-login-branding-update"></a>

スタイルを作成したら、アプリケーションクライアントにスタイルをリンクします。アプリケーションクライアントのスタイル割り当てを変更するには、まず元のスタイルを削除する必要があります。現在、スタイル間で設定をコピーすることはできません。この操作は、プログラムで行う必要があります。スタイルとアプリケーションクライアント間で設定をレプリケートするには、[DescribeManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeManagedLoginBranding.html) API オペレーションを使用してスタイルの設定を取得し、[CreateManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateManagedLoginBranding.html) または [UpdateManagedLoginBranding](https://docs.aws.amazon.com/) を使用して適用します。アプリケーションクライアントの割り当て済みスタイルを変更することはできません。元のスタイルを削除して新しいスタイルを設定することのみができます。API および SDK オペレーションを使用したスタイルの管理の詳細については、「[マネージドログインのブランディングの API および SDK オペレーション](managed-login-brandingeditor.md#branding-designer-api)」を参照してください。

**注記**  
ブランディングスタイルを作成または更新するプログラムリクエストは、リクエストサイズが 2 MB 以下である必要があります。リクエストがこの制限より大きい場合は、リクエストを複数の `UpdateManagedLoginBranding` リクエストに分割し、最大リクエストサイズを超えないパラメータのグループにします。これらのリクエストでは、指定していないパラメータがデフォルトに設定されることはないため、既存の設定に影響を与えずに、部分的なリクエストを送信できます。

スタイルを削除するには、Amazon Cognito コンソールの **[マネージドログイン]** メニューを使用します。**[スタイル]** で削除するスタイルを選択し、**[スタイルを削除]** を選択します。

ドメインにブランディングを割り当てるプロセスは、以下のステップに要約されます。

1. [ドメインを作成し、ブランディングバージョンを設定します。](cognito-user-pools-assign-domain.md)

1. ブランディングスタイルを作成してアプリケーションクライアントに割り当てます。

**アプリケーションクライアントにスタイルを割り当てるには**

1. ユーザープールの **[ドメイン]** メニューでドメインを作成し、**[ブランディングバージョン]** を **[マネージドログイン]** に設定します。

1. **[マネージドログイン]** メニューに移動します。**[スタイル]** で、**[スタイルを作成]** を選択します。

1. スタイルを割り当てる先のアプリケーションクライアントを選択するか、新しい[アプリケーションクライアント](user-pool-settings-client-apps.md)を作成します。

1. ブランディング設定の構成を開始するには、**[ブランディングエディタを起動]** を選択します。

**Topics**
+ [ブランディングエクスペリエンスを選択してスタイルを割り当てる](#managed-login-branding-choose)
+ [ブランディングエディタによるマネージドログインのカスタマイズ](managed-login-brandingeditor.md)
+ [ホステッド UI (クラシック) ブランディングのカスタマイズ](hosted-ui-classic-branding.md)

# ブランディングエディタによるマネージドログインのカスタマイズ
<a name="managed-login-brandingeditor"></a>

ブランディングエディタは、マネージドログインウェブページ用のビジュアルデザインおよび編集ツールです。Amazon Cognito コンソールに組み込まれています。ブランディングエディタでは、ログインページのプレビューから開始し、Quick Setup オプションまたは詳細ビューの詳細オプションに進むことができます。スタイルパラメータを変更してプレビューしたり、カスタム背景イメージとロゴを追加したりできます。ライトモードとダークモードを設定できます。

![\[Amazon Cognito ユーザープールのブランディングエディタビジュアルエディタのプレビュー。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/hosted-ui-customization-editor-preview.png)


まず、ユーザープールまたはアプリケーションクライアントに適用できるスタイルを作成します。

**ブランディングエディタの使用を開始するには**

1. [[ドメイン]](cognito-user-pools-assign-domain.md) タブから**ドメインを作成**するか、既存のドメインを更新します。**[ブランディングバージョン]** で、**[マネージドログイン]** を使用するようにドメインを設定します。

1. 既存のアプリケーションクライアントスタイルがある場合は削除します。

   1. **[アプリケーションクライアント]** メニューで、アプリケーションクライアントを選択します。

   1. **[マネージドログインスタイル]** で、アプリクライアントに割り当てられたスタイルを選択します。

   1. **[スタイルを削除]** を選択します。[Confirm] (確認) をクリックして、選択内容を確認します。

1. ユーザープールの **[マネージドログイン]** メニューに移動します。プロンプトに従って、マネージドログインを含む[機能プラン](cognito-sign-in-feature-plans.md)を選択します (まだ選択していない場合)。変更を行わずにブランディングエディタをチェックアウトする場合は、**[この機能をプレビュー]** を選択することもできます。

1. **[スタイル]** で、**[スタイルを作成]** を選択します。

1. スタイルを割り当てるアプリケーションクライアントを選択し、**[作成]** を選択します。新しいアプリケーションクライアントを作成することもできます。

1. Amazon Cognito コンソールでブランディングエディタを起動します。

1. 編集を開始するタブを選択するか、**[エディタを起動]** を選択して [[Quick Setup]](#branding-designer-quick-setup) に移動します。以下のタブが利用可能です。  
**プレビュー**  
マネージドログインページで現在の選択内容がどのように表示されるかを確認します。  
**基盤**  
全体的なテーマを設定し、外部 ID プロバイダーへのリンクとスタイルフォームフィールドを設定します。  
**コンポーネント**  
ヘッダー、フッター、個々の UI 要素のスタイルを設定します。

1. 初期設定を選択するには、Quick Setup に移動します。**[設定カテゴリの変更]** を選択し、**[Quick Setup]** を選択します。**[続行]** を選択すると、ブランディングエディタが起動し、設定する一連の基本オプションが表示されます。

## テキストとローカリゼーション
<a name="branding-designer-loc"></a>

ブランディングエディタでテキストを変更またはローカライズすることはできません。代わりに、ユーザーに配信する URL に `lang` クエリパラメータを追加します。このパラメータにより、マネージドログインページは利用可能な言語の 1 つにローカライズされます。詳細については、「[マネージドログインのローカリゼーション](cognito-user-pools-managed-login.md#managed-login-localization)」を参照してください。

## Quick Setup
<a name="branding-designer-quick-setup"></a>

**[ブランディングエディタを起動]** ボタンを選択すると、マネージドログイン設定のビジュアルエディタがロードされ、さまざまな主要カスタマイズオプションから選択できます。選択するに従って、Amazon Cognito はマネージドログインの変更をプレビューウィンドウに反映します。詳細設定メニューに戻るには、**[設定カテゴリの変更]** ボタンを選択します。

**全体的な外観と操作感をどのようにするか?**  
マネージドログインの基本的なテーマ設定を構成します。    
**Display mode (表示モード)**  
マネージドログインのライトモード、ダークモード、またはアダプティブエクスペリエンスを選択します。Amazon Cognito がマネージドログインをレンダリングすると、アダプティブ設定はユーザーのブラウザ設定に従います。ブラウザアダプティブモードを選択すると、ライトモードとダークモードに異なる色とロゴ画像を選択できます。  
**[Spacing] (間隔)**  
ページの要素間のデフォルト間隔を設定します。  
**境界の半径**  
要素の外側の境界について、丸みの深さを設定します。

**ページの背景をどのようにするか?**    
**背景タイプ**  
**[画像を表示]** チェックボックスは、背景画像を使用するか、単色の背景を設定するかを示します。  

1. 画像を使用するには、**[画像を表示]** を選択し、ライトモードとダークモードの背景画像を選択します。画像でカバーされない背景領域には、ダークモードとライトモードの **[ページの背景色]** を設定することもできます。

1. 背景に単色のみを使用するには、**[画像を表示]** の選択を解除し、ライトモードとダークモードの **[ページの背景色]** を選択します。

**フォームの外観をどのようにするか?**  
マネージドログインのフォーム要素の設定を行います。フォーム項目の例として、ログインプロンプトとコードプロンプトがあります。    
**水平位置合わせ**  
フォームフィールドの水平位置合わせを設定します。  
**フォームのロゴ**  
ロゴ画像の配置を設定します。  
**ロゴ画像**  
ライトモードとダークモードのフォーム要素に含めるロゴ画像ファイルを選択します。画像をアップロードするには、**[ロゴ画像]** ドロップダウンを選択し、**[新しいアセットを追加]** を選択してロゴファイルを追加します。  
**主なブランドカラー**  
ライトモードとダークモードのテーマ色を設定します。この色は、プライマリとして分類されたすべての要素に背景色として適用されます。

**ヘッダーの外観をどのようにするか?**  
マネージドログインページにヘッダーを含めるかどうかを選択します。ヘッダーにはロゴ画像を含めることができます。    
**ヘッダーのロゴ**  
ヘッダー内のロゴ画像の位置を設定します。  
**ロゴ画像**  
ヘッダーに含めるロゴの位置とロゴ画像ファイルを選択します。画像をアップロードするには、**[ロゴ画像]** ドロップダウンを選択し、**[新しいアセットを追加]** を選択してロゴファイルを追加します。  
**ヘッダーの背景色**  
ヘッダーの背景にライトモードとダークモードの色を設定します。

## 詳細設定
<a name="branding-designer-advanced"></a>

詳細設定ビューでは、**[基盤]** と **[コンポーネント]** の個々のコンポーネントを変更できます。**[プレビュー]** タブには、現在のコンテキストにおけるマネージドログインのプレビューとカスタマイズが表示されます。

![\[マネージドログインコンポーネントの詳細な設定の AWS マネジメントコンソール スクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/hosted-ui-customization-console-preview.png)


コンポーネントのビジュアルエディタに移動するには、コンポーネントのタイトルにある [編集] アイコンを選択します。テーマスタジオエディタで、**[設定カテゴリを変更]** ボタンを使用してコンポーネントを切り替えることができます。

### 基盤
<a name="branding-designer-advanced-foundation"></a>

**アプリスタイル**  
マネージドログイン設定の基本を構成します。このカテゴリには、全体的なテーマ、テキスト間隔、ページのヘッダーとフッターの設定があります。

**Display mode (表示モード)**  
マネージドログインページのライトモード、ダークモード、またはアダプティブエクスペリエンスを選択します。ブラウザアダプティブモードを選択すると、ライトモードとダークモードに異なる色とロゴ画像を選択できます。

**[Spacing] (間隔)**  
ページの要素間のデフォルト間隔を設定します。

**認証動作**  
ユーザーを外部 ID プロバイダー (IdP) に接続するボタンのスタイルを設定します。このセクションには、マネージドログインでユーザーに E メールアドレスの入力を求め、それを [SAML ID プロバイダー識別子](cognito-user-pools-managing-saml-idp-naming.md)と照合するための **[ドメイン検索入力]** オプションが含まれています。

**フォーム動作**  
入力フォームのスタイル (入力の配置、色、要素の位置合わせ) を設定します。

### コンポーネント
<a name="branding-designer-advanced-components"></a>

**ボタン**  
Amazon Cognito がマネージドログインページでレンダリングするボタンのスタイル。

**ディバイダー**  
入力フォームや外部プロバイダーのサインインセレクターなど、マネージドログイン要素間の分割線と境界のスタイル。

**ドロップダウン**  
ドロップダウンメニューのスタイル。

**ファビコン**  
Amazon Cognito がタブとブックマークアイコンに提供する画像のスタイル。

**フォーカスリング**  
現在選択されている入力を示すハイライトのスタイル。

**フォームコンテナ**  
フォームを囲む要素のスタイル。

**グローバルフッター**  
Amazon Cognito がマネージドログインページの下部に表示するフッターのスタイル。

**グローバルヘッダー**  
Amazon Cognito がマネージドログインページの上部に表示するヘッダーのスタイル。

**表示**  
エラーメッセージと成功メッセージのスタイル。

**オプションコントロール**  
チェックボックス、複数選択、その他の入力プロンプトのスタイル。

**ページ背景**  
マネージドログインの全体的な背景のスタイル。

**入力**  
フォームフィールド入力プロンプトのスタイル。

**Link**  
マネージドログインページのハイパーリンクのスタイル。

**ページのテキスト**  
ページ内テキストのスタイル。

**フィールドのテキスト**  
フォーム入力の周囲のテキストのスタイル。

## マネージドログインのブランディングの API および SDK オペレーション
<a name="branding-designer-api"></a>

API オペレーション [CreateManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateManagedLoginBranding.html) および [UpdateManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateManagedLoginBranding.html) を使用して、マネージドログインスタイルにブランディングを適用することもできます。これらのオペレーションは、別のアプリケーションクライアントやユーザープールのブランディングスタイルと同一またはわずかに変更したバージョンを作成するのに最適です。API オペレーション [DescribeManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeManagedLoginBranding.html) を使用して、既存のスタイルのマネージドログインブランディングをクエリし、必要に応じて出力を変更して別のリソースに適用します。

`UpdateManagedLoginBranding` オペレーションでは、スタイルを適用する先のアプリケーションクライアントは変更されません。アプリケーションクライアントに割り当てられている既存のスタイルのみが更新されます。アプリケーションクライアントのスタイルを完全に置き換えるには、[DeleteManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteManagedLoginBranding.html) を使用して既存のスタイルを削除し、`CreateManagedLoginBranding` を使用して新しいスタイルを割り当てます。Amazon Cognito コンソールでも同様です。既存のスタイルを削除して新しいスタイルを作成する必要があります。

API または SDK リクエストでマネージドログインのブランディングを設定するには、`Document` データ型に変換された JSON ファイルに設定を埋め込む必要があります。以下は、追加できる画像と、ブランディングスタイルを設定するリクエストをプログラムで生成するためのガイダンスです。

### 画像アセット
<a name="branding-designer-api-assets"></a>

[CreateManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateManagedLoginBranding.html) と [UpdateManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateManagedLoginBranding.html) には `Assets` パラメータが含まれています。このパラメータは、base64 でエンコードされたバイナリ形式の画像ファイルの配列です。

**注記**  
ブランディングスタイルを作成または更新するプログラムリクエストは、リクエストサイズが 2 MB 以下である必要があります。リクエスト内のアセットによっては、この制限を超える場合があります。この場合、リクエストを複数の `UpdateManagedLoginBranding` リクエストに分割し、最大リクエストサイズを超えないパラメータのグループにします。これらのリクエストでは、指定していないパラメータがデフォルトに設定されることはないため、既存の設定に影響を与えずに、部分的なリクエストを送信できます。

一部のアセットは、送信できるファイルタイプに制限があります。


****  

| アセット | 許可されるファイル拡張子 | 
| --- | --- | 
| FAVICON\$1ICO | ico | 
| FAVICON\$1SVG | svg | 
| EMAIL\$1GRAPHIC | png、svg、jpeg | 
| SMS\$1GRAPHIC | png、svg、jpeg | 
| AUTH\$1APP\$1GRAPHIC | png、svg、jpeg | 
| PASSWORD\$1GRAPHIC | png、svg、jpeg | 
| PASSKEY\$1GRAPHIC | png、svg、jpeg | 
| PAGE\$1HEADER\$1LOGO | png、svg、jpeg | 
| PAGE\$1HEADER\$1BACKGROUND | png、svg、jpeg | 
| PAGE\$1FOOTER\$1LOGO | png、svg、jpeg | 
| PAGE\$1FOOTER\$1BACKGROUND | png、svg、jpeg | 
| PAGE\$1BACKGROUND | png、svg、jpeg | 
| FORM\$1BACKGROUND | png、svg、jpeg | 
| FORM\$1LOGO | png、svg、jpeg | 
| IDP\$1BUTTON\$1ICON | ico、svg | 

SVG タイプのファイルは、以下の属性と要素をサポートしています。

------
#### [ Attributes ]

```
accent-height, accumulate, additivive, alignment-baseline, ascent, attributename, attributetype, azimuth, basefrequency, baseline-shift, begin, bias, by, class, clip, clip-path, clip-rule, color, color-interpolation, color-interpolation-filters, color-profile, color-rendering, cx, cy, d, dx, dy, diffuseconstant, direction, display, divisor, dur, edgemode, elevation, end, fill, fill-opacity, fill-rule, filter, filterunits, flood-color, flood-opacity, font-family, font-size, font-size-adjust, font-stretch, font-style, font-variant, font-weight, fx, fy, g1, g2, glyph-name, glyphref, gradientunits, gradienttransform, height, href, id, image-rendering, in, in2, k, k1, k2, k3, k4, kerning, keypoints, keysplines, keytimes, lang, lengthadjust, letter-spacing, kernelmatrix, kernelunitlength, lighting-color, local, marker-end, marker-mid, marker-start, markerheight, markerunits, markerwidth, maskcontentunits, maskunits, max, mask, media, method, mode, min, name, numoctaves, offset, operator, opacity, order, orient, orientation, origin, overflow, paint-order, path, pathlength, patterncontentunits, patterntransform, patternunits, points, preservealpha, preserveaspectratio, r, rx, ry, radius, refx, refy, repeatcount, repeatdur, restart, result, rotate, scale, seed, shape-rendering, specularconstant, specularexponent, spreadmethod, stddeviation, stitchtiles, stop-color, stop-opacity, stroke-dasharray, stroke-dashoffset, stroke-linecap, stroke-linejoin, stroke-miterlimit, stroke-opacity, stroke, stroke-width, style, surfacescale, tabindex, targetx, targety, transform, text-anchor, text-decoration, text-rendering, textlength, type, u1, u2, unicode, values, viewbox, visibility, vert-adv-y, vert-origin-x, vert-origin-y, width, word-spacing, wrap, writing-mode, xchannelselector, ychannelselector, x, x1, x2, xmlns, y, y1, y2, z, zoomandpan
```

------
#### [ Elements ]

```
svg, a, altglyph, altglyphdef, altglyphitem, animatecolor, animatemotion, animatetransform, audio, canvas, circle, clippath, defs, desc, ellipse, filter, font, g, glyph, glyphref, hkern, image, line, lineargradient, marker, mask, metadata, mpath, path, pattern, polygon, polyline, radialgradient, rect, stop, style, switch, symbol, text, textpath, title, tref, tspan, video, view, vkern, feBlend, feColorMatrix, feComponentTransfer, feComposite, feConvolveMatrix, feDiffuseLighting, feDisplacementMap, feDistantLight, feFlood, feFuncA, feFuncB, feFuncG, feFuncR, feGaussianBlur, feMerge, feMergeNode, feMorphology, feOffset, fePointLight, feSpecularLighting, feSpotLight, feTile, feTurbulence
```

------

### マネージドログインのブランディングオペレーション用のツール
<a name="branding-designer-api-tools"></a>

Amazon Cognito は、マネージドログインのブランディング設定オブジェクト用のファイルを [JSON スキーマ形式](https://json-schema.org/docs)で管理します。ブランディングスタイルをプログラムで更新する方法は、次のとおりです。

**ユーザープール API でブランディングを更新するには**

1. Amazon Cognito コンソールで、ユーザープールの **[マネージドログイン]** メニューからマネージドログインのデフォルトのブランディングスタイルを作成します。それをアプリケーションクライアントに割り当てます。

1. スタイルを作成したアプリケーションクライアントの ID (例: `1example23456789`) を記録します。

1. `ReturnMergedResources` を `true` に設定して [DescribeManagedLoginBrandingByClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeManagedLoginBrandingByClient.html) API リクエストを使用し、ブランディングスタイルの設定を取得します。 リクエスト本文の例を次に示します。

   ```
   {
      "ClientId": "1example23456789",
      "ReturnMergedResources": true,
      "UserPoolId": "us-east-1_EXAMPLE"
   }
   ```

1. `DescribeManagedLoginBrandingByClient` の出力をカスタマイズして変更します。

   1. レスポンス本文は、作成および更新オペレーションの構文に含まれない `ManagedLoginBranding` 要素で囲まれています。この JSON オブジェクトの最上位レベルを削除します。

   1. 画像を置き換えるには、`Bytes` 値を、各画像ファイルの Base64 エンコードされたバイナリデータに置き換えます。

   1. 設定を更新するには、`Settings` オブジェクトの出力を変更し、次回のリクエストに含めます。Amazon Cognito は、API レスポンスで受け取ったスキーマに存在しない `Settings` オブジェクトの値を無視します。

1. 更新されたレスポンス本文を [CreateManagedLoginBranding](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateManagedLoginBranding.html) または [UpdateManagedLoginBranding](https://docs.aws.amazon.com/) リクエストで使用します。このリクエストのサイズが 2 MB を超える場合は、複数のリクエストに分割します。これらのオペレーションは、特に指定しない限り、元の設定が未変更のままである `PATCH` モデルで機能します。

# ホステッド UI (クラシック) ブランディングのカスタマイズ
<a name="hosted-ui-classic-branding"></a>

 AWS マネジメントコンソール、、 AWS CLI または API を使用して、ホストされた UI の従来のカスタマイズ設定を指定できます。アプリに表示するカスタムのロゴイメージをアップロードできます。UI の外観と操作感にカスケーディングスタイルシート (CSS) オプションをいくつか適用することもできます。

UI のデフォルトをカスタマイズし、個々の[アプリケーションクライアント](cognito-terms.md#term-appclient)を特定の設定で上書きできます。Amazon Cognito は、クライアントレベルの設定を持たないすべてのアプリケーションクライアントにデフォルト設定を適用します。

Amazon Cognito コンソールおよび API リクエストでは、UI のカスタマイズを設定するリクエストのサイズが 135 KB を超えることはできません。まれに、リクエストヘッダー、CSS ファイル、ロゴの合計が 135 KB を超えることがあります。Amazon Cognito はイメージファイルを Base64 にエンコードします。これにより、100 KB のイメージのサイズが 130 KB に増え、リクエストヘッダーと CSS 用に 5 KB が残ります。リクエストが大きすぎる場合、 AWS マネジメントコンソール または `SetUICustomization` API リクエストは`request parameters too large`エラーを返します。ロゴイメージを 100 KB 以下、CSS ファイルを 3 KB 以下に調整します。CSS とロゴのカスタマイズを個別に設定することはできません。

**注記**  
UI をカスタマイズするには、ユーザープールのドメインを設定する必要があります。

## クラシックブランディングでのカスタムロゴの指定
<a name="cognito-user-pools-app-ui-customization-logo"></a>

Amazon Cognito は、[ログインエンドポイント](login-endpoint.md) の入力フィールドの上の中央にカスタムロゴを配置します。

ホストされているカスタムの UI ロゴには、350 x 178 ピクセルまで拡大できる PNG、JPG、または JPEG ファイルを選択します。ロゴファイルのサイズは 100 KB 以下で、Amazon Cognito が Base64 にエンコードした後は 130 KB 以下にしてください。API [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUICustomization.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUICustomization.html)で `ImageFile`を設定するには、ファイルを Base64-encodedされたテキスト文字列に変換するか、 でファイルパス AWS CLIを指定して Amazon Cognito にエンコードさせます。

## クラシックブランディングでの CSS カスタマイズの指定
<a name="cognito-user-pools-app-ui-customization-css"></a>

ホストされたアプリページの CSS をカスタマイズできます。ただし、以下の制限があります。
+ 以下の CSS クラス名を使用できます。
  + `background-customizable`
  + `banner-customizable`
  + `errorMessage-customizable`
  + `idpButton-customizable`
  + `idpButton-customizable:hover`
  + `idpDescription-customizable`
  + `inputField-customizable`
  + `inputField-customizable:focus`
  + `label-customizable`
  + `legalText-customizable`
  + `logo-customizable`
  + `passwordCheck-valid-customizable`
  + `passwordCheck-notValid-customizable`
  + `redirect-customizable`
  + `socialButton-customizable`
  + `submitButton-customizable`
  + `submitButton-customizable:hover`
  + `textDescription-customizable`
+ プロパティ値は HTML を含めることができます。ただし、`@import`,`@supports`,`@page`, または`@media`ステートメント、または Javascript の値を除きます。

次の CSS プロパティをカスタマイズできます。

**Labels**  
+ [**font-weight**] は 100 ～ 900 までの 100 の倍数です。
+ [**color**] はテキストの色です。[有効な CSS カラー値](https://www.w3schools.com/cssref/css_colors_legal.php)である必要があります。

**入力フィールド**  
+ [**width**] は含まれるブロックの幅に対してパーセンテージで表したものです。
+ [**height**] は入力フィールドの高さ (ピクセル (px)) です。
+ [**color**] はテキストの色です。任意の標準 CSS 色値を使用できます。
+ [**background-color**] は、入力フィールドの背景色です。任意の標準 CSS 色値を使用できます。
+ [**border**] は、アプリウィンドウの境界の幅、透明度、色を指定する標準 CSS 値です。幅は 1 px から 100 px までの任意の値を使用できます。透明度は solid または none です。色は任意の標準色値を使用できます。

**テキストの説明**  
+ [**padding-top**] は、説明欄の上のパディング量です。
+ [**padding-bottom**] は、説明欄の下のパディング量です。
+ [**display**] には `block` または `inline` のいずれかを設定できます。
+ [**font-size**] はテキストの説明のフォントサイズです。
+ [**color**] はテキストの色です。[有効な CSS カラー値](https://www.w3schools.com/cssref/css_colors_legal.php)である必要があります。

**送信ボタン**  
+ [**font-size**] はボタンテキストのフォントサイズです。
+ [**font-weight**] はボタンテキストのフォントウェイトです。`bold`、`italic`、または `normal` です。
+ [**margin**] はボタンの上下左右のマージンサイズを示す 4 つの値の文字列です。
+ [**font-size**] はテキストの説明のフォントサイズです。
+ [**width**] はボタンテキストのブロックに対する幅 (パーセント) です。
+ [**height**] はボタンの高さ (ピクセル (px)) です。
+ [**color**] はボタンの色です。任意の標準 CSS 色値を使用できます。
+ [**background-color**] は、ボタンの背景色です。任意の標準色値を使用できます。

**バナー**  
+ [**padding**] はバナーの上下左右のパディングサイズを示す 4 つの値の文字列です。
+ [**background-color**] は、バナーの背景色です。任意の標準 CSS 色値を使用できます。

**送信ボタンのホバー**  
+ [**color**] は、ボタンにカーソルを合わせたときのボタンの前景色です。任意の標準 CSS 色値を使用できます。
+ [**background-color**] は、ボタンにカーソルを合わせたときのボタンの背景色です。任意の標準 CSS 色値を使用できます。

**ID プロバイダーボタンのホバー**  
+ [**color**] は、ボタンにカーソルを合わせたときのボタンの前景色です。任意の標準 CSS 色値を使用できます。
+ [**background-color**] は、ボタンにカーソルを合わせたときのボタンの背景色です。任意の標準 CSS 色値を使用できます。

**パスワードのチェックが有効ではありません**  
+ [**color**] は `"Password check not valid"` メッセージのテキスト色です。任意の標準 CSS 色値を使用できます。

**背景**  
+ [**background-color**] は、アプリウィンドウの背景色です。任意の標準 CSS 色値を使用できます。

**エラーメッセージ**  
+ [**margin**] は上下左右のマージンサイズを示す 4 つの値の文字列です。
+ [**padding**] はパディングサイズです。
+ [**font-size**] はフォントサイズです。
+ [**width**] はエラーメッセージの幅を含まれるブロックに対するパーセンテージで表したものです。
+ [**background**] は、エラーメッセージの背景色です。任意の標準 CSS 色値を使用できます。
+ [**border**] は境界の幅、透明度、色を指定する 3 つの値の文字列です。
+ [**color**] はエラーメッセージのテキスト色です。任意の標準 CSS 色値を使用できます。
+ [**box-sizing**] は含める必要があるサイズのプロパティ (幅と高さ) をブラウザに指示するために使用されます。

**ID プロバイダーボタン**  
+ [**height**] はボタンの高さ (ピクセル (px)) です。
+ [**width**] はボタンテキストの幅を含まれるブロックに対するパーセンテージで示したものです。
+ [**text-align**] はテキストの整列設定です。`left`、`right` または `center` のいずれかを設定できます。
+ [**margin-bottom**] は下側マージンの設定です。
+ [**color**] はボタンの色です。任意の標準 CSS 色値を使用できます。
+ [**background-color**] は、ボタンの背景色です。任意の標準 CSS 色値を使用できます。
+ [**border-color**] は、ボタンの境界の色です。任意の標準 CSS 色値を使用できます。

**ID プロバイダーの説明**  
+ [**padding-top**] は、説明欄の上のパディング量です。
+ [**padding-bottom**] は、説明欄の下のパディング量です。
+ [**display**] には `block` または `inline` のいずれかを設定できます。
+ [**font-size**] は説明のフォントサイズです。
+ **color** は、IdP セクションヘッダーのテキスト色です。例: **企業 ID でサインイン**。[有効な CSS カラー値](https://www.w3schools.com/cssref/css_colors_legal.php)である必要があります。

**法務関連のテキスト**  
+ [**color**] はテキストの色です。任意の標準 CSS 色値を使用できます。
+ [**font-size**] はフォントサイズです。
**リーガルテキスト**をカスタマイズする際は、サインインページのソーシャル ID プロバイダーに表示されるメッセージ「**We won't post to any of your accounts without asking first**」(最初に確認せずにアカウントに投稿することはありません) をカスタマイズします。

**ロゴ**  
+ [**max-width**] は最大幅を含まれるブロックに対するパーセンテージで表したものです。
+ [**max-height**] は最大高を含まれるブロックに対するパーセンテージで表したものです。
+ **background-color** は、透明なセクションを持つログの背景の色です。[有効な CSS カラー値](https://www.w3schools.com/cssref/css_colors_legal.php)である必要があります。

**入力フィールドのフォーカス**  
+ [**border-color**] は、入力フィールドの色です。任意の標準 CSS 色値を使用できます。
+ [**outline**] は入力フィールドの境界線の幅 (ピクセル) です。

**ソーシャルボタン**  
+ [**height**] はボタンの高さ (ピクセル (px)) です。
+ [**text-align**] はテキストの整列設定です。`left`、`right` または `center` のいずれかを設定できます。
+ [**width**] はボタンテキストの幅を含まれるブロックに対するパーセンテージで示したものです。
+ [**margin-bottom**] は下側マージンの設定です。

**パスワードのチェックが有効です**  
+ [**color**] は `"Password check valid"` メッセージのテキスト色です。任意の標準 CSS 色値を使用できます。

## でクラシックブランドを使用してホストされた UI をカスタマイズする AWS マネジメントコンソール
<a name="cognito-user-pools-app-ui-customization-console"></a>

を使用して AWS マネジメントコンソール 、アプリの UI カスタマイズ設定を指定できます。

**注記**  
以下の URL を、ユーザープールの指定を含めて作成し、ブラウザに入力することで、カスタマイズが反映されているホストされた UI を表示できます。` https://<your_domain>/login?response_type=code&client_id=<your_app_client_id>&redirect_uri=<your_callback_url>` 変更がコンソールに反映されるまで最大 1 分待ってからブラウザを最新表示にする必要がある場合があります。  
ドメインは、**[Domain]** (ドメイン) の下の **[App integration]** (アプリケーション統合) タブに表示されます。アプリケーションクライアント ID およびコールバック URL は **[App clients]** (アプリケーションクライアント) に表示されています。

**アプリ UI のカスタマイズ設定を指定する**

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

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

1. [[ドメイン]](cognito-user-pools-assign-domain.md) タブから**ドメインを作成**するか、既存のドメインを更新します。**[ブランディングバージョン]** で、**[ホストされた UI (クラシック)]** を使用するようにドメインを設定します。

1. **[マネージドログイン]** メニューを選択します。

1. すべてのアプリケーションクライアントの UI 設定をカスタマイズするには、**[ホストされた UI 設定]** で **[スタイル]** を参照し、**[編集]** を選択します。

1. 1 つのアプリケーションクライアントの UI 設定をカスタマイズするには、**[アプリクライアント]** メニューに移動し、変更するアプリケーションクライアントを選択します。次に **[ホストされた UI (クラシック) スタイル]** を参照し、**[オーバーライド]** を選択します。**[Edit]** (編集) を選択します。

1. 独自のロゴイメージファイルをアップロードするには、**[Choose file]** (ファイルを選択) または **[Replace current file]** (現在のファイルを置き換える) を選択します。

1. ホストされた UI CSS をカスタマイズするには、**CSS template.css** をダウンロードし、テンプレートをカスタマイズ値に変更します。ホストされた UI で使用できるのは、テンプレートに含まれるキーのみです。追加された CSS キーは UI に反映されません。CSS ファイルをカスタマイズしたら、**[Choose file]** (ファイルの選択) または **[Replace current file]** (現在のファイルを置き換える) を選択し、カスタム CSS ファイルをアップロードします。

## ユーザープール API のクラシックブランドと を使用したホストされた UI のカスタマイズ AWS CLI
<a name="cognito-user-pools-app-ui-customization-cli-api"></a>

次のコマンドを使用して、ユーザープールのアプリ UI カスタマイズ設定を指定します。

**ユーザープールの組み込みアプリ UI の UI カスタマイズ設定を取得するには、次の API オペレーションを使用します。**
+ AWS CLI: `aws cognito-idp get-ui-customization`
+ AWS API: [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUICustomization.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUICustomization.html)

**ユーザープールの組み込みアプリ UI の UI カスタマイズ設定を設定するには、次の API オペレーションを使用します。**
+ AWS CLI イメージファイルから: `aws cognito-idp set-ui-customization --user-pool-id <your-user-pool-id> --client-id <your-app-client-id> --image-file fileb://"<path-to-logo-image-file>" --css ".label-customizable{ color: <color>;}"`
+ AWS CLI Base64 バイナリテキストとしてエンコードされたイメージ: `aws cognito-idp set-ui-customization --user-pool-id <your-user-pool-id> --client-id <your-app-client-id> --image-file <base64-encoded-image-file> --css ".label-customizable{ color: <color>;}"`
+ AWS API: [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUICustomization.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUICustomization.html)

# Lambda トリガーを使用したユーザープールワークフローのカスタマイズ
<a name="cognito-user-pools-working-with-lambda-triggers"></a>

Amazon Cognito は AWS Lambda 関数と連携して、ユーザープールの認証動作を変更します。初回サインアップ前、認証完了後、およびその間のいくつかの段階で Lambda 関数を自動的に呼び出すようにユーザープールを設定できます。関数は、認証フローのデフォルトの動作を変更したり、ユーザープールやその他の AWS リソースを変更するための API リクエストを行ったり、外部システムと通信したりできます。Lambda 関数のコードはユーザー独自のものです。Amazon Cognito はイベントデータを関数に送信し、関数がデータを処理するのを待ちます。ほとんどの場合、セッションへの変更を示すレスポンスイベントが返されます。

リクエストイベントとレスポンスイベントのシステム内では、独自の認証チャレンジの導入、ユーザープールと別の ID ストア間でのユーザーの移行、メッセージのカスタマイズ、JSON ウェブトークン (JWT) の変更を行うことができます。

Lambda トリガーは、ユーザーがユーザープールでアクションを開始した後に Amazon Cognito がユーザーに配信するレスポンスをカスタマイズできます。例えば、他の方法では成功するはずのユーザーによるサインインを禁止できます。また、 AWS 環境、外部 API、データベース、または ID ストアに対してランタイムオペレーションを実行することもできます。例えば、ユーザー移行のトリガーでは、外部アクションと Amazon Cognito の変更を組み合わせることができます。つまり、外部ディレクトリでユーザー情報を検索し、その外部情報に基づいて新しいユーザーに属性を設定できます。

Lambda トリガーをユーザープールに割り当てると、Amazon Cognito はデフォルトのフローを中断して関数から情報をリクエストします。Amazon Cognito は JSON *イベント*を生成し、それを関数に渡します。イベントには、ユーザーアカウントの作成、サインイン、パスワードのリセット、または属性の更新を求めるユーザーのリクエストに関する情報が含まれます。これで、関数がアクションを実行、またはイベントを変更せずに送り返すことができます。変更されていないイベントが返されると、イベントのデフォルトのアクションを続行するようにユーザープールに通知されます。例えば、サインアップ前トリガーは、`PreSignUp_SignUp` トリガーソースのユーザーを自動的に確認しますが、外部のユーザーと管理者が作成したユーザーの場合はイベントを変更せずに返すことができます。

次の表は、Lambda トリガーを使用してユーザープールオペレーションをカスタマイズする方法をまとめたものです。


****  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html)

**Topics**
+ [Lambda トリガーについて知っておくべきこと](#important-lambda-considerations)
+ [ユーザープールの Lambda トリガーを追加する](#triggers-working-with-lambda)
+ [ユーザープールの Lambda トリガーイベント](#cognito-user-pools-lambda-trigger-event-parameter-shared)
+ [ユーザープールの Lambda トリガーの一般的なパラメータ](#cognito-user-pools-lambda-trigger-syntax-shared)
+ [クライアントメタデータ](#working-with-lambda-trigger-client-metadata)
+ [Lambda トリガーへの API オペレーションの接続](#lambda-triggers-by-event)
+ [Lambda トリガーのユーザープールの機能オペレーションへの接続](#working-with-lambda-trigger-sources)
+ [サインアップ前の Lambda トリガー](user-pool-lambda-pre-sign-up.md)
+ [確認後の Lambda トリガー](user-pool-lambda-post-confirmation.md)
+ [認証前の Lambda トリガー](user-pool-lambda-pre-authentication.md)
+ [認証後の Lambda トリガー](user-pool-lambda-post-authentication.md)
+ [インバウンドフェデレーション Lambda トリガー](user-pool-lambda-inbound-federation.md)
+ [カスタム認証チャレンジの Lambda トリガー](user-pool-lambda-challenge.md)
+ [トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)
+ [ユーザー移行の Lambda トリガー](user-pool-lambda-migrate-user.md)
+ [カスタムメッセージの Lambda トリガー](user-pool-lambda-custom-message.md)
+ [カスタム送信者の Lambda トリガー](user-pool-lambda-custom-sender-triggers.md)

## Lambda トリガーについて知っておくべきこと
<a name="important-lambda-considerations"></a>

Lambda 関数用のユーザープールを準備するときは、以下の点を考慮します。
+ Amazon Cognito が Lambda トリガーに送信するイベントは、新しい機能に伴って変わる可能性があります。JSON 階層内のレスポンス要素とリクエスト要素の位置が変更されたり、要素名が追加されたりする場合があります。Lambda 関数では、このガイドで説明している入力要素のキーと値のペアを受け取ることが期待できますが、入力検証がより厳密になると、関数が失敗する可能性があります。
+ Amazon Cognito が一部のトリガーに送信する複数のバージョンのイベントから 1 つを選択できます。バージョンによっては、Amazon Cognito 料金の変更を受け入れることが必要になる場合があります。料金の詳細については、「[Amazon Cognito の料金](https://aws.amazon.com/cognito/pricing/)」を参照してください。[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)でアクセストークンをカスタマイズするには、*ライト*以外の機能プランを使用してユーザープールを設定し、イベントバージョン 2 を使用するように Lambda トリガー設定を更新する必要があります。
+ [カスタム送信者の Lambda トリガー](user-pool-lambda-custom-sender-triggers.md)を除き、Amazon Cognito は Lambda 関数を同期的に呼び出します。Amazon Cognito が Lambda 関数を呼び出したら、5 秒以内に応答する必要があります。そうでなく、呼び出しを再試行できる場合、Amazon Cognito は呼び出しを再試行することがあります。すべての再試行が失敗すると、関数はタイムアウトします。この 5 秒のタイムアウト値を変更することはできません。詳細については、「 AWS Lambda デベロッパーガイド」の[「Lambda プログラミングモデル](https://docs.aws.amazon.com/lambda/latest/dg/foundation-progmodel.html)」を参照してください。

  Amazon Cognito は、HTTP ステータスコード 500～599 の[呼び出しエラー](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_Errors)を返す関数呼び出しを再試行しません。これらのコードは、Lambda が関数を起動できない原因となる設定の問題を示しています。詳細については、[「エラー処理と自動再試行 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)」を参照してください。
+ Lambda トリガー設定で関数バージョンを宣言することはできません。Amazon Cognito ユーザープールは、デフォルトで最新バージョンの関数を呼び出します。ただし、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) または [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストにより、関数バージョンをエイリアスに関連付け、トリガーの `LambdaArn` をエイリアス ARN に設定できます。このオプションは、 AWS マネジメントコンソールでは使用できません。エイリアスの詳細については、「AWS Lambda デベロッパーガイド」の「[Lambda 関数のエイリアス](https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html)」を参照してください。**
+ Lambda トリガーを削除する場合は、ユーザープール内の対応するトリガーを更新する必要があります。例えば、認証後トリガーを削除した場合は、ユーザープール内の対応する**認証後トリガー**を [**なし**] に設定する必要があります。
+ Lambda 関数がリクエストとレスポンスのパラメータを Amazon Cognito に返さないか、エラーを返す場合、認証イベントは成功しません。関数にエラーを返して、ユーザーのサインアップ、認証、トークン生成、または Lambda トリガーを呼び出す認証フローのその他の段階を防ぐことができます。

  マネージドログインは、Lambda トリガーが生成したエラーをサインインプロンプトの上にエラーテキストとして返します。Amazon Cognito ユーザープール API は、トリガーエラーを `[trigger] failed with error [error text from response]` 形式で返します。ベストプラクティスとして、Lambda 関数では、ユーザーに表示させるエラーのみを生成します。`print()` のような出力方法を使用して、機密情報やデバッグ情報を CloudWatch ログに記録します。例については、[サインアップ前の例:ユーザー名が 5 文字未満の場合にサインアップを拒否する](user-pool-lambda-pre-sign-up.md#aws-lambda-triggers-pre-registration-example-3)を参照してください。
+ ユーザープールのトリガー AWS アカウント として、別の に Lambda 関数を追加できます。[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API オペレーションと [UpdateUserPool](https://docs.aws.amazon.com/) API オペレーション、またはそれらに相当する CloudFormation と でクロスアカウントトリガーを追加する必要があります AWS CLI。にクロスアカウント関数を追加することはできません AWS マネジメントコンソール。
+ Amazon Cognito コンソールに Lambda トリガーを追加すると、Amazon Cognito はユーザープールが関数を呼び出すことを許可するリソースベースのポリシーを、関数に追加します。クロスアカウント関数を含む Lambda トリガーを Amazon Cognito コンソールの外部で作成する場合は、Lambda 関数のリソースベースポリシーにアクセス許可を追加する必要があります。追加したアクセス権限では、Amazon Cognito はユーザープールの代わりに関数を呼び出すことを許可する必要があります。[Lambda コンソールから権限を追加](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html)、または Lambda [AddPermission](https://docs.aws.amazon.com/lambda/latest/dg/API_AddPermission.html) API オペレーションを使用することができます。

**Lambda リソースベースのポリシーの例**  
次の Lambda リソースベースのポリシーの例では、Lambda 関数を呼び出す Amazon Cognito の限定的な機能が付与されます。Amazon Cognito は、`aws:SourceArn` の条件でのユーザープールと `aws:SourceAccount` 条件でのアカウントの両方に代わって関数を呼び出す場合にのみ、関数を呼び出すことができます。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Id": "default",
      "Statement": [
          {
              "Sid": "LambdaCognitoIdpTrust",
              "Effect": "Allow",
              "Principal": {
                  "Service": "cognito-idp.amazonaws.com"
              },
              "Action": "lambda:InvokeFunction",
              "Resource": "arn:aws:lambda:us-east-1:111122223333:function:MyFunction",
              "Condition": {
                  "StringEquals": {
                      "AWS:SourceAccount": "111122223333"
                  },
                  "ArnLike": {
                      "AWS:SourceArn": "arn:aws:cognito-idp:us-east-1:111122223333:userpool/us-east-1_EXAMPLE"
                  }
              }
          }
      ]
  }
  ```

------

## ユーザープールの Lambda トリガーを追加する
<a name="triggers-working-with-lambda"></a>

**コンソールを使用してユーザープールの Lambda トリガーを追加する**

1. [Lambda コンソール](https://console.aws.amazon.com/lambda/home)を使用して Lambda 関数を作成します。Lambda 関数の詳細については、[AWS Lambda デベロッパーガイド](https://docs.aws.amazon.com/lambda/latest/dg/)を参照してください。

1. [[Amazon Cognito console]](https://console.aws.amazon.com/cognito/home) (Amazon Cognito コンソール) に移動し、**[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[拡張機能]** メニューを選択し、**[Lambda トリガー]** を見つけます。

1. **[Add a Lambda trigger]** (Lambda トリガーの追加) を選択します。

1. カスタマイズする認証のステージに基づいて、Lambda トリガー**カテゴリ**を選択します。

1. **Lambda 関数の割り当て**を選択し、ユーザープール AWS リージョン と同じ 内の関数を選択します。
**注記**  
 AWS Identity and Access Management (IAM) 認証情報に Lambda 関数を更新するアクセス許可がある場合、Amazon Cognito は Lambda リソースベースのポリシーを追加します。このポリシーを使用すると、Amazon Cognito は選択した関数を呼び出すことができます。サインインした認証情報に十分な IAM アクセス権限がない場合は、リソースベースのポリシーを個別に更新する必要があります。詳細については、「[Lambda トリガーについて知っておくべきこと](#important-lambda-considerations)」を参照してください。

1. **[Save changes]** (変更の保存) をクリックします。

1. Lambda コンソールで CloudWatch を使用して、Lambda 関数をログすることができます。詳細については、「[Accessing CloudWatch Logs for Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)」を参照してください。

## ユーザープールの Lambda トリガーイベント
<a name="cognito-user-pools-lambda-trigger-event-parameter-shared"></a>

Amazon Cognito は Lambda 関数にイベント情報を渡します。Lambda 関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。関数が入力イベントを変更せずに返した場合、Amazon Cognito はデフォルトの動作を続行します。以下に示すのは、すべての Lambda トリガー入力イベントに共通するパラメータです。トリガー別のイベント構文については、このガイドのトリガー別のセクションでイベントスキーマを確認してください。

------
#### [ JSON ]

```
{
    "version": "string",
    "triggerSource": "string",
    "region": AWSRegion,
    "userPoolId": "string",
    "userName": "string",
    "callerContext": 
        {
            "awsSdkVersion": "string",
            "clientId": "string"
        },
    "request":
        {
            "userAttributes": {
                "string": "string",
                ....
            }
        },
    "response": {}
}
```

------

## ユーザープールの Lambda トリガーの一般的なパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-shared"></a>

**バージョン**  
Lambda 関数のバージョン番号。

**triggerSource**  
Lambda 関数をトリガーしたイベントの名前。各 triggerSource の説明については、「[Lambda トリガーのユーザープールの機能オペレーションへの接続](#working-with-lambda-trigger-sources)」を参照してください。

**リージョン**  
`AWSRegion` インスタンス AWS リージョン としての 。

**userPoolId**  
ユーザープールの ID。

**userName**  
現在のユーザーのユーザー名。

**callerContext**  
リクエストとコード環境に関するメタデータ。これには、**[awsSdkVersion]** と **[clientId]** フィールドが含まれています。    
**awsSdkVersion**  
リクエストを生成した AWS SDK のバージョン。  
****clientId****  
ユーザープールアプリクライアントの ID。

**request**  
ユーザーの API リクエストの詳細。以下のフィールドと、トリガーに固有のリクエストパラメータが含まれます。例えば、Amazon Cognito が事前認証トリガーに送信するイベントには `userNotFound` パラメータも含まれます。ユーザーが未登録のユーザー名でサインインしようとしたときに、このパラメータの値を処理してカスタムアクションを実行できます。    
**userAttributes**  
ユーザー属性の名前と値の 1 つ以上のキーと値のペア。例: `"email": "john@example.com"`。

**response**  
このパラメータには、元のリクエストの情報は含まれていません。Lambda 関数はイベント全体を Amazon Cognito に返し、返されるパラメータは `response` に追加する必要があります。関数に含めることができる返されるパラメータを確認するには、使用するトリガーのドキュメントを参照してください。

## クライアントメタデータ
<a name="working-with-lambda-trigger-client-metadata"></a>

API オペレーションと [トークンエンドポイント](token-endpoint.md) リクエストでは、Lambda トリガー関数にカスタムパラメータを送信できます。クライアントメタデータを使用すると、アプリケーションはリクエスト元の環境に関する追加情報を収集できます。クライアントメタデータを Lambda 関数に渡すと、関数は追加のデータを処理することで、認証フローのログ記録やカスタマイズに使用できます。クライアントメタデータは、JSON 形式のキーと値の文字列ペアであり、自分で選択して作成します。

**クライアントメタデータのユースケース例**
+ サインアップ時に位置情報データを[サインアップ前トリガー](user-pool-lambda-pre-sign-up.md)に渡し、不要な場所からのサインインを防止します。
+ テナント ID データを[カスタムチャレンジトリガー](user-pool-lambda-challenge.md)に渡し、さまざまなビジネスユニットのユーザーごとに異なるチャレンジを発行します。
+ ユーザーのトークンを[トークン生成前トリガー](user-pool-lambda-pre-token-generation.md)に渡し、M2M リクエストを代行した対象のプリンシパルのログを生成します。リクエスト例については、「[基本認可によるクライアント認証情報POST 本文認可によるクライアント認証情報](token-endpoint.md#exchanging-client-credentials-for-an-access-token-in-request-body)」を参照してください。

クライアントメタデータをサインアップ前トリガーに渡す例を以下に示します。

------
#### [ SignUp request ]

次に示すのは、[SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html#CognitoUserPools-SignUp-request-ValidationData) リクエストにより、Amazon Cognito がクライアントメタデータをサインアップ前トリガーに渡す例です。

```
POST HTTP/1.1
Host: cognito-idp.us-east-1.amazonaws.com
X-Amz-Date: 20230613T200059Z
Accept-Encoding: gzip, deflate, br
X-Amz-Target: AWSCognitoIdentityProviderService.SignUp
User-Agent: <UserAgentString>
Authorization: AWS4-HMAC-SHA256 Credential=<Credential>, SignedHeaders=<Headers>, Signature=<Signature>
Content-Length: <PayloadSizeBytes>

{
    "ClientId": "1example23456789",
    "Username": "mary_major",
    "Password": "<Password>",
    "SecretHash": "<Secret hash>",
    "ClientMetadata": { 
        "IpAddress" : "192.0.2.252",
        "GeoLocation" : "Netherlands (Kingdom of the) [NL]"
    }
    "UserAttributes": [
        {
            "Name": "name",
            "Value": "Mary"
        },
        {
            "Name": "email",
            "Value": "mary_major@example.com"
        },
        {
            "Name": "phone_number",
            "Value": "+12065551212"
        }
    ],
}
```

------
#### [ Lambda trigger input event ]

サインアップ前関数へのリクエストは、次のような本文になります。

```
{
    "callerContext": {
        "awsSdkVersion": "aws-sdk-unknown-unknown",
        "clientId": "1example23456789"
    },
    "region": "us-west-2",
    "request": {
        "clientMetadata": {
            "GeoLocation": "Netherlands (Kingdom of the) [NL]",
            "IpAddress": "192.0.2.252"
        },
        "userAttributes": {
            "email": "mary_major@example.com",
            "name": "Mary",
            "phone_number": "+12065551212"
        },
        "validationData": null
    },
    "response": {
        "autoConfirmUser": false,
        "autoVerifyEmail": false,
        "autoVerifyPhone": false
    },
    "triggerSource": "PreSignUp_SignUp",
    "userName": "mary_major2",
    "userPoolId": "us-west-2_EXAMPLE",
    "version": "1"
}
```

------

**Machine to Machine (M2M) クライアント認証情報のクライアントメタデータ**  
[クライアントメタデータ](#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
```

**一時的なユーザー属性: `validationData`**  
一部の認証オペレーションには `validationData` パラメータもあります。このパラメータにより、Amazon Cognito が自動的に収集しない外部情報を、クライアントメタデータと同様に、Lambda トリガーに渡すことができます。検証データフィールドは、サインアップおよびサインインオペレーションにおいて、追加のユーザーコンテキストを Lambda 関数に渡すことを目的としています。[SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html#CognitoUserPools-SignUp-request-ValidationData) と [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html#CognitoUserPools-AdminCreateUser-request-ValidationData) は、`validationData` を[サインアップ前トリガー](user-pool-lambda-pre-sign-up.md)に渡します。[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-ClientMetadata) と [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-ClientMetadata) は、API リクエスト本文の `ClientMetadata` を入力イベントの `validationData` として、[認証前](user-pool-lambda-pre-authentication.md)トリガーと[ユーザー移行](user-pool-lambda-migrate-user.md)トリガーに渡します。

クライアントメタデータを渡す先の関数に API オペレーションをマッピングする方法については、トリガーソースに関する以降のセクションを参照してください。

## Lambda トリガーへの API オペレーションの接続
<a name="lambda-triggers-by-event"></a>

以下のセクションでは、Amazon Cognito がユーザープールのアクティビティから呼び出す Lambda トリガーについて説明します。

アプリケーションが、Amazon Cognito ユーザープールの API、マネージドログイン、またはユーザープールのエンドポイントを介してユーザーをサインインさせると、Amazon Cognito はセッションコンテキストに基づいて Lambda 関数を呼び出します。Amazon Cognito ユーザープール API およびユーザープールの詳細については、「[API、OIDC、マネージドログインページの認証についての理解](authentication-flows-public-server-side.md#user-pools-API-operations)」を参照してください。次のセクションの表では、Amazon Cognito が関数を呼び出す原因となるイベントと、Amazon Cognito がリクエストに含める `triggerSource` 文字列について説明します。

**Topics**
+ [Amazon Cognito API の Lambda トリガー](#lambda-triggers-native-users-native-api)
+ [マネージドログインにおける Amazon Cognito ローカルユーザー向けの Lambda トリガー](#lambda-triggers-native-users-hosted-UI)
+ [フェデレーティッドユーザーの Lambda トリガー](#lambda-triggers-for-federated-users)

### Amazon Cognito API の Lambda トリガー
<a name="lambda-triggers-native-users-native-api"></a>

次の表は、アプリがローカルユーザーを作成、サインイン、または更新するときに Amazon Cognito が呼び出すことができる Lambda トリガーのソース文字列を示しています。


**Amazon Cognito API のローカルユーザートリガーソース**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html)

### マネージドログインにおける Amazon Cognito ローカルユーザー向けの Lambda トリガー
<a name="lambda-triggers-native-users-hosted-UI"></a>

次の表は、ローカルユーザーがマネージドログインを使用してユーザープールにサインインするときに Amazon Cognito が呼び出せる Lambda トリガーのソース文字列を示しています。


**マネージドログインにおけるローカルユーザーのトリガーソース**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html)

### フェデレーティッドユーザーの Lambda トリガー
<a name="lambda-triggers-for-federated-users"></a>

次の Lambda トリガーを使用して、フェデレーションプロバイダーでサインインするユーザーのユーザープールのワークフローをカスタマイズできます。

**注記**  
フェデレーションユーザーは、マネージドログインを使用してサインインできます。または、[認可エンドポイント](authorization-endpoint.md) へのリクエストを生成して、ユーザーを ID プロバイダーのサインインページにサイレントにリダイレクトすることができます。Amazon Cognito ユーザープール API を使用してフェデレーションユーザーをサインインすることはできません。


**フェデレーティッドユーザートリガーのソース**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html)

フェデレーティッドサインインは、ユーザープールの [カスタム認証チャレンジの Lambda トリガー](user-pool-lambda-challenge.md)、[ユーザー移行の Lambda トリガー](user-pool-lambda-migrate-user.md)、[カスタムメッセージの Lambda トリガー](user-pool-lambda-custom-message.md)、または [カスタム送信者の Lambda トリガー](user-pool-lambda-custom-sender-triggers.md) を呼び出しません。

## Lambda トリガーのユーザープールの機能オペレーションへの接続
<a name="working-with-lambda-trigger-sources"></a>

各 Lambda トリガーは、ユーザープールで機能的な役割を果たします。例えば、トリガーを使用してサインアップフローを変更したり、カスタム認証チャレンジを追加したりできます。Amazon Cognito が Lambda 関数に送信するイベントには、その機能ロールを構成する複数のアクションのうちの 1 つが反映されます。例えば、Amazon Cognito は、ユーザーがサインアップしたとき、およびユーザーを作成したときに、事前サインアップトリガーを呼び出します。同じ機能的役割を持つ、これらのさまざまなケースには、それぞれ独自の `triggerSource` 値があります。Lambda 関数は、呼び出したオペレーションに基づいて受信イベントを異なる方法で処理できます。

また Amazon Cognito は、イベントがトリガーソースに対応するときに、割り当てられたすべての関数を呼び出します。例えば、ユーザー移行トリガーと事前認証トリガーを割り当てたユーザープールにユーザーがサインインすると、両方がアクティブになります。


**サインアップ、確認、およびサインイン (認証) トリガー**  

| トリガー | triggerSource 値 | イベント | 
| --- | --- | --- | 
| サインアップ前 | PreSignUp\$1SignUp | サインアップ前。 | 
| サインアップ前 | PreSignUp\$1AdminCreateUser | 管理者が新しいユーザーを作成するときのサインアップ前 | 
| サインアップ前 | PreSignUp\$1ExternalProvider | 外部 ID プロバイダーのサインアップ前。 | 
| 確認後 | PostConfirmation\$1ConfirmSignUp | サインアップの確認後。 | 
| 確認後 | PostConfirmation\$1ConfirmForgotPassword | パスワードを忘れた場合の確認後。 | 
| 認証前 | PreAuthentication\$1Authentication | 認証前。 | 
| 認証後 | PostAuthentication\$1Authentication | 認証後。 | 


**カスタム認証チャレンジトリガー**  

| Trigger | triggerSource 値 | イベント | 
| --- | --- | --- | 
| 認証チャレンジを定義する | DefineAuthChallenge\$1Authentication | 認証チャレンジの定義。 | 
| 認証チャレンジの作成 | CreateAuthChallenge\$1Authentication | 認証チャレンジの作成。 | 
| 認証チャレンジの検証。 | VerifyAuthChallengeResponse\$1Authentication | 認証チャレンジレスポンスの確認。 | 


**フェデレーショントリガー**  

| Trigger | triggerSource 値 | イベント | 
| --- | --- | --- | 
| インバウンドフェデレーション | InboundFederation\$1ExternalProvider | インバウンドフェデレーション。 | 


**トークン生成前トリガー**  

| Trigger | triggerSource 値 | イベント | 
| --- | --- | --- | 
| トークン生成前 | TokenGeneration\$1HostedAuth |  Amazon Cognito は、マネージドログインのサインインページからユーザーを認証します。 | 
| トークン生成前 | TokenGeneration\$1Authentication | ユーザーの認証またはトークンの更新が完了しました。 | 
| トークン生成前 | TokenGeneration\$1NewPasswordChallenge | 管理者がユーザーを作成します。ユーザーが一時パスワードを変更する必要があるときに、Amazon Cognito は、これを呼び出します。 | 
| トークン生成前 | TokenGeneration\$1AuthenticateDevice | ユーザーデバイスの認証の終了。 | 
| トークン生成前 | TokenGeneration\$1RefreshTokens | ユーザーは、ID およびアクセストークンを更新しようとします。 | 


**移行ユーザートリガー**  

| Trigger | triggerSource 値 | イベント | 
| --- | --- | --- | 
| ユーザー移行 | UserMigration\$1Authentication | サインイン時のユーザー移行。 | 
| ユーザー移行 | UserMigration\$1ForgotPassword | パスワードを忘れた場合のフロー実行時のユーザー移行 | 


**カスタムメッセージトリガー**  

| Trigger | triggerSource 値 | イベント | 
| --- | --- | --- | 
| カスタムメッセージ | CustomMessage\$1SignUp | ユーザーがユーザープールにサインアップしたときのカスタムメッセージ。 | 
| カスタムメッセージ | CustomMessage\$1AdminCreateUser | 管理者としてユーザーを作成し、Amazon Cognito から一時パスワードが送信されるときのカスタムメッセージ。 | 
| カスタムメッセージ | CustomMessage\$1ResendCode | 既存のユーザーが新しい確認コードをリクエストしたときのカスタムメッセージ。 | 
| カスタムメッセージ | CustomMessage\$1ForgotPassword | ユーザーがパスワードのリセットを要求したときのカスタムメッセージ。 | 
| カスタムメッセージ | CustomMessage\$1UpdateUserAttribute | ユーザーが E メールアドレスまたは電話番号を変更し、Amazon Cognito が検証コードを送信したときのカスタムメッセージ。 | 
| カスタムメッセージ | CustomMessage\$1VerifyUserAttribute | ユーザーが E メールアドレスまたは電話番号を追加し、Amazon Cognito が検証コードを送信したときのカスタムメッセージ。 | 
| カスタムメッセージ | CustomMessage\$1Authentication | SMS MFA を設定したユーザーがサインインしたときのカスタムメッセージ。 | 


**カスタム送信者トリガー**  

| Trigger | triggerSource 値 | イベント | 
| --- | --- | --- | 
| カスタム送信者 |  `CustomEmailSender_SignUp` `CustomSmsSender_SignUp`  | ユーザーがユーザープールにサインアップした場合。 | 
| カスタム送信者 |  `CustomEmailSender_AdminCreateUser` `CustomSmsSender_AdminCreateUser`  | 管理者としてユーザーを作成し、Amazon Cognito がユーザーに仮パスワードを送信した場合。 | 
| カスタム送信者 |  `CustomEmailSender_ForgotPassword` `CustomSmsSender_ForgotPassword`  | ユーザーがパスワードのリセットをリクエストした場合。 | 
| カスタム送信者 |  `CustomEmailSender_UpdateUserAttribute` `CustomSmsSender_UpdateUserAttribute`  | ユーザーが E メールアドレスまたは電話番号を変更し、Amazon Cognito が検証コードを送信した場合。 | 
| カスタム送信者 |  `CustomEmailSender_VerifyUserAttribute` `CustomSmsSender_VerifyUserAttribute`  | ユーザーが E メールアドレスまたは電話番号を追加し、Amazon Cognito が検証コードを送信した場合。 | 
| カスタム送信者 |  `CustomEmailSender_Authentication` `CustomSmsSender_Authentication`  | SMS、E メール MFA、または OTP を設定したユーザーがサインインした場合。 | 
| カスタム送信者 | CustomEmailSender\$1AccountTakeOverNotification | 脅威保護設定により、ユーザーのサインイン試行に対して自動アクションが実行され、リスクレベルのアクションに通知が含まれている場合。 | 

# サインアップ前の Lambda トリガー
<a name="user-pool-lambda-pre-sign-up"></a>

セルフサービスのサインアップオプションがあるユーザープールでサインアッププロセスをカスタマイズする場合があります。サインアップ前トリガーの一般的な用途は、新規ユーザーのカスタム分析と記録の実行、セキュリティとガバナンスの基準の適用、またはサードパーティー IdP から[統合されたユーザープロファイル](cognito-user-pools-identity-federation-consolidate-users.md)へのユーザーのリンクです。また、[検証と確認](signing-up-users-in-your-app.md)を受ける必要がない信頼されたユーザーが存在する場合もあります。

Amazon Cognito は、[ローカル](cognito-terms.md#terms-localuser)ユーザーまたは[フェデレーション](cognito-terms.md#terms-federateduser)ユーザーの新規作成を完了する直前に、サインアップ前 Lambda 関数をアクティブ化します。この関数に送信したリクエストオブジェクトの `userAttributes` には、ローカルユーザーのサインアップ時に指定した属性、またはフェデレーションユーザーのプロバイダー属性から正常にマッピングされた属性が含まれています。ユーザープールは、[SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) によるセルフサービスのサインアップ時や信頼できる [ID プロバイダー](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-federated)による初回サインイン時、および [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html) によるユーザー作成時に、このトリガーを呼び出します。サインアッププロセスの一環として、この関数を使用してカスタムロジックでのサインインイベントの分析や、新しいユーザーの変更または拒否ができます。

**Topics**
+ [サインアップ前の Lambda トリガーのパラメータ](#cognito-user-pools-lambda-trigger-syntax-pre-signup)
+ [サインアップ前の例: 登録済みドメインのユーザーを自動確認する](#aws-lambda-triggers-pre-registration-example)
+ [サインアップ前の例: すべてのユーザーを自動確認して自動検証する](#aws-lambda-triggers-pre-registration-example-2)
+ [サインアップ前の例:ユーザー名が 5 文字未満の場合にサインアップを拒否する](#aws-lambda-triggers-pre-registration-example-3)

## サインアップ前の Lambda トリガーのパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-pre-signup"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
        "userAttributes": {
            "string": "string",
            . . .
        },
        "validationData": {
            "string": "string",
            . . .
         },
        "clientMetadata": {
            "string": "string",
            . . .
         }
    },

    "response": {
        "autoConfirmUser": "boolean",
        "autoVerifyPhone": "boolean",
        "autoVerifyEmail": "boolean"
    }
}
```

------

### サインアップ前のリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-pre-signup-request"></a>

**userAttributes**  
ユーザー属性を表す 1 つ以上の名前 - 値ペア。属性名はキーです。

**validationData**  
新しいユーザーの作成リクエストでアプリケーションから Amazon Cognito に渡したユーザー属性データを示す 1 つ以上のキーと値のペアです。この情報を [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html) API リクエストまたは [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) API リクエストの ValidationData パラメータで Lambda 関数に送信します。  
Amazon Cognito は、ValidationData データを、作成したユーザーの属性として設定しません。ValidationData は、サインアップ前 Lambda トリガーのためにユーザーが提供する一時的なユーザー情報です。

**clientMetadata**  
サインアップ前のトリガーに指定する Lambda 関数へのカスタム入力として提供できる 1 つ、または複数のキー/値ペア。このデータは、[AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html)、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html)、[ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html)、および [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) の API アクションで ClientMetadata パラメータを使用することによって Lambda 関数に渡すことができます。

### サインアップ前のレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-pre-signup-response"></a>

ユーザーを自動的に確認する場合は、レスポンスで `autoConfirmUser` を `true` に設定できます。`autoVerifyEmail` を `true` に設定してユーザーの E メールを自動検証できます。`autoVerifyPhone` を `true` に設定してユーザーの電話番号を自動検証できます。

**注記**  
サインアップ前 Lambda 関数が `AdminCreateUser` API によってトリガーされる場合、レスポンスパラメータの `autoVerifyPhone`、`autoVerifyEmail`、および `autoConfirmUser` は Amazon Cognito によって無視されます。

**autoConfirmUser**  
ユーザーを自動的に確認する場合は `true` に、それ以外の場合は `false` に設定します。

**autoVerifyEmail**  
`true` に設定すると、サインアップしたユーザーの E メールアドレスを検証済みとして設定します。それ以外の場合は `false` です。`autoVerifyEmail` が `true` に設定されている場合、`email` 属性は有効な null 以外の値である必要があります。それ以外の場合はエラーが発生し、ユーザーがサインアップを完了できません。  
`email` 属性がエイリアスとして選択されている場合、`autoVerifyEmail` が設定されていると、ユーザーの E メールアドレスのエイリアスが自動的に作成されます。その E メールアドレスのエイリアスが既に存在している場合は、エイリアスは新規ユーザーに移動され、以前のユーザーの E メールアドレスは未検証としてマークされます。詳細については、「[ログイン属性のカスタマイズ](user-pool-settings-attributes.md#user-pool-settings-aliases)」を参照してください。

**autoVerifyPhone**  
`true` に設定すると、サインアップしたユーザーの電話番号を検証済みとして設定します。それ以外の場合は `false` です。`autoVerifyPhone` が `true` に設定されている場合、`phone_number` 属性は有効な null 以外の値である必要があります。それ以外の場合はエラーが発生し、ユーザーがサインアップを完了できません。  
`phone_number` 属性がエイリアスとして選択されている場合、`autoVerifyPhone` が設定されていると、ユーザーの電話番号のエイリアスが自動的に作成されます。その電話番号のエイリアスが既に存在している場合、エイリアスは新規ユーザーに移動され、以前のユーザーの電話番号は未検証としてマークされます。詳細については、「[ログイン属性のカスタマイズ](user-pool-settings-attributes.md#user-pool-settings-aliases)」を参照してください。

## サインアップ前の例: 登録済みドメインのユーザーを自動確認する
<a name="aws-lambda-triggers-pre-registration-example"></a>

これは Lambda トリガーコードの例です。サインアップ前トリガーは、Amazon Cognito がサインアップリクエストを処理する直前に呼び出されます。これは、カスタム属性の [**custom:domain**] を使用して特定の E メールドメインからの新しいユーザーを自動的に確認します。このカスタムドメインに属していない新しいユーザーは、ユーザープールには追加されますが、自動的には確認されません。

------
#### [ Node.js ]

```
export const handler = async (event, context, callback) => {
  // Set the user pool autoConfirmUser flag after validating the email domain
  event.response.autoConfirmUser = false;

  // Split the email address so we can compare domains
  var address = event.request.userAttributes.email.split("@");

  // This example uses a custom attribute "custom:domain"
  if (event.request.userAttributes.hasOwnProperty("custom:domain")) {
    if (event.request.userAttributes["custom:domain"] === address[1]) {
      event.response.autoConfirmUser = true;
    }
  }

  // Return to Amazon Cognito
  callback(null, event);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    # It sets the user pool autoConfirmUser flag after validating the email domain
    event['response']['autoConfirmUser'] = False

    # Split the email address so we can compare domains
    address = event['request']['userAttributes']['email'].split('@')

    # This example uses a custom attribute 'custom:domain'
    if 'custom:domain' in event['request']['userAttributes']:
        if event['request']['userAttributes']['custom:domain'] == address[1]:
            event['response']['autoConfirmUser'] = True

    # Return to Amazon Cognito
    return event
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
    "request": {
        "userAttributes": {
            "email": "testuser@example.com",
            "custom:domain": "example.com"
        }
    },
    "response": {}
}
```

------

## サインアップ前の例: すべてのユーザーを自動確認して自動検証する
<a name="aws-lambda-triggers-pre-registration-example-2"></a>

次の例では、すべてのユーザーを確認し、ユーザーの `email` 属性と `phone_number` 属性を検証済みとして設定します (属性が存在する場合)。また、エイリアシングが有効になっている場合は、自動検証が設定されていると、`phone_number` および `email` にエイリアスが作成されます。

**注記**  
同じ電話番号のエイリアスが既に存在している場合は、エイリアスは新規ユーザーに移動され、以前のユーザーの `phone_number` は未検証としてマークされます。E メールアドレスの場合も同様です。これを防ぐには、ユーザープール [ListUsers API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html) を使用して既存のユーザーの中に、新しいユーザーの電話番号や E メールアドレスをエイリアスとして既に使用しているユーザーがいないかどうかを確認します。

------
#### [ Node.js ]

```
exports.handler = (event, context, callback) => {
  // Confirm the user
  event.response.autoConfirmUser = true;

  // Set the email as verified if it is in the request
  if (event.request.userAttributes.hasOwnProperty("email")) {
    event.response.autoVerifyEmail = true;
  }

  // Set the phone number as verified if it is in the request
  if (event.request.userAttributes.hasOwnProperty("phone_number")) {
    event.response.autoVerifyPhone = true;
  }

  // Return to Amazon Cognito
  callback(null, event);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    # Confirm the user
    event['response']['autoConfirmUser'] = True

    # Set the email as verified if it is in the request
    if 'email' in event['request']['userAttributes']:
        event['response']['autoVerifyEmail'] = True

    # Set the phone number as verified if it is in the request
    if 'phone_number' in event['request']['userAttributes']:
        event['response']['autoVerifyPhone'] = True

    # Return to Amazon Cognito
    return event
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
  "request": {
    "userAttributes": {
      "email": "user@example.com",
      "phone_number": "+12065550100"
    }
  },
  "response": {}
}
```

------

## サインアップ前の例:ユーザー名が 5 文字未満の場合にサインアップを拒否する
<a name="aws-lambda-triggers-pre-registration-example-3"></a>

次の例は、サインアップリクエストのユーザー名の長さを調べます。次の例は、ユーザーが 5 文字未満の名前を入力した場合、エラーを返します。

------
#### [ Node.js ]

```
export const handler = (event, context, callback) => {
    // Impose a condition that the minimum length of the username is 5 is imposed on all user pools.
    if (event.userName.length < 5) {
        var error = new Error("Cannot register users with username less than the minimum length of 5");
        // Return error to Amazon Cognito
        callback(error, event);
    }
    // Return to Amazon Cognito
    callback(null, event);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    if len(event['userName']) < 5:
        raise Exception("Cannot register users with username less than the minimum length of 5")
    # Return to Amazon Cognito
    return event
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
  "userName": "rroe",
  "response": {}
}
```

------

# 確認後の Lambda トリガー
<a name="user-pool-lambda-post-confirmation"></a>

Amazon Cognito は、サインアップしたユーザーがユーザーアカウントを確認した後にこのトリガーを呼び出します。投稿確認 Lambda 関数では、カスタムメッセージを送信したり、カスタム API リクエストを追加したりできます。たとえば、外部システムにクエリを実行して、ユーザーに追加の属性を入力できます。Amazon Cognito は、管理者認証情報を使用して作成したユーザーではなく、ユーザープールにサインアップしたユーザーに対してのみこのトリガーを呼び出します。

リクエストには、確認されたユーザーの現在の属性が含まれています。ユーザープールは、[ConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html)、[AdminConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminConfirmSignUp.html)、[ConfirmForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html) に対して確認後の関数を呼び出します。このトリガーは、ユーザーが[マネージドログイン](cognito-user-pools-managed-login.md)でサインアップまたはパスワードのリセットを確認したときにも実行されます。

**Topics**
+ [確認後の Lambda トリガーのパラメータ](#cognito-user-pools-lambda-trigger-syntax-post-confirmation)
+ [確認後の例](#aws-lambda-triggers-post-confirmation-example)

## 確認後の Lambda トリガーのパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-post-confirmation"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
            "userAttributes": {
                "string": "string",
                . . .
            },
            "clientMetadata": {
            	"string": "string",
            	. . .
            }
        },
    "response": {}
}
```

------

### 確認後のリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-post-confirmation-request"></a>

**userAttributes**  
ユーザー属性を表す 1 つ以上のキーバリューペア。

**clientMetadata**  
確認後のトリガーに指定する Lambda 関数へのカスタム入力として提供できる 1 つ、または複数のキー/値ペア。このデータは、[AdminConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminConfirmSignUp.html)、[ConfirmForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html)、[ConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html)、および [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) の API アクションで ClientMetadata パラメータを使用することによって Lambda 関数に渡すことができます。

### 確認後のレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-post-confirmation-response"></a>

レスポンスで返される追加の情報は想定されていません。

## 確認後の例
<a name="aws-lambda-triggers-post-confirmation-example"></a>

この Lambda 関数の例では、Amazon SES を使用してユーザーに確認 E メールメッセージを送信します。詳細については、[Amazon Simple Email Service デベロッパーガイド](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/)を参照してください。

------
#### [ Node.js ]

```
// Import required AWS SDK clients and commands for Node.js. Note that this requires
// the `@aws-sdk/client-ses` module to be either bundled with this code or included
// as a Lambda layer.
import { SES, SendEmailCommand } from "@aws-sdk/client-ses";
const ses = new SES();

const handler = async (event) => {
  if (event.request.userAttributes.email) {
    await sendTheEmail(
      event.request.userAttributes.email,
      `Congratulations ${event.userName}, you have been confirmed.`,
    );
  }
  return event;
};

const sendTheEmail = async (to, body) => {
  const eParams = {
    Destination: {
      ToAddresses: [to],
    },
    Message: {
      Body: {
        Text: {
          Data: body,
        },
      },
      Subject: {
        Data: "Cognito Identity Provider registration completed",
      },
    },
    // Replace source_email with your SES validated email address
    Source: "<source_email>",
  };
  try {
    await ses.send(new SendEmailCommand(eParams));
  } catch (err) {
    console.log(err);
  }
};

export { handler };
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
    "request": {
        "userAttributes": {
            "email": "user@example.com",
            "email_verified": true
        }
    },
    "response": {}
}
```

------

# 認証前の Lambda トリガー
<a name="user-pool-lambda-pre-authentication"></a>

Amazon Cognito は、ユーザーがサインインしようとするときにこのトリガーを呼び出し、準備アクションを実行するカスタム認証を作成できるようにします。たとえば、認証リクエストを拒否したり、外部システムへのセッションデータを記録したりできます。

**注記**  
この Lambda トリガーは、ユーザープールのアプリケーションクライアントの `PreventUserExistenceErrors` 設定を `ENABLED` に指定していない限り、ユーザーが存在しない場合はアクティブになりません。既存の認証セッションを更新しても、このトリガーはアクティブになりません。

**Topics**
+ [フローの概要](#user-pool-lambda-pre-authentication-1)
+ [認証前の Lambda トリガーのパラメータ](#cognito-user-pools-lambda-trigger-syntax-pre-auth)
+ [事前認証の例](#aws-lambda-triggers-pre-authentication-example)

## フローの概要
<a name="user-pool-lambda-pre-authentication-1"></a>

![\[認証前の Lambda トリガー - クライアントフロー\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/lambda-pre-authentication-1.png)


リクエストには、アプリケーションからユーザープールの `InitiateAuth` および `AdminInitiateAuth` API オペレーションに渡す `ClientMetadata` 値のクライアント検証データが含まれます。

詳細については、「[認証セッションの例](authentication.md#amazon-cognito-user-pools-authentication-flow)」を参照してください。

## 認証前の Lambda トリガーのパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-pre-auth"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
        "userAttributes": {
            "string": "string",
            . . .
        },
        "validationData": {
            "string": "string",
            . . .
        },
        "userNotFound": boolean
    },
    "response": {}
}
```

------

### 認証前のリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-pre-auth-request"></a>

**userAttributes**  
ユーザー属性を表す 1 つ以上の名前 - 値ペア。

**userNotFound**  
ユーザープールクライアントの `PreventUserExistenceErrors` を `ENABLED` に設定すると、Amazon Cognito はこのブール値を入力します。

**validationData**  
ユーザーのサインインリクエストに検証データを含む 1 つ以上のキーバリューペア。このデータを Lambda 関数に渡すには、[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) API アクションで ClientMetadata パラメータを使用します。

### 認証前のレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-pre-auth-response"></a>

Amazon Cognito は、関数がレスポンスで返す追加情報を処理しません。関数がエラーを返してサインイン試行を拒否したり、API オペレーションを使用してリソースをクエリしたり変更できます。

## 事前認証の例
<a name="aws-lambda-triggers-pre-authentication-example"></a>

このサンプル関数は、特定のアプリクライアントからユーザープールにサインインされるのを防ぎます。事前認証の Lambda 関数は、ユーザーが既存のセッションを持っている場合は呼び出されないため、この関数はブロックするアプリクライアント ID の*新規*セッションのみを防止します。

------
#### [ Node.js ]

```
const handler = async (event) => {
  if (
    event.callerContext.clientId === "user-pool-app-client-id-to-be-blocked"
  ) {
    throw new Error("Cannot authenticate users from this user pool app client");
  }

  return event;
};

export { handler };
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    if event['callerContext']['clientId'] == "<user pool app client id to be blocked>":
        raise Exception("Cannot authenticate users from this user pool app client")

    # Return to Amazon Cognito
    return event
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
    "callerContext": {
        "clientId": "<user pool app client id to be blocked>"
    },
    "response": {}
}
```

------

# 認証後の Lambda トリガー
<a name="user-pool-lambda-post-authentication"></a>

認証後トリガーは、ユーザーの認証フローを変更しません。Amazon Cognito は、認証が完了した後で、ユーザーがトークンを受け取る前に、この Lambda を呼び出します。次のサインインに反映されるログ記録やユーザープロファイルの調整など、認証イベントの後処理をカスタムで追加する場合は、認証後トリガーを追加します。

リクエスト本文を Amazon Cognito に返さない認証後 Lambda は、認証の完了に失敗する可能性があります。詳細については、「[Lambda トリガーについて知っておくべきこと](cognito-user-pools-working-with-lambda-triggers.md#important-lambda-considerations)」を参照してください。

**Topics**
+ [認証フローの概要](#user-pool-lambda-post-authentication-1)
+ [認証後の Lambda トリガーのパラメータ](#cognito-user-pools-lambda-trigger-syntax-post-auth)
+ [認証後の例](#aws-lambda-triggers-post-authentication-example)

## 認証フローの概要
<a name="user-pool-lambda-post-authentication-1"></a>

![\[認証後の Lambda トリガー - クライアントフロー\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/lambda-post-authentication-1.png)


詳細については、「[認証セッションの例](authentication.md#amazon-cognito-user-pools-authentication-flow)」を参照してください。

## 認証後の Lambda トリガーのパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-post-auth"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
        "userAttributes": {
             "string": "string",
             . . .
         },
         "newDeviceUsed": boolean,
         "clientMetadata": {
             "string": "string",
             . . .
            }
        },
    "response": {}
}
```

------

### 認証後のリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-post-auth-request"></a>

**newDeviceUsed**  
このフラグは、ユーザーが新しいデバイスにサインインしているかどうかを示します。Amazon Cognito は、ユーザープールの記憶済みデバイス値が `Always` または `User Opt-In` である場合にのみ、このフラグを設定します。

**userAttributes**  
ユーザー属性を表す 1 つ以上の名前 - 値ペア。

**clientMetadata**  
認証後のトリガーに指定する Lambda 関数へのカスタム入力として提供できる 1 つ、または複数のキー/値ペア。このデータを Lambda 関数に渡すには、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) および [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) API アクションで ClientMetadata パラメータを使用します。Amazon Cognito は、認証後関数に渡すリクエストの [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) および [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションの ClientMetadata パラメータからのデータを含めません。

### 認証後のレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-post-auth-response"></a>

Amazon Cognito は、レスポンスに追加の返品情報を期待しません。関数では、API オペレーションを使用してリソースをクエリして変更したり、イベントメタデータを外部システムに記録することができます。

## 認証後の例
<a name="aws-lambda-triggers-post-authentication-example"></a>

この認証後の Lambda 関数のサンプルは、正常に行われたサインインからのデータをCloudWatch Logs に送信します。

------
#### [ Node.js ]

```
const handler = async (event) => {
  // Send post authentication data to Amazon CloudWatch logs
  console.log("Authentication successful");
  console.log("Trigger function =", event.triggerSource);
  console.log("User pool = ", event.userPoolId);
  console.log("App client ID = ", event.callerContext.clientId);
  console.log("User ID = ", event.userName);

  return event;
};

export { handler };
```

------
#### [ Python ]

```
import os
def lambda_handler(event, context):

    # Send post authentication data to Cloudwatch logs
    print ("Authentication successful")
    print ("Trigger function =", event['triggerSource'])
    print ("User pool = ", event['userPoolId'])
    print ("App client ID = ", event['callerContext']['clientId'])
    print ("User ID = ", event['userName'])

    # Return to Amazon Cognito
    return event
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
  "triggerSource": "testTrigger",
  "userPoolId": "testPool",
  "userName": "testName",
  "callerContext": {
      "clientId": "12345"
  },
  "response": {}
}
```

------

# インバウンドフェデレーション Lambda トリガー
<a name="user-pool-lambda-inbound-federation"></a>

インバウンドフェデレーショントリガーは、外部 ID プロバイダーによる認証プロセス中にフェデレーションユーザー属性を変換します。ユーザーが設定された ID プロバイダーを介して認証する場合、このトリガーにより、認証プロセスでデータを傍受して変換することで外部 SAML プロバイダーと OIDC プロバイダーからのレスポンスを変更でき、Amazon Cognito ユーザープールがフェデレーティッドユーザーとその属性を処理する方法をプログラムで制御できます。

このトリガーを使用して、新しいユーザーを作成する前、または既存のフェデレーティッドユーザープロファイルを更新する前に、属性を追加、上書き、または抑制します。このトリガーは、raw ID プロバイダー属性を入力として受け取り、Amazon Cognito がユーザープロファイルに適用する変更された属性を返します。

**Topics**
+ [フローの概要](#cognito-user-pools-lambda-trigger-inbound-federation-flow)
+ [インバウンドフェデレーション Lambda トリガーパラメータ](#cognito-user-pools-lambda-trigger-syntax-inbound-federation)
+ [インバウンドフェデレーションの例: グループメンバーシップ管理](#aws-lambda-triggers-inbound-federation-example-groups)
+ [インバウンドフェデレーションの例: 大きな属性を切り捨てる](#aws-lambda-triggers-inbound-federation-example-truncate)
+ [インバウンドフェデレーションの例: フェデレーションイベントのログ記録](#aws-lambda-triggers-inbound-federation-example-logging)

## フローの概要
<a name="cognito-user-pools-lambda-trigger-inbound-federation-flow"></a>

ユーザーが外部 ID プロバイダーで認証されると、Amazon Cognito はユーザープロファイルを作成または更新する前にインバウンドフェデレーショントリガーを呼び出します。トリガーは ID プロバイダーから raw 属性を受け取り、Amazon Cognito が保存する前に変換できます。このフローは、フェデレーションを通じて再度サインインする新しいフェデレーティッドユーザーと既存のユーザーの両方に発生します。

![\[インバウンドフェデレーション Lambda トリガーフロー\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/lambda-inbound-federation.png)


## インバウンドフェデレーション Lambda トリガーパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-inbound-federation"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "version": "string",
    "triggerSource": "InboundFederation_ExternalProvider",
    "region": AWSRegion,
    "userPoolId": "string",
    "userName": "string",
    "callerContext": {
        "awsSdkVersion": "string",
        "clientId": "string"
    },
    "request": {
        "providerName": "string",
        "providerType": "string",
        "attributes": {
            "tokenResponse": {
                "access_token": "string",
                "token_type": "string",
                "expires_in": "string"
            },
            "idToken": {
                "sub": "string",
                "email": "string",
                "email_verified": "string"
            },
            "userInfo": {
                "email": "string",
                "given_name": "string",
                "family_name": "string"
            },
            "samlResponse": {
                "string": "string"
            }
        }
    },
    "response": {
        "userAttributesToMap": {
            "string": "string"
        }
    }
}
```

------

### インバウンドフェデレーションリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-inbound-federation-request"></a>

**providerName**  
外部 ID プロバイダーの名前。

**providerType**  
外部 ID プロバイダーのタイプ。有効な値: `OIDC`、`SAML`、、`Facebook`、`Google``SignInWithApple`、`LoginWithAmazon`。

**属性**  
処理前に ID プロバイダーから受信した raw 属性。構造はプロバイダータイプによって異なります。

**attributes.tokenResponse**  
`/token` エンドポイントからの OAuth トークンレスポンスデータ。OIDC およびソーシャルプロバイダーでのみ使用できます。`access_token`、`id_token`、、`refresh_token`、`token_type``expires_in`、および が含まれます`scope`。

**attributes.idToken**  
デコードおよび検証された ID トークン JWT クレーム。OIDC およびソーシャルプロバイダーでのみ使用できます。(一意のユーザー識別子)`email`、、`sub`、 (`iss`発行者)`name`、 `aud` (対象者）、 `exp` (有効期限）、 `iat` (発行時間) などの検証済みユーザー ID 情報が含まれます。

**attributes.userInfo**  
UserInfo エンドポイントからの拡張ユーザープロファイル情報。OIDC およびソーシャルプロバイダーでのみ使用できます。`given_name`、、`family_name`、`picture`、 などのプロバイダー固有のフィールドなど`address`、詳細なプロファイル属性が含まれます。IdP が UserInfo エンドポイントをサポートしていない場合、またはエンドポイント呼び出しが失敗した場合、空になる可能性があります。

**attributes.samlResponse**  
SAML アサーション属性。SAML プロバイダーでのみ使用できます。SAML レスポンスの属性が含まれます。

### インバウンドフェデレーションレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-inbound-federation-response"></a>

**userAttributesToMap**  
ユーザープロファイルに適用するユーザー属性。

**重要**  
変更しない属性を含め、レスポンスに保持するすべてのユーザー属性を含める必要があります。`userAttributesToMap` レスポンスに含まれていない属性は削除され、ユーザープロファイルに保存されません。これは、変更された属性と変更されていない属性の両方に適用されます。

**空のレスポンス動作**  
に空のオブジェクトを返した場合`{}``userAttributesToMap`、ID プロバイダーからのすべての元の属性は変更されません。これは、Lambda 関数が実行されなかったかのように、no-op として機能します。これは、削除される属性を省略する場合とは異なります。

**プロバイダー固有の属性**  
の構造は、 `request.attributes`によって異なります`providerType`。OIDC およびソーシャルプロバイダーには、`tokenResponse`、`idToken`、 `userInfo` オブジェクトが含まれます。SAML プロバイダーには `samlResponse` オブジェクトのみが含まれます。

## インバウンドフェデレーションの例: グループメンバーシップ管理
<a name="aws-lambda-triggers-inbound-federation-example-groups"></a>

この例では、フェデレーティッド ID プロバイダーグループを Amazon Cognito ユーザープールグループにマッピングする方法を示します。この関数は、フェデレーティッドレスポンスからグループメンバーシップを抽出し、対応する Amazon Cognito グループにユーザーを自動的に追加するため、認証後のトリガーが不要になります。

------
#### [ Node.js ]

```
exports.handler = async (event) => {
    const { providerType, attributes } = event.request;
    
    // Extract user attributes based on provider type
    let userAttributesFromIdp = {};
    if (providerType === 'SAML') {
        userAttributesFromIdp = attributes.samlResponse || {};
    } else {
        // For OIDC and Social providers, merge userInfo and idToken
        userAttributesFromIdp = {
            ...(attributes.userInfo || {}),
            ...(attributes.idToken || {})
        };
    }
    
    // Extract groups from federated response
    const federatedGroups = userAttributesFromIdp.groups?.split(',') || [];
    
    // Map federated groups to Cognito groups
    const groupMapping = {
        'Domain Admins': 'Administrators',
        'Engineering': 'Developers',
        'Sales': 'SalesTeam'
    };
    
    // Filter to only in-scope groups
    const mappedGroups = federatedGroups
        .map(group => groupMapping[group.trim()])
        .filter(group => group); // Remove undefined values
    
    // Pass through attributes with mapped groups as custom attribute
    const attributesToMap = {
        ...userAttributesFromIdp,
        'custom:user_groups': mappedGroups.join(',')
    };
    
    // Remove original groups attribute
    delete attributesToMap.groups;
    
    event.response.userAttributesToMap = attributesToMap;
    return event;
};
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
    "userPoolId": "us-east-1_XXXXXXXXX",
    "request": {
        "providerName": "CorporateAD",
        "providerType": "SAML",
        "attributes": {
            "samlResponse": {
                "email": "jane.smith@company.com",
                "given_name": "Jane",
                "family_name": "Smith",
                "groups": "Engineering,Domain Admins",
                "department": "Engineering"
            }
        }
    },
    "response": {
        "userAttributesToMap": {}
    }
}
```

------

## インバウンドフェデレーションの例: 大きな属性を切り捨てる
<a name="aws-lambda-triggers-inbound-federation-example-truncate"></a>

この例では、Amazon Cognito のストレージ制限を超える属性値を切り捨てる方法を示します。この関数は、ID プロバイダーの各属性をチェックします。属性値が 2048 文字を超える場合、値は切り捨てられ、切り捨てを示す省略記号が追加されます。他のすべての属性は変更されずに渡されます。

------
#### [ Node.js ]

```
exports.handler = async (event) => {
    const MAX_ATTRIBUTE_LENGTH = 2048;
    
    // Get the identity provider attributes based on provider type
    const { providerType, attributes } = event.request;
    let idpAttributes = {};
    
    if (providerType === 'SAML') {
        idpAttributes = attributes.samlResponse || {};
    } else {
        // For OIDC and Social providers, merge userInfo and idToken
        idpAttributes = {
            ...(attributes.userInfo || {}),
            ...(attributes.idToken || {})
        };
    }
    
    const userAttributes = {};
    
    // Process each attribute
    for (const [key, value] of Object.entries(idpAttributes)) {
        if (typeof value === 'string' && value.length > MAX_ATTRIBUTE_LENGTH) {
            // Truncate the value and add ellipsis
            userAttributes[key] = value.substring(0, MAX_ATTRIBUTE_LENGTH - 3) + '...';
            console.log(`Truncated attribute ${key} from ${value.length} to ${userAttributes[key].length} characters`);
        } else {
            // Keep the original value
            userAttributes[key] = value;
        }
    }
    
    // Return the modified attributes
    event.response.userAttributesToMap = userAttributes;
    return event;
};
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
    "version": "string",
    "triggerSource": "InboundFederation_ExternalProvider",
    "region": "us-east-1",
    "userPoolId": "us-east-1_XXXXXXXXX",
    "userName": "ExampleProvider_12345",
    "callerContext": {
        "awsSdkVersion": "string",
        "clientId": "string"
    },
    "request": {
        "providerName": "ExampleProvider",
        "providerType": "OIDC",
        "attributes": {
            "tokenResponse": {
                "access_token": "abcDE...",
                "token_type": "Bearer",
                "expires_in": "3600"
            },
            "idToken": {
                "sub": "12345",
                "email": "user@example.com"
            },
            "userInfo": {
                "email": "user@example.com",
                "given_name": "Example",
                "family_name": "User",
                "bio": "This is a very long biography that contains more than 2048 characters..."
            }
        }
    },
    "response": {
        "userAttributesToMap": {}
    }
}
```

------

## インバウンドフェデレーションの例: フェデレーションイベントのログ記録
<a name="aws-lambda-triggers-inbound-federation-example-logging"></a>

この例では、モニタリングとデバッグのためにフェデレーティッド認証イベントを記録する方法を示します。このサンプル関数は、フェデレーティッドユーザーとその属性に関する詳細情報をキャプチャし、認証プロセスを可視化します。

------
#### [ Node.js ]

```
exports.handler = async (event) => {
    const { providerName, providerType, attributes } = event.request;
    
    // Extract user attributes based on provider type
    let userAttributesFromIdp = {};
    if (providerType === 'SAML') {
        userAttributesFromIdp = attributes.samlResponse || {};
    } else {
        // For OIDC and Social providers, merge userInfo and idToken
        userAttributesFromIdp = {
            ...(attributes.userInfo || {}),
            ...(attributes.idToken || {})
        };
    }
    
    // Log federated authentication details
    console.log(JSON.stringify({
        timestamp: new Date().toISOString(),
        providerName,
        providerType,
        userEmail: userAttributesFromIdp.email,
        attributeCount: Object.keys(userAttributesFromIdp).length,
        attributes: userAttributesFromIdp
    }));
    
    // Pass through all attributes unchanged
    event.response.userAttributesToMap = userAttributesFromIdp;
    return event;
};
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
    "version": "string",
    "triggerSource": "InboundFederation_ExternalProvider",
    "region": "us-east-1",
    "userPoolId": "us-east-1_XXXXXXXXX",
    "userName": "CorporateAD_john.doe",
    "callerContext": {
        "awsSdkVersion": "string",
        "clientId": "string"
    },
    "request": {
        "providerName": "CorporateAD",
        "providerType": "SAML",
        "attributes": {
            "samlResponse": {
                "email": "john.doe@company.com",
                "given_name": "John",
                "family_name": "Doe",
                "department": "Engineering",
                "employee_id": "EMP12345"
            }
        }
    },
    "response": {
        "userAttributesToMap": {}
    }
}
```

------

予想される CloudWatch Logs 出力:

------
#### [ JSON ]

```
{
    "timestamp": "2025-01-14T21:17:40.153Z",
    "providerName": "CorporateAD",
    "providerType": "SAML",
    "userEmail": "john.doe@company.com",
    "attributeCount": 5,
    "attributes": {
        "email": "john.doe@company.com",
        "given_name": "John",
        "family_name": "Doe",
        "department": "Engineering",
        "employee_id": "EMP12345"
    }
}
```

------

# カスタム認証チャレンジの Lambda トリガー
<a name="user-pool-lambda-challenge"></a>

Amazon Cognito ユーザープールの認証フローを構築した後で、組み込みフローを超えた認証モデルに拡張したい場合があります。カスタムチャレンジトリガーの一般的なユースケースの 1 つは、ユーザー名、パスワード、および多要素認証 (MFA) を超えた追加のセキュリティチェックを実装することです。カスタムチャレンジは、Lambda がサポートするプログラミング言語で生成できる質問とレスポンスです。例えば、認証を許可する前に、CAPTCHA を解決することや、セキュリティの質問に回答することをユーザーに要求する場合があります。もう 1 つの潜在的なニーズは、特殊な認証要素やデバイスと統合することです。または、ハードウェアセキュリティキーまたは生体認証デバイスでユーザーを認証するソフトウェアを開発済みである場合もあります。カスタムチャレンジの認証成功の定義は、どのような回答であっても、Lambda 関数が正しいものとして受け入れる回答です。例えば、固定文字列、または外部 API からの十分なレスポンスです。

カスタムチャレンジを使用した認証を開始して認証プロセスを完全に制御することも、アプリケーションがカスタムチャレンジを受信する前にユーザー名パスワード認証を実行することもできます。

カスタム認証チャレンジの Lambda トリガー

**[定義](user-pool-lambda-define-auth-challenge.md)**  
チャレンジシーケンスを開始します。新しいチャレンジを開始するか、認証を完了としてマークするか、認証の試行を停止するかを決定します。

**[作成](user-pool-lambda-create-auth-challenge.md)**  
ユーザーが回答する必要がある質問をアプリケーションに発行します。この関数は、アプリケーションがユーザーに表示するセキュリティの質問や CAPTCHA へのリンクを提示する場合があります。

**[検証](user-pool-lambda-verify-auth-challenge-response.md)**  
予想される回答を把握し、それをチャレンジレスポンスでアプリケーションが提供する回答と比較します。この関数は、CAPTCHA サービスの API を呼び出して、ユーザーの試行したソリューションの期待される結果を取得することができます。

これらの 3 つの Lambda 関数は連鎖して、完全に制御範囲内で独自の設計の認証メカニズムを提示します。カスタム認証は、クライアントと Lambda 関数にアプリケーションロジックを必要とするため、マネージドログイン内ではカスタム認証を処理できません。この認証システムには、デベロッパーの労力が追加で必要です。アプリケーションは、ユーザープール API を使用して認証フローを実行し、結果として返されるチャレンジを、カスタム構築されたログインインターフェイスで処理する必要があります。このインターフェイスは、カスタム認証チャレンジの中心に質問を表示します。

![\[チャレンジの Lambda トリガー\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/lambda-challenges.png)


カスタム認証の実装の詳細については、「[カスタム認証フローとチャレンジ](amazon-cognito-user-pools-authentication-flow-methods.md#Custom-authentication-flow-and-challenges)」を参照してください。

API オペレーション [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) と [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) または [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) 間の認証。このフローでは、認証が失敗するか、トークンが発行されるまで、ユーザーは引き続きチャレンジに回答して認証を行います。チャレンジレスポンスが新しいチャレンジとなる場合があります。この場合、アプリケーションは新しいチャレンジに対して必要な回数を応答します。認証は、認証チャレンジの定義関数がそれまでの結果を分析し、すべてのチャレンジが回答されたと判断し、`IssueTokens` を返すときに完了します。

**Topics**
+ [カスタムチャレンジフローでの SRP 認証](#user-pool-lambda-challenge-srp-authentication)
+ [認証チャレンジの定義の Lambda トリガー](user-pool-lambda-define-auth-challenge.md)
+ [認証チャレンジの作成の Lambda トリガー](user-pool-lambda-create-auth-challenge.md)
+ [認証チャレンジレスポンスの検証の Lambda トリガー](user-pool-lambda-verify-auth-challenge-response.md)

## カスタムチャレンジフローでの SRP 認証
<a name="user-pool-lambda-challenge-srp-authentication"></a>

Amazon Cognito では、カスタムチャレンジを発行する前にユーザーパスワードを検証させることができます。[リクエストレートクォータ](quotas.md#category_operations.title)の認証カテゴリに関連付けられているすべての Lambda トリガーは、カスタムチャレンジフローで SRP 認証を行うと、実行されます。以下は、そのプロセスの概要です。

1. アプリは、`AuthParameters` マップを使用して `InitiateAuth` または `AdminInitiateAuth` を呼び出してサインインを開始します。パラメータには `CHALLENGE_NAME: SRP_A,`、`SRP_A` および `USERNAME` の値を含める必要があります。

1. Amazon Cognito は、`challengeName: SRP_A` と `challengeResult: true` を含む初期セッションで、認証チャレンジの定義 Lambda トリガーを呼び出します。

1. Lambda 関数は、これらの入力を受け取った後、`challengeName: PASSWORD_VERIFIER`、`issueTokens: false`、`failAuthentication: false` で応答します。

1. パスワードの検証が成功すると、Amazon Cognito `challengeName: PASSWORD_VERIFIER` と `challengeResult: true` が含まれる新しいセッションで Lambda 関数を再度呼び出します。

1. カスタムチャレンジを開始するために、Lambda 関数は `challengeName: CUSTOM_CHALLENGE`、`issueTokens: false`、および `failAuthentication: false` で応答します。パスワード検証でカスタム認証フローを開始したくない場合は、`CHALLENGE_NAME: CUSTOM_CHALLENGE` を含む `AuthParameters` マップでサインインを開始できます。

1. チャレンジループは、すべてのチャレンジが回答されるまで繰り返します。

以下は、SRP フローによるカスタム認証の前になされる開始 `InitiateAuth` リクエストの例です。

```
{
    "AuthFlow": "CUSTOM_AUTH",
    "ClientId": "1example23456789",
    "AuthParameters": {
        "CHALLENGE_NAME": "SRP_A",
        "USERNAME": "testuser",
        "SRP_A": "[SRP_A]",
        "SECRET_HASH": "[secret hash]"
    }
}
```

### カスタム認証 SRP フローでのパスワードのリセット
<a name="user-pool-lambda-challenge-force-password-change"></a>

ユーザーが `FORCE_CHANGE_PASSWORD` ステータスの場合、カスタム認証フローは、認証チャレンジの整合性を維持しながら、パスワード変更ステップを統合する必要があります。Amazon Cognito は、`NEW_PASSWORD_REQUIRED` チャレンジ中に [[認証チャレンジを定義]](user-pool-lambda-define-auth-challenge.md) Lambda トリガーを呼び出します。このシナリオの場合、ユーザーがカスタムチャレンジフローと SRP 認証を使用してサインインするときに、パスワードのリセット状態にあれば、新しいパスワードを設定できます。

ユーザーは、`RESET_REQUIRED` ステータスまたは `FORCE_CHANGE_PASSWORD` ステータスである場合、`NEW_PASSWORD` を使用して `NEW_PASSWORD_REQUIRED` チャレンジに[応答](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html#API_RespondToAuthChallenge_RequestParameters)する必要があります。SRP を使用したカスタム認証の場合、ユーザーが SRP `NEW_PASSWORD_REQUIRED` チャレンジを完了すると、Amazon Cognito は `PASSWORD_VERIFIER` チャレンジを返します。認証チャレンジ定義トリガーは、両方のチャレンジ結果を `session` 配列で受け取り、ユーザーがパスワードを正常に変更した後で、追加のカスタムチャレンジを続行できます。

認証チャレンジ定義の Lambda トリガーは、SRP 認証、パスワードリセット、以降のカスタムチャレンジを通じて、チャレンジシーケンスを管理する必要があります。トリガーは、完了したチャレンジの配列 (`PASSWORD_VERIFIER` と `NEW_PASSWORD_REQUIRED` の両方の結果を含む) を `session` パラメータで受け取ります。実装の例については、「[認証チャレンジの定義の例](user-pool-lambda-define-auth-challenge.md#aws-lambda-triggers-define-auth-challenge-example)」を参照してください。

#### 認証フローの手順
<a name="user-pool-lambda-challenge-password-flow-steps"></a>

ユーザーがカスタムチャレンジの前にパスワードを検証する必要がある場合は、次の手順に従います。

1. アプリは、`AuthParameters` マップを使用して `InitiateAuth` または `AdminInitiateAuth` を呼び出してサインインを開始します。パラメータには `CHALLENGE_NAME: SRP_A` に加えて、`SRP_A` と `USERNAME` の値を含める必要があります。

1. Amazon Cognito は、`challengeName: SRP_A` と `challengeResult: true` を含む初期セッションで、認証チャレンジの定義 Lambda トリガーを呼び出します。

1. Lambda 関数は、これらの入力を受け取った後、`challengeName: PASSWORD_VERIFIER`、`issueTokens: false`、`failAuthentication: false` で応答します。

1. パスワードの検証が成功すると、次の 2 つのどちらかになります。  
**通常ステータスのユーザーの場合:**  
Amazon Cognito は、`challengeName: PASSWORD_VERIFIER` と `challengeResult: true` を含む新しいセッションで Lambda 関数を再度呼び出します。  
カスタムチャレンジを開始するために、Lambda 関数は `challengeName: CUSTOM_CHALLENGE`、`issueTokens: false`、および `failAuthentication: false` で応答します。  
**`RESET_REQUIRED` ステータスまたは `FORCE_CHANGE_PASSWORD` ステータスのユーザーの場合:**  
Amazon Cognito は、`challengeName: PASSWORD_VERIFIER` と `challengeResult: true` を含むセッションで Lambda 関数を呼び出します。  
Lambda 関数は、`challengeName: NEW_PASSWORD_REQUIRED`、`issueTokens: false`、および `failAuthentication: false` により、これに応答する必要があります。  
パスワードが正常に変更されると、Amazon Cognito は `PASSWORD_VERIFIER` と `NEW_PASSWORD_REQUIRED` の両方の結果を含むセッションで Lambda 関数を呼び出します。  
カスタムチャレンジを開始するために、Lambda 関数は `challengeName: CUSTOM_CHALLENGE`、`issueTokens: false`、および `failAuthentication: false` で応答します。

1. チャレンジループは、すべてのチャレンジが回答されるまで繰り返します。

パスワード検証でカスタム認証フローを開始したくない場合は、`CHALLENGE_NAME: CUSTOM_CHALLENGE` を含む `AuthParameters` マップでサインインを開始できます。

#### セッション管理
<a name="user-pool-lambda-challenge-session-management"></a>

認証フローは、一連のセッション ID とチャレンジ結果を通じてセッションの継続性を維持します。チャレンジレスポンスごとに新しいセッション ID を生成して、セッション再利用エラーを防ぎます。これは、多要素認証フローでは特に重要です。

チャレンジの結果は、Lambda トリガーが受信するセッション配列に時系列で保存されます。`FORCE_CHANGE_PASSWORD` ステータスのユーザーの場合、セッション配列には以下が含まれます。

1. `session[0]` - 最初の `SRP_A` チャレンジ

1. `session[1]` - `PASSWORD_VERIFIER` の結果

1. `session[2]` - `NEW_PASSWORD_REQUIRED` の結果

1. 後続の要素 - 追加のカスタムチャレンジの結果

#### 認証フローの例
<a name="user-pool-lambda-challenge-example-flow"></a>

次の例は、パスワード変更とカスタム CAPTCHA チャレンジの両方を完了する必要があるユーザー (`FORCE_CHANGE_PASSWORD` ステータス) の完全なカスタム認証フローを示しています。

1. **InitiateAuth リクエスト**

   ```
   {
       "AuthFlow": "CUSTOM_AUTH",
       "ClientId": "1example23456789",
       "AuthParameters": {
           "CHALLENGE_NAME": "SRP_A",
           "USERNAME": "testuser",
           "SRP_A": "[SRP_A]"
       }
   }
   ```

1. **InitiateAuth レスポンス**

   ```
   {
       "ChallengeName": "PASSWORD_VERIFIER",
       "ChallengeParameters": {
           "USER_ID_FOR_SRP": "testuser"
       },
       "Session": "[session_id_1]"
   }
   ```

1. **`PASSWORD_VERIFIER` を使用した RespondToAuthChallenge リクエスト**

   ```
   {
       "ChallengeName": "PASSWORD_VERIFIER",
       "ClientId": "1example23456789",
       "ChallengeResponses": {
           "PASSWORD_CLAIM_SIGNATURE": "[claim_signature]",
           "PASSWORD_CLAIM_SECRET_BLOCK": "[secret_block]",
           "TIMESTAMP": "[timestamp]",
           "USERNAME": "testuser"
       },
       "Session": "[session_id_1]"
   }
   ```

1. **`NEW_PASSWORD_REQUIRED` チャレンジを使用した RespondToAuthChallenge レスポンス**

   ```
   {
       "ChallengeName": "NEW_PASSWORD_REQUIRED",
       "ChallengeParameters": {},
       "Session": "[session_id_2]"
   }
   ```

1. **`NEW_PASSWORD_REQUIRED` を使用した RespondToAuthChallenge リクエスト**

   ```
   {
       "ChallengeName": "NEW_PASSWORD_REQUIRED",
       "ClientId": "1example23456789",
       "ChallengeResponses": {
           "NEW_PASSWORD": "[password]",
           "USERNAME": "testuser"
       },
       "Session": "[session_id_2]"
   }
   ```

1. **CAPTCHA カスタムチャレンジを使用した RespondToAuthChallenge レスポンス**

   ```
   {
       "ChallengeName": "CUSTOM_CHALLENGE",
       "ChallengeParameters": {
           "captchaUrl": "url/123.jpg"
       },
       "Session": "[session_id_3]"
   }
   ```

1. **CAPTCHA カスタムチャレンジを使用した RespondToAuthChallenge リクエスト**

   ```
   {
       "ChallengeName": "CUSTOM_CHALLENGE",
       "ClientId": "1example23456789",
       "ChallengeResponses": {
           "ANSWER": "123",
           "USERNAME": "testuser"
       },
       "Session": "[session_id_3]"
   }
   ```

**6。最終的な成功レスポンス**

```
{
    "AuthenticationResult": {
        "AccessToken": "eyJra456defEXAMPLE",
        "ExpiresIn": 3600,
        "IdToken": "eyJra789ghiEXAMPLE",
        "RefreshToken": "eyJjd123abcEXAMPLE",
        "TokenType": "Bearer"
    },
    "ChallengeParameters": {}
}
```

# 認証チャレンジの定義の Lambda トリガー
<a name="user-pool-lambda-define-auth-challenge"></a>

認証チャレンジ定義トリガーは、カスタム認証フローでチャレンジシーケンスを維持する Lambda 関数です。チャレンジシーケンスの成功または失敗を宣言し、シーケンスがまだ完了していない場合に次のチャレンジを設定します。

![\[チャレンジの Lambda トリガー\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/lambda-challenges1.png)


**認証チャレンジの定義**  
 Amazon Cognito は、このトリガーを呼び出して[カスタム認証フロー](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html#amazon-cognito-user-pools-custom-authentication-flow)を開始します。

この Lambda トリガーのリクエストには、`session` が含まれます。`session` パラメータは、現在の認証プロセスでユーザーに提示されたすべてのチャレンジが含まれる配列です。リクエストには、対応する結果も含まれます。`session` 配列は、チャレンジの詳細 (`ChallengeResult`) を時系列に保存します。チャレンジ `session[0]` は、ユーザーが最初に受け取るチャレンジを表します。

**Topics**
+ [認証チャレンジの定義の Lambda トリガーのパラメータ](#cognito-user-pools-lambda-trigger-syntax-define-auth-challenge)
+ [認証チャレンジの定義の例](#aws-lambda-triggers-define-auth-challenge-example)

## 認証チャレンジの定義の Lambda トリガーのパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-define-auth-challenge"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
        "userAttributes": {
            "string": "string",
                . . .
        },
        "session": [
            ChallengeResult,
            . . .
        ],
        "clientMetadata": {
            "string": "string",
            . . .
        },
        "userNotFound": boolean
    },
    "response": {
        "challengeName": "string",
        "issueTokens": boolean,
        "failAuthentication": boolean
    }
}
```

------

### 認証チャレンジの定義のリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-define-auth-challenge-request"></a>

 Amazon Cognito が Lambda 関数を呼び出すときに、次のパラメータを提供します。

**userAttributes**  
ユーザー属性を表す 1 つ以上の名前 - 値ペア。

**userNotFound**  
ユーザープールクライアントの `PreventUserExistenceErrors` が `ENABLED` に設定されている場合に、Amazon Cognito が入力するブール値です。`true` の値は、ユーザー ID (ユーザー名、メールアドレス、その他の詳細など) が既存のいずれのユーザーとも一致しなかったことを意味します。`PreventUserExistenceErrors` が `ENABLED` に設定されている場合、サービスは存在しないユーザーをアプリに通知しません。Lambda 関数が同じユーザーエクスペリエンスを維持し、レイテンシーを考慮することをお勧めします。この方法では、発信者はユーザーが存在する場合と存在しない場合で異なる動作を検出することができません。

**セッション**  
`ChallengeResult` 要素の配列。それぞれに以下の要素が含まれます。    
**challengeName**  
次のチャレンジタイプのいずれかです: `CUSTOM_CHALLENGE`、`SRP_A`、`PASSWORD_VERIFIER`、`SMS_MFA`、`EMAIL_OTP`、`SOFTWARE_TOKEN_MFA`、`DEVICE_SRP_AUTH`、`DEVICE_PASSWORD_VERIFIER`、または `ADMIN_NO_SRP_AUTH`。  
認証チャレンジの定義機能が、多要素認証を設定したユーザーに `PASSWORD_VERIFIER` チャレンジを発行すると、Amazon Cognito はそれに続いて `SMS_MFA`、`EMAIL_OTP`、または `SOFTWARE_TOKEN_MFA` のチャレンジを行います。これらは、多要素認証コードのプロンプトです。関数には、`SMS_MFA`、`EMAIL_OTP`、および `SOFTWARE_TOKEN_MFA` のチャレンジからの入力イベントの処理を含めます。認証チャレンジの定義関数から MFA チャレンジを呼び出す必要はありません。  
ユーザーが正常に認証され、トークンが発行されるべきかを判断するときは、常に define auth challenge 関数で `challengeName` をチェックし、予想された値と一致することを確認します。  
**challengeResult**  
ユーザーが正常にチャレンジを完了した場合は `true` に、それ以外の場合は `false` に設定します。  
**challengeMetadata**  
カスタムチャレンジの名前を入力します。`challengeName` が `CUSTOM_CHALLENGE` である場合にのみ使用されます。

**clientMetadata**  
認証チャレンジの定義のトリガーに指定する Lambda 関数へのカスタム入力として提供できる 1 つ、または複数のキー/値ペア。このデータを Lambda 関数に渡すには、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) および [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) API オペレーションで `ClientMetadata` パラメータを使用できます。define auth challenge 関数を呼び出すリクエストに、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) および [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションの ClientMetadata パラメータに渡されたデータは含まれません。

### 認証チャレンジの定義のレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-define-auth-challenge-response"></a>

レスポンスで、認証プロセスの次のステージを返すことができます。

**challengeName**  
次のチャレンジの名前を含む文字列。ユーザーに新しいチャレンジを提示する場合は、ここでチャレンジ名を指定します。

**issueTokens**  
ユーザーが認証チャレンジを十分に完了したと判断した場合、`true` に設定します。ユーザーがチャレンジを十分に満たしていない場合は、`false` に設定します。

**failAuthentication**  
現在の認証プロセスを終了する場合は、`true` に設定します。現在の認証プロセスを続行するには、`false` に設定します。

## 認証チャレンジの定義の例
<a name="aws-lambda-triggers-define-auth-challenge-example"></a>

この例では、認証用に一連のチャレンジを定義し、それらのチャレンジがすべて正常に完了した場合にのみトークンを発行します。ユーザーが `SRP_A` チャレンジと `PASSWORD_VERIFIER` チャレンジを使用して SRP 認証を完了すると、この関数は、認証チャレンジの作成トリガーを呼び出す `CUSTOM_CHALLENGE` を、ユーザーに渡します。[認証チャレンジの作成例](user-pool-lambda-create-auth-challenge.md#aws-lambda-triggers-create-auth-challenge-example)と組み合わせることで、このシーケンスは、チャレンジ 3 で CAPTCHA チャレンジを提供し、チャレンジ 4 でセキュリティの質問を提供します。

ユーザーが CAPTCHA を解決してセキュリティの質問に回答すると、この関数は、ユーザープールがトークンを発行できることを確認します。SRP 認証は必須ではありません。CAPTCHA とセキュリティの質問をチャレンジ 1 とチャレンジ 2 として設定することもできます。認証チャレンジの定義関数が SRP チャレンジを宣言しない場合、ユーザーの成功はカスタムプロンプトへの応答によってのみ決定されます。

------
#### [ Node.js ]

```
const handler = async (event) => {
  if (
    event.request.session.length === 1 &&
    event.request.session[0].challengeName === "SRP_A"
  ) {
    event.response.issueTokens = false;
    event.response.failAuthentication = false;
    event.response.challengeName = "PASSWORD_VERIFIER";
  } else if (
    event.request.session.length === 2 &&
    event.request.session[1].challengeName === "PASSWORD_VERIFIER" &&
    event.request.session[1].challengeResult === true
  ) {
    event.response.issueTokens = false;
    event.response.failAuthentication = false;
    event.response.challengeName = "CUSTOM_CHALLENGE";
  } else if (
    event.request.session.length === 3 &&
    event.request.session[2].challengeName === "CUSTOM_CHALLENGE" &&
    event.request.session[2].challengeResult === true
  ) {
    event.response.issueTokens = false;
    event.response.failAuthentication = false;
    event.response.challengeName = "CUSTOM_CHALLENGE";
  } else if (
    event.request.session.length === 4 &&
    event.request.session[3].challengeName === "CUSTOM_CHALLENGE" &&
    event.request.session[3].challengeResult === true
  ) {
    event.response.issueTokens = true;
    event.response.failAuthentication = false;
  } else {
    event.response.issueTokens = false;
    event.response.failAuthentication = true;
  }

  return event;
};

export { handler };
```

------

# 認証チャレンジの作成の Lambda トリガー
<a name="user-pool-lambda-create-auth-challenge"></a>

認証チャレンジの作成のトリガーは、認証チャレンジの定義トリガーによって宣言された各チャレンジの詳細を持つ Lambda 関数です。これは、認証チャレンジの定義トリガーによって宣言されたチャレンジ名を処理し、アプリケーションがユーザーに提示する必要がある `publicChallengeParameters` を返します。次に、この関数は、ユーザープールが認証チャレンジ検証トリガーに渡すチャレンジに対する回答、 `privateChallengeParameters` をユーザープールに提供します。認証チャレンジの定義トリガーがチャレンジシーケンスを管理する場合、認証チャレンジの作成トリガーはチャレンジの内容を管理します。

![\[チャレンジの Lambda トリガー\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/lambda-challenges2.png)


**認証チャレンジの作成**  
**認証チャレンジの定義**トリガーの一部としてカスタムチャレンジが指定されている場合、Amazon Cognito は**認証チャレンジの定義**後にこのトリガーを呼び出します。これにより、[カスタム認証フロー](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html#amazon-cognito-user-pools-custom-authentication-flow)を作成します。

この Lambda トリガーは、ユーザーに提示するチャレンジを作成するために呼び出されます。この Lambda トリガーのリクエストには `challengeName` と `session` が含まれます。`challengeName` は文字列であり、ユーザーに対する次のチャレンジの名前です。この属性の値は、認証チャレンジの定義の Lambda トリガーに設定されています。

チャレンジループは、すべてのチャレンジに応答するまで繰り返されます。

**Topics**
+ [認証チャレンジの作成 Lambda トリガーパラメータ](#cognito-user-pools-lambda-trigger-syntax-create-auth-challenge)
+ [認証チャレンジの作成の例](#aws-lambda-triggers-create-auth-challenge-example)

## 認証チャレンジの作成 Lambda トリガーパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-create-auth-challenge"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
        "userAttributes": {
            "string": "string",
            . . .
        },
        "challengeName": "string",
        "session": [
            ChallengeResult,
            . . .
        ],
        "clientMetadata": {
            "string": "string",
            . . .
        },
        "userNotFound": boolean
    },
    "response": {
        "publicChallengeParameters": {
            "string": "string",
            . . .
        },
        "privateChallengeParameters": {
            "string": "string",
            . . .
        },
        "challengeMetadata": "string"
    }
}
```

------

### 認証チャレンジの作成のリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-create-auth-challenge-request"></a>

**userAttributes**  
ユーザー属性を表す 1 つ以上の名前 - 値ペア。

**userNotFound**  
このブール値は、ユーザープールクライアントで `PreventUserExistenceErrors` が `ENABLED` に設定されている場合に設定されます。

**challengeName**  
新しいチャレンジの名前。

**session**  
session 要素は `ChallengeResult` 要素の配列であり、それぞれに以下の要素が含まれます。    
**challengeName**  
チャレンジタイプ。`"CUSTOM_CHALLENGE"`、`"PASSWORD_VERIFIER"`、`"SMS_MFA"`、`"DEVICE_SRP_AUTH"`、`"DEVICE_PASSWORD_VERIFIER"`、`"NEW_PASSWORD_REQUIRED"`、または `"ADMIN_NO_SRP_AUTH"` のいずれか。  
**challengeResult**  
ユーザーが正常にチャレンジを完了した場合は `true` に、それ以外の場合は `false` に設定します。  
**challengeMetadata**  
カスタムチャレンジの名前を入力します。`challengeName` が `"CUSTOM_CHALLENGE"` である場合にのみ使用されます。

**clientMetadata**  
認証チャレンジの作成のトリガーに指定する Lambda 関数へのカスタム入力として提供できる 1 つ、または複数のキー/値ペア。このデータは、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) および [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) API アクションで ClientMetadata パラメータを使用することによって Lambda 関数に渡すことができます。create auth challenge 関数を呼び出すリクエストに、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) および [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションで ClientMetadata パラメータに渡されたデータは含まれません。

### 認証チャレンジの作成のレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-create-auth-challenge-response"></a>

**publicChallengeParameters**  
クライアントアプリケーションでユーザーに提示されるチャレンジに使用する 1 つ以上のキー - 値ペア。このパラメータには、ユーザーにチャレンジを正確に提示するために必要なすべての情報を含める必要があります。

**privateChallengeParameters**  
このパラメータは、認証チャレンジレスポンスの検証の Lambda トリガー以外では使用されません。このパラメータには、チャレンジに対するユーザーのレスポンスを検証するために必要な情報のすべてを含める必要があります。つまり、`publicChallengeParameters` には、ユーザーに示される質問が含まれ、`privateChallengeParameters` には、質問に対する有効な回答が含まれます。

**challengeMetadata**  
カスタムチャレンジの名前 (カスタムチャレンジの場合)。

## 認証チャレンジの作成の例
<a name="aws-lambda-triggers-create-auth-challenge-example"></a>

この関数には、[認証チャレンジの定義例](user-pool-lambda-define-auth-challenge.md#aws-lambda-triggers-define-auth-challenge-example)のチャレンジシーケンスに対応する 2 つのカスタムチャレンジがあります。最初の 2 つのチャレンジは SRP 認証です。3 番目のチャレンジの場合、この関数はチャレンジレスポンスで CAPTCHA URL をアプリケーションに返します。アプリケーションは、指定された URL で CAPTCHA をレンダリングし、ユーザーの入力を返します。CAPTCHA イメージの URL が "`captchaUrl`" としてパブリックチャレンジパラメータに追加され、想定される回答がプライベートチャレンジパラメータに追加されます。

4 番目のチャレンジの場合、この関数はセキュリティの質問を返します。アプリケーションは質問をレンダリングし、ユーザーに回答を求めます。ユーザーが両方のカスタムチャレンジを解決すると、認証チャレンジの定義トリガーは、ユーザープールがトークンを発行できることを確認します。

------
#### [ Node.js ]

```
const handler = async (event) => {
  if (event.request.challengeName !== "CUSTOM_CHALLENGE") {
    return event;
  }

  if (event.request.session.length === 2) {
    event.response.publicChallengeParameters = {};
    event.response.privateChallengeParameters = {};
    event.response.publicChallengeParameters.captchaUrl = "url/123.jpg";
    event.response.privateChallengeParameters.answer = "5";
  }

  if (event.request.session.length === 3) {
    event.response.publicChallengeParameters = {};
    event.response.privateChallengeParameters = {};
    event.response.publicChallengeParameters.securityQuestion =
      "Who is your favorite team mascot?";
    event.response.privateChallengeParameters.answer = "Peccy";
  }

  return event;
};

export { handler };
```

------

# 認証チャレンジレスポンスの検証の Lambda トリガー
<a name="user-pool-lambda-verify-auth-challenge-response"></a>

認証チャレンジの検証トリガーは、ユーザーが提供したレスポンスを既知のレスポンスと比較する Lambda 関数です。この関数は、ユーザーがチャレンジに正しく応答したかどうかをユーザープールに伝えます。認証チャレンジの検証トリガーが `true` の `answerCorrect` で応答すると、認証シーケンスは続行できます。

![\[チャレンジの Lambda トリガー\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/lambda-challenges3.png)


**認証チャレンジレスポンスの検証**  
Amazon Cognito は、このトリガーが呼び出して、カスタム認証チャレンジに対するユーザーからのレスポンスが有効であるかどうかを検証します。これはユーザープールの[カスタム認証フロー](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html#amazon-cognito-user-pools-custom-authentication-flow)の一環です。

このトリガーのリクエストには `privateChallengeParameters` および `challengeAnswer` パラメータが含まれます。`privateChallengeParameters` 値は、認証チャレンジの作成の Lambda トリガーによって返され、ユーザーからの期待されるレスポンスが含まれます。`challengeAnswer` パラメータには、チャレンジに対するユーザーのレスポンスが含まれます。

レスポンスには、`answerCorrect` 属性が含まれます。ユーザーがチャレンジを正常に完了すると、Amazon Cognito は属性値を `true` に設定します。ユーザーがチャレンジを正常に完了しなかった場合、Amazon Cognito は値を `false` に設定します。

チャレンジループは、すべてのチャレンジが回答されるまで繰り返します。

**Topics**
+ [認証チャレンジの検証の Lambda トリガーのパラメータ](#cognito-user-pools-lambda-trigger-syntax-verify-auth-challenge)
+ [認証チャレンジレスポンスの確認の例](#aws-lambda-triggers-verify-auth-challenge-response-example)

## 認証チャレンジの検証の Lambda トリガーのパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-verify-auth-challenge"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
        "userAttributes": {
            "string": "string",
            . . .
        },
        "privateChallengeParameters": {
            "string": "string",
            . . .
        },
        "challengeAnswer": "string",
        "clientMetadata": {
            "string": "string",
            . . .
        },
        "userNotFound": boolean
    },
    "response": {
        "answerCorrect": boolean
    }
}
```

------

### 認証チャレンジの検証のリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-verify-auth-challenge-request"></a>

**userAttributes**  
このパラメータには、ユーザー属性を表す 1 つ以上の名前-値ペアが含まれます。

**userNotFound**  
Amazon Cognito がユーザープールクライアントの `PreventUserExistenceErrors` を `ENABLED` に設定すると、Amazon Cognito はこのブール値を入力します。

**privateChallengeParameters**  
このパラメータは、認証チャレンジの作成トリガーから取得されます。ユーザーがチャレンジに合格したかどうかを判断するために、Amazon Cognito はパラメータをユーザーの **challengeAnswer** パラメータと比較します。  
このパラメータには、チャレンジに対するユーザーのレスポンスを検証するために必要な情報のすべてが含まれます。その情報には、Amazon Cognito がユーザーに提示する質問 (`publicChallengeParameters`) と、その質問に対する有効な回答 (`privateChallengeParameters`) が含まれます。認証チャレンジレスポンスの検証の Lambda トリガーのみがこのパラメータを使用します。

**challengeAnswer**  
このパラメータ値は、チャレンジに対するユーザーの回答です。

**clientMetadata**  
このパラメータには、認証チャレンジの検証のトリガーの Lambda 関数へのカスタム入力として提供できる 1 つまたは複数のキーバリューペアが含まれています。このデータを Lambda 関数に渡すには、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) および [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) API オペレーションで ClientMetadata パラメータを使用します。Amazon Cognito は、認証チャレンジの検証関数に渡すリクエストの [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) および [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションの ClientMetadata パラメータからのデータを含めません。

### 認証チャレンジの検証のレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-verify-auth-challenge-response"></a>

**answerCorrect**  
ユーザーがチャレンジを正常に完了した場合、Amazon Cognito はこのパラメータを `true` に設定します。ユーザーがチャレンジを正常に完了しなかった場合、Amazon Cognito はパラメータを `false` に設定します。

## 認証チャレンジレスポンスの確認の例
<a name="aws-lambda-triggers-verify-auth-challenge-response-example"></a>

この認証チャレンジの確認関数は、チャレンジに対するユーザーのレスポンスが、想定されたレスポンスと一致するかどうかを確認します。ユーザーの回答はアプリケーションからの入力によって定義され、推奨される回答は [認証チャレンジの作成トリガーレスポンス](user-pool-lambda-create-auth-challenge.md#aws-lambda-triggers-create-auth-challenge-example)からのレスポンスの `privateChallengeParameters.answer` によって定義されます。正しい回答と与えられた回答は、どちらもこの関数への入力イベントの一部となります。

この例では、ユーザーのレスポンスが想定されたレスポンスと一致した場合、Amazon Cognito は `answerCorrect` パラメータを `true` に設定します。

------
#### [ Node.js ]

```
const handler = async (event) => {
  if (
    event.request.privateChallengeParameters.answer ===
    event.request.challengeAnswer
  ) {
    event.response.answerCorrect = true;
  } else {
    event.response.answerCorrect = false;
  }

  return event;
};

export { handler };
```

------

# トークン生成前の Lambda トリガー
<a name="user-pool-lambda-pre-token-generation"></a>

Amazon Cognito は、このトリガーをトークンの生成前に呼び出すため、ユーザープールトークンのクレームをカスタマイズできます。バージョン 1 または `V1_0` のトークン生成前トリガーイベントの**基本機能**を使用して、アイデンティティ (ID) トークンをカスタマイズできます。エッセンシャル機能プランまたはプラス機能プランを使用するユーザープールでは、Machine to Machine (M2M) クライアント認証情報の付与で、アクセストークンのカスタマイズを伴うバージョン 2 (`V2_0`) トリガーイベントと、アクセストークンのカスタマイズを伴うバージョン 3 (`V3_0`) トリガーイベントを生成できます。

Amazon Cognito は、ID トークンに書き込むデータが含まれているリクエストとして `V1_0` イベントを関数に送信します。`V2_0` イベントまたは `V3_0` イベントは、Amazon Cognito が ID トークンとアクセストークンの両方に書き込むデータが含まれている単一のリクエストです。両方のトークンをカスタマイズするには、トリガーバージョン 2 または 3 を使用するように関数を更新し、両方のトークンのデータを同じレスポンスで送信する必要があります。

Amazon Cognito は、バージョン 2 のイベントレスポンスを、ユーザー認証 (ユーザー自らユーザープールに提示した認証情報) からのアクセストークンに適用します。バージョン 3 のイベントレスポンスは、ユーザー認証とマシン認証からのアクセストークンに適用されます。マシン認証では、自動化されたシステムが、アプリケーションクライアントシークレットを使用してアクセストークンリクエストを承認します。結果のアクセストークンの状況を除いて、バージョン 2 と 3 のイベントは同じです。

この Lambda トリガーでは、Amazon Cognito がアプリケーションに発行する前の ID トークンとアクセストークンの一部のクレームを追加、削除、変更できます。この機能を使用するには、Amazon Cognito ユーザープールコンソールから Lambda 関数を関連付けるか、 AWS Command Line Interface (AWS CLI) でユーザープール `LambdaConfig` を更新します。

## イベントバージョン
<a name="user-pool-lambda-pre-token-generation-event-versions"></a>

ユーザープールは、トークン生成前トリガーイベントのさまざまなバージョンを Lambda 関数に配信できます。`V1_0` トリガーは、ID トークンを変更するためのパラメータを配信します。`V2_0` または `V3_0` トリガーは、以下のパラメータを提供します。

1. `V1_0` トリガーの関数。

1. アクセストークンをカスタマイズする機能。

1. 複雑なデータ型を ID に渡し、次のトークンクレーム値にアクセスする機能。
   + String
   + Number
   + ブール値
   + 文字列、数値、ブール値、またはこれらの組み合わせの配列
   + JSON

**注記**  
ID トークンでは、`phone_number_verified`、`email_verified`、`updated_at` および `address` を除くクレームの値に複雑なオブジェクトを入力できます。

ユーザープールはデフォルトで `V1_0` イベントを配信します。`V2_0` イベントを送信するようにユーザープールを設定するには、Amazon Cognito コンソールでトリガーを設定するときに、**[トリガーイベントバージョン]** として **[基本機能 \$1 ユーザー ID のアクセストークンのカスタマイズ]** を選択します。`V3_0` イベントを生成するには、****[基本機能 \$1 ユーザー ID とマシン ID のアクセストークンのカスタマイズ]**** を選択します。[UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストまたは [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API リクエストの [LambdaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html#CognitoUserPools-UpdateUserPool-request-LambdaConfig) パラメータで `LambdaVersion` の値を設定することもできます。イベントバージョン 1、2、3 は、**エッセンシャル**機能プランと**プラス**機能プランで利用できます。バージョン 3 イベントの M2M オペレーションには、月間アクティブユーザー (MAU) の計算式とは別の料金体系があります。詳細については、「[Amazon Cognito の料金](https://aws.amazon.com/cognito/pricing/)」を参照してください。

**注記**  
ユーザープールが 2024 年 11 月 22 日 18:00 GMT 以前に **[高度なセキュリティ機能]** オプションを使用して動作し、**ライト**機能階層に残っている場合は、トークン生成前トリガーのイベントバージョン 1 と 2 にアクセスできます。このレガシー階層のユーザープールで高度なセキュリティ機能を有効にして*いない*場合は、イベントバージョン 1 にアクセスできます。バージョン 3 は、エッセンシャルとプラスで*のみ*利用できます。

## クレームとスコープのリファレンス
<a name="user-pool-lambda-pre-token-generation-excluded-claims"></a>

Amazon Cognito は、アクセストークンと ID トークンに対して追加、変更、または抑制できるクレームとスコープを制限します。次の表は、Lambda 関数で変更できるクレームと変更できないクレーム、およびクレームの存在や値に影響するトリガーイベントパラメータを示しています。


| Claim | デフォルトのトークンタイプ | 追加可能? | 変更可能? | 抑制可能? | イベントパラメータ - 追加または変更 | イベントパラメータ - 抑制 | ID のタイプ | イベントバージョン | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| ユーザープールのトークンスキーマにないクレーム | なし | はい | はい | 該当なし | claimsToAddOrOverride | claimsToSuppress | ユーザー、マシン[1](#cognito-pretoken-machine-ids-tier-note) | すべて[2](#cognito-pretoken-id-access-versions-note) | 
| scope | アクセス | はい  | はい | はい | scopesToAdd | scopesToSuppress | ユーザー、マシン[1](#cognito-pretoken-machine-ids-tier-note) | v2\$10, v3\$10 | 
| cognito:groups | ID、アクセス | はい  | はい | はい | groupsToOverride | claimsToSuppress | ユーザー | すべて[2](#cognito-pretoken-id-access-versions-note) | 
| cognito:preferred\$1role | ID | はい  | はい | はい | preferredRole | claimsToSuppress[3](#cognito-pretoken-suppress-groups-note) | ユーザー | すべて | 
| cognito:roles | ID | はい  | はい | はい | iamRolesToOverride | claimsToSuppress[3](#cognito-pretoken-suppress-groups-note) | ユーザー | すべて | 
| cognito:username | ID | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー | 該当なし | 
| cognito: プレフィックスが付いたその他のクレーム | なし | いいえ | なし | いいえ | 該当なし | 該当なし | 該当なし | 該当なし | 
| username | アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー | v2\$10, v3\$10 | 
| sub | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー | 該当なし | 
| 標準 OIDC 属性 | ID | はい  | はい | はい | claimsToAddOrOverride | claimsToSuppress | ユーザー | すべて | 
| custom: 属性 | ID | はい  | はい | はい | claimsToAddOrOverride | claimsToSuppress | ユーザー | すべて | 
| dev: 属性 | ID | いいえ | なし | はい | 該当なし | claimsToSuppress | ユーザー | すべて | 
| identities | ID | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー | 該当なし | 
| aud[4](#cognito-pretoken-aud-note) | ID | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| client\$1id | アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| event\$1id | アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| device\$1key | アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー | 該当なし | 
| version | アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| acr | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| amr | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| at\$1hash | ID | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| auth\$1time | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| azp | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| exp | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| iat | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| iss | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| jti | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| nbf | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| nonce | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| origin\$1jti | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 
| token\$1use | ID、アクセス | いいえ | なし | いいえ | 該当なし | 該当なし | ユーザー、マシン | 該当なし | 

 1 マシン ID のアクセストークンは、トリガー入力イベントの `v3_0` でのみ使用できます。イベントバージョン 3 は、**エッセンシャル**機能階層と**プラス**機能階層でのみ使用できます。**ライト**階層のユーザープールは `v1_0` イベントを受信できます。高度なセキュリティ機能を備えた、**ライト**階層のユーザープールは、`v1_0` イベントと `v2_0` イベントを受信できます。

2 トークン生成前トリガーを、`v1_0` イベントバージョン (ID トークンのみ)、`v2_0` イベントバージョン (ID トークンとアクセストークン)、`v3_0` イベントバージョン ( ID トークンとアクセストークン、さらにマシン ID の機能) に設定します。

 3 `cognito:preferred_role` クレームと `cognito:roles` クレームを抑制するには、`cognito:groups` を `claimsToSuppress` に追加します。

 4 `aud` クレームをアクセストークンに追加することはできますが、その値は現在のセッションのアプリケーションクライアント ID と一致する必要があります。リクエストイベントのクライアント ID は、`event.callerContext.clientId` から取得できます。

## ID トークンのカスタマイズ
<a name="user-pool-lambda-pre-token-generation-idtoken"></a>

トークン生成前 Lambda トリガーのすべてのイベントバージョンでは、ユーザープールのアイデンティティ (ID) トークンの内容をカスタマイズできます。ID トークンは、ウェブまたはモバイルアプリにサインインするためのユーザー属性を、信頼できる ID ソースから提供します。ID トークンの詳細については、「[ID トークンの理解](amazon-cognito-user-pools-using-the-id-token.md)」を参照してください。

トークン生成前の Lambda トリガーでは、ID トークンを使用して以下のような操作を行います。
+ ユーザーがアイデンティティプールにリクエストした IAM ロールをランタイムに変更します。
+ 外部ソースからユーザー属性を追加します。
+ 既存のユーザー属性値を追加または置換します。
+ アプリに渡されるはずのユーザー属性が、ユーザーの許可されたスコープや、アプリクライアントに付与した属性の読み取りアクセス権により開示されることを抑制します。

## アクセストークンのカスタマイズ
<a name="user-pool-lambda-pre-token-generation-accesstoken"></a>

トークン生成前 Lambda トリガーのイベントバージョン 2 および 3 を使用すると、ユーザープールのアクセストークンの内容をカスタマイズできます。アクセストークンは、Amazon Cognito トークン認可 API オペレーションやサードパーティ API などのアクセス保護されたリソースから情報を取得することをユーザーに許可します。クライアント認証情報の付与による Machine to Machine (M2M) 認証の場合、Amazon Cognito は、ユーザープールがバージョン 3 (`V3_0`) イベント用に設定されている場合にのみ、トークン生成前トリガーを呼び出します。アクセストークンの詳細については、「[アクセストークンの理解](amazon-cognito-user-pools-using-the-access-token.md)」を参照してください。

トークン生成前の Lambda トリガーでは、アクセストークンを使用して以下のような操作を行います。
+ `scope` クレーム内のスコープを追加または抑制します。例えば、スコープ `aws.cognito.signin.user.admin` のみを割り当てる Amazon Cognito ユーザープール API 認証で生成されたアクセストークンにスコープを追加できます。
+ ユーザープールグループのユーザーのメンバーシップを変更します。
+ Amazon Cognito アクセストークンにまだ存在していないクレームを追加します。
+ アプリに渡されるはずのクレームの開示を抑制します。

ユーザープールでのアクセスのカスタマイズをサポートするには、トリガーリクエストの更新バージョンを生成するようにユーザープールを設定する必要があります。ユーザープールを更新するには、次の手順に従います。

------
#### [ AWS マネジメントコンソール ]

**トークン生成前の Lambda トリガーでアクセストークンのカスタマイズをサポートするには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動し、**[ユーザープール]** を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[拡張機能]** メニューを選択し、**[Lambda トリガー]** を見つけます。

1. **トークン生成前トリガー**を追加または編集します。

1. **[Lambda 関数を割り当てる]** で Lambda 関数を選択します。

1. **[トリガーイベントバージョン]** として、**[基本機能 \$1 ユーザー ID のアクセストークンのカスタマイズ]** または **[機能機能 \$1 ユーザー ID とマシン ID のアクセストークンのカスタマイズ]** を選択します。この設定により、Amazon Cognito が関数に送信するリクエストパラメータが更新され、アクセストークンをカスタマイズするためのフィールドが含まれるようになります。

------
#### [ User pools API ]

**トークン生成前の Lambda トリガーでアクセストークンのカスタマイズをサポートするには**

[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) または [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストを生成します。デフォルト値に設定しないすべてのパラメータには、値を指定する必要があります。詳細については、「[ユーザープールとアプリケーションクライアントの設定更新](cognito-user-pool-updating.md)」を参照してください。

リクエストの `LambdaVersion` パラメータに以下の内容を含めます。`LambdaVersion` の値が `V2_0` である場合、ユーザープールはアクセストークンのパラメータを追加し、アクセストークンに変更を適用します。`LambdaVersion` の値が `V3_0` である場合、`V2_0` と同じイベントが生成されますが、ユーザープールは M2M アクセストークンに*対しても*変更を適用します。特定の関数バージョンを呼び出すには、関数バージョンを `LambdaArn` の値とする Lambda 関数 ARN を使用します。

```
"PreTokenGenerationConfig": { 
   "LambdaArn": "arn:aws:lambda:us-west-2:123456789012:function:MyFunction",
   "LambdaVersion": "V3_0"
},
```

------

**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) の結果に役立つユーザーまたはアプリケーション環境からの追加情報です。ユーザープリンシパルによる認証オペレーションでは、[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
```

**その他のリソース**
+ [Amazon Cognito ユーザープールでアクセストークンをカスタマイズする方法](https://aws.amazon.com/blogs/security/how-to-customize-access-tokens-in-amazon-cognito-user-pools/)

**Topics**
+ [イベントバージョン](#user-pool-lambda-pre-token-generation-event-versions)
+ [クレームとスコープのリファレンス](#user-pool-lambda-pre-token-generation-excluded-claims)
+ [ID トークンのカスタマイズ](#user-pool-lambda-pre-token-generation-idtoken)
+ [アクセストークンのカスタマイズ](#user-pool-lambda-pre-token-generation-accesstoken)
+ [トークン生成前の Lambda トリガーのソース](#user-pool-lambda-pre-token-generation-trigger-source)
+ [トークン生成前の Lambda トリガーのパラメータ](#cognito-user-pools-lambda-trigger-syntax-pre-token-generation)
+ [トークン生成前トリガーイベントバージョン 2 の例:クレーム、スコープ、グループの追加と非表示](#aws-lambda-triggers-pre-token-generation-example-version-2-overview)
+ [トークン生成前イベントバージョン 2 の例: 複雑なオブジェクトでクレームを追加する](#aws-lambda-triggers-pre-token-generation-example-version-2-complex-objects)
+ [トークン生成前イベントバージョン 1 の例: 新しいクレームの追加と既存のクレームの非表示](#aws-lambda-triggers-pre-token-generation-version-1-add-claim)
+ [トークン生成前イベントバージョン 1 の例: ユーザーグループのメンバーシップの変更](#aws-lambda-triggers-pre-token-generation-version-1-change-group)

## トークン生成前の Lambda トリガーのソース
<a name="user-pool-lambda-pre-token-generation-trigger-source"></a>


| triggerSource 値 | イベント | 
| --- | --- | 
| TokenGeneration\$1HostedAuth | Amazon Cognito マネージドログインのサインインページからの認証時に呼び出されます。 | 
| TokenGeneration\$1Authentication | ユーザー認証フローが完了した後に呼び出されます。 | 
| TokenGeneration\$1NewPasswordChallenge | 管理者によってユーザーが作成された後に呼び出されます。このフローは、ユーザーが一時パスワードを変更する必要があるときに呼び出されます。 | 
| TokenGeneration\$1ClientCredentials | M2M クライアント認証情報の付与の後に呼び出されます。ユーザープールがこのイベントを送信するのは、イベントバージョンが V3\$10 の場合のみです。 | 
| TokenGeneration\$1AuthenticateDevice | ユーザーデバイスの認証の終了時に呼び出されます。 | 
| TokenGeneration\$1RefreshTokens | ユーザーが ID およびアクセスのトークンを更新しようとしたときに呼び出されます。 | 

## トークン生成前の Lambda トリガーのパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-pre-token-generation"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。トークン生成前の Lambda トリガーをユーザープールに追加するときに、トリガーバージョンを選択できます。このバージョンにより、Amazon Cognito がアクセストークンをカスタマイズするための追加パラメータを含むリクエストを Lambda 関数に渡すかどうかが決まります。

------
#### [ Version one ]

バージョン 1 のトークンは、ID トークン内のグループメンバーシップ、IAM ロール、新しいクレームを設定できます。グループメンバーシップのオーバーライドは、アクセストークンの `cognito:groups` クレームにも適用されます。

```
{
    "request": {
        "userAttributes": {"string": "string"},
        "groupConfiguration": {
                "groupsToOverride": [
                    "string",
                    "string"
                ],
                "iamRolesToOverride": [
                    "string",
                    "string"
                ],
                "preferredRole": "string"
        },
        "clientMetadata": {"string": "string"}
    },
    "response": {
        "claimsOverrideDetails": {
            "claimsToAddOrOverride": {"string": "string"},
            "claimsToSuppress": [
                "string",
                "string"
            ],
            "groupOverrideDetails": {
                "groupsToOverride": [
                    "string",
                    "string"
                ],
                "iamRolesToOverride": [
                    "string",
                    "string"
                ],
                "preferredRole": "string"
            }
        }
    }
}
```

------
#### [ Versions two and three ]

バージョン 2 および 3 のリクエストイベントは、アクセストークンをカスタマイズするフィールドを追加します。ユーザープールは、バージョン 3 のイベントの変更をマシン ID のアクセストークンに適用します。また、これらのバージョンは、レスポンスオブジェクトの複雑な `claimsToOverride` データ型のサポートも追加します。Lambda 関数は、次のタイプのデータを `claimsToOverride` の値で返すことができます。
+ String
+ Number
+ ブール値
+ 文字列、数値、ブール値、またはこれらの組み合わせの配列
+ JSON

```
{
    "request": {
        "userAttributes": {
            "string": "string"
        },
        "scopes": ["string", "string"],
        "groupConfiguration": {
            "groupsToOverride": ["string", "string"],
            "iamRolesToOverride": ["string", "string"],
            "preferredRole": "string"
        },
        "clientMetadata": {
            "string": "string"
        }
    },
    "response": {
        "claimsAndScopeOverrideDetails": {
            "idTokenGeneration": {
                "claimsToAddOrOverride": {
                    "string": [accepted datatype]
                },
                "claimsToSuppress": ["string", "string"]
            },
            "accessTokenGeneration": {
                "claimsToAddOrOverride": {
                    "string": [accepted datatype]
                },
                "claimsToSuppress": ["string", "string"],
                "scopesToAdd": ["string", "string"],
                "scopesToSuppress": ["string", "string"]
            },
            "groupOverrideDetails": {
                "groupsToOverride": ["string", "string"],
                "iamRolesToOverride": ["string", "string"],
                "preferredRole": "string"
            }
        }
    }
}
```

------

### トークン生成前のリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-pre-token-generation-request"></a>


| 名前 | 説明 | トリガーイベントの最小バージョン | 
| --- |--- |--- |
| userAttributes |  ユーザープール内のユーザープロファイルの属性。  | 1 | 
| groupConfiguration |  現在のグループ設定を含む入力オブジェクト。このオブジェクトには、`groupsToOverride`、`iamRolesToOverride`、および `preferredRole` が含まれています。  | 1 | 
| groupsToOverride |  ユーザーがメンバーになっている[ユーザープールグループ](cognito-user-pools-user-groups.md#cognito-user-pools-user-groups.title)。  | 1 | 
| iamRolesToOverride |  ユーザープールグループを AWS Identity and Access Management (IAM) ロールに関連付けることができます。この要素は、ユーザーがメンバーになっているグループのすべての IAM ロールのリストです。  | 1 | 
| preferredRole |  ユーザープールグループには、[優先順位](cognito-user-pools-user-groups.md#assigning-precedence-values-to-groups.title)を設定できます。この要素には、`groupsToOverride` 要素内で優先順位が最も高いグループの IAM ロールの名前が含まれます。  | 1 | 
| clientMetadata |  トークン生成前のトリガーに指定する Lambda 関数へのカスタム入力として提供できる 1 つ、または複数のキー/値ペア。 このデータを Lambda 関数に渡すには、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) および [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) API オペレーションで ClientMetadata パラメータを使用します。Amazon Cognito は、トークン生成前の関数に渡すリクエストの [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) および [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションに `ClientMetadata` パラメータのデータを含めません。  | 1 | 
| scopes |  アクセストークンのスコープ。アクセストークンに含まれるスコープは、ユーザーがリクエストし、アプリクライアントに発行を許可したユーザープールの標準スコープとカスタムスコープです。  | 2 | 

### トークン生成前のレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-pre-token-generation-response"></a>


| 名前 | 説明 | トリガーイベントの最小バージョン | 
| --- |--- |--- |
| claimsOverrideDetails | A container for all elements in a V1\$10 trigger event. | 1 | 
| claimsAndScopeOverrideDetails |  `V2_0` または `V3_0` トリガーイベント内のすべての要素を格納するコンテナ。  | 2 | 
| idTokenGeneration |  ユーザーの ID トークンで上書き、追加、または抑制するクレーム。この ID トークンのカスタマイズ値の親は、バージョン 2 以降でのみ表示されますが、子要素はバージョン 1 のイベントでも表示されます。  | 2 | 
| accessTokenGeneration |  ユーザーのアクセストークンで上書き、追加、または抑制するクレームとスコープ。このアクセストークンのカスタマイズ値の親は、バージョン 2 以降のイベントでのみ表示されます。  | 2 | 
| claimsToAddOrOverride |  追加または変更する 1 つ以上のクレームとその値のマップ。グループ関連のクレームには、代わりに `groupOverrideDetails` を使用します。 イベントバージョン 2 以降の場合、この要素は `accessTokenGeneration` と `idTokenGeneration` の両方の下に表示されます。  | 1[*](#cognito-pretoken-complex-objects-note) | 
| claimsToSuppress |  Amazon Cognito で抑制するクレームのリスト。関数がクレーム値の非表示と置換の両方を行う場合、Amazon Cognito はクレームを非表示にします。 イベントバージョン 2 以降の場合、この要素は `accessTokenGeneration` と `idTokenGeneration` の両方の下に表示されます。  | 1 | 
| groupOverrideDetails |  現在のグループ設定を含む出力オブジェクト。このオブジェクトには、`groupsToOverride`、`iamRolesToOverride`、および `preferredRole` が含まれています。 この関数は、`groupOverrideDetails` オブジェクトを、指定したオブジェクトに置き換えます。レスポンスで空または Null オブジェクトを返すと、Amazon Cognito はグループを非表示にします。既存のグループ設定を同じままにするには、リクエストの `groupConfiguration` オブジェクトの値をレスポンスの `groupOverrideDetails` オブジェクトにコピーします。その後、サービスに渡します。 Amazon Cognito ID とアクセストークンには、両方とも `cognito:groups` クレームが含まれています。`groupOverrideDetails` オブジェクトは、アクセストークンおよび ID トークンの `cognito:groups` クレームを置き換えます。バージョン 1 のイベントがアクセストークンを変更できるのは、グループのオーバーライドのみです。  | 1 | 
| scopesToAdd |  ユーザーのアクセストークンの `scope` クレームに追加するスコープのリスト。1 つ以上の空白文字を含むスコープ値を追加することはできません。  | 2 | 
| scopesToSuppress |  ユーザーのアクセストークンの `scope` クレームから削除するスコープのリスト。  | 2 | 

 \$1 バージョン 1 のイベントへのレスポンスオブジェクトは、文字列を返すことができます。バージョン 2 および 3 のイベントへのレスポンスオブジェクトは、[複雑なオブジェクト](#user-pool-lambda-pre-token-generation-event-versions)を返すことができます。

## トークン生成前トリガーイベントバージョン 2 の例:クレーム、スコープ、グループの追加と非表示
<a name="aws-lambda-triggers-pre-token-generation-example-version-2-overview"></a>

この例では、ユーザーのトークンに以下の変更を行います。

1. ID トークンに `family_name` として `Doe` を設定します。

1. ID トークンに `email` クレームと `phone_number` クレームが表示されないようにします。

1. ID トークンの `cognito:roles` クレームを `"arn:aws:iam::123456789012:role\/sns_callerA","arn:aws:iam::123456789012:role\/sns_callerC","arn:aws:iam::123456789012:role\/sns_callerB"` に設定します。

1. ID トークンの `cognito:preferred_role` クレームを `arn:aws:iam::123456789012:role/sns_caller` に設定します。

1. スコープとして `openid`、`email`、`solar-system-data/asteroids.add` をアクセストークンに追加します。

1. アクセストークンの `phone_number` スコープと `aws.cognito.signin.user.admin` スコープを非表示にします。`phone_number` を削除すると、`userInfo` からユーザーの電話番号が取得されなくなります。`aws.cognito.signin.user.admin` を削除すると、ユーザーが Amazon Cognito ユーザープール API を使用して自分のプロファイルを読み取ったり変更したりするための API リクエストが禁止されます。
**注記**  
`phone_number` をスコープから削除した場合、アクセストークンの残りのスコープに `openid` と少なくとも 1 つの標準スコープが含まれていれば、ユーザーの電話番号のみが取得できなくなります。詳細については、「[スコープについて](cognito-user-pools-define-resource-servers.md#cognito-user-pools-define-resource-servers-about-scopes)」を参照してください。

1. ID トークンとアクセストークンの `cognito:groups` クレームを `"new-group-A","new-group-B","new-group-C"` に設定します。

------
#### [ JavaScript ]

```
export const handler = function(event, context) {
  event.response = {
    "claimsAndScopeOverrideDetails": {
      "idTokenGeneration": {
        "claimsToAddOrOverride": {
          "family_name": "Doe"
        },
        "claimsToSuppress": [
          "email",
          "phone_number"
        ]
      },
      "accessTokenGeneration": {
        "scopesToAdd": [
          "openid",
          "email",
          "solar-system-data/asteroids.add"
        ],
        "scopesToSuppress": [
          "phone_number",
          "aws.cognito.signin.user.admin"
        ]
      },
      "groupOverrideDetails": {
        "groupsToOverride": [
          "new-group-A",
          "new-group-B",
          "new-group-C"
        ],
        "iamRolesToOverride": [
          "arn:aws:iam::123456789012:role/new_roleA",
          "arn:aws:iam::123456789012:role/new_roleB",
          "arn:aws:iam::123456789012:role/new_roleC"
        ],
        "preferredRole": "arn:aws:iam::123456789012:role/new_role",
      }
    }
  };
  // Return to Amazon Cognito
  context.done(null, event);
};
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
    "version": "2",
    "triggerSource": "TokenGeneration_Authentication",
    "region": "us-east-1",
    "userPoolId": "us-east-1_EXAMPLE",
    "userName": "JaneDoe",
    "callerContext": {
        "awsSdkVersion": "aws-sdk-unknown-unknown",
        "clientId": "1example23456789"
    },
    "request": {
        "userAttributes": {
            "sub": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
            "cognito:user_status": "CONFIRMED",
            "email_verified": "true",
            "phone_number_verified": "true",
            "phone_number": "+12065551212",
            "family_name": "Zoe",
            "email": "Jane.Doe@example.com"
        },
        "groupConfiguration": {
            "groupsToOverride": ["group-1", "group-2", "group-3"],
            "iamRolesToOverride": ["arn:aws:iam::123456789012:role/sns_caller1", "arn:aws:iam::123456789012:role/sns_caller2", "arn:aws:iam::123456789012:role/sns_caller3"],
            "preferredRole": ["arn:aws:iam::123456789012:role/sns_caller"]
        },
        "scopes": [
            "aws.cognito.signin.user.admin", "openid", "email", "phone"
        ]
    },
    "response": {
        "claimsAndScopeOverrideDetails": []
    }
}
```

------

## トークン生成前イベントバージョン 2 の例: 複雑なオブジェクトでクレームを追加する
<a name="aws-lambda-triggers-pre-token-generation-example-version-2-complex-objects"></a>

この例では、ユーザーのトークンに以下の変更を行います。

1. ID トークンに数値、文字列、ブール値、JSON タイプのクレームを追加します。これは、ID トークンでバージョン 2 のトリガーイベントが利用できる唯一の変更です。

1. アクセストークンに数値、文字列、ブール値、JSON タイプのクレームを追加します。

1. アクセストークンに 3 つのスコープを追加します。

1. ID トークンとアクセストークンの `email` クレームを抑制します。

1. アクセストークンの `aws.cognito.signin.user.admin` スコープを抑制します。

------
#### [ JavaScript ]

```
export const handler = function(event, context) {

    var scopes = ["MyAPI.read", "MyAPI.write", "MyAPI.admin"]
    var claims = {}
    claims["aud"]= event.callerContext.clientId;
    claims["booleanTest"] = false;
    claims["longTest"] = 9223372036854775807;
    claims["exponentTest"] = 1.7976931348623157E308;
    claims["ArrayTest"] = ["test", 9223372036854775807, 1.7976931348623157E308, true];
    claims["longStringTest"] = "\{\
        \"first_json_block\": \{\
            \"key_A\": \"value_A\",\
            \"key_B\": \"value_B\"\
        \},\
        \"second_json_block\": \{\
            \"key_C\": \{\
                \"subkey_D\": [\
                    \"value_D\",\
                    \"value_E\"\
                ],\
                \"subkey_F\": \"value_F\"\
            \},\
            \"key_G\": \"value_G\"\
        \}\
    \}";
    claims["jsonTest"] = {
    	"first_json_block": {
    		"key_A": "value_A",
    		"key_B": "value_B"
    	},
    	"second_json_block": {
    		"key_C": {
    			"subkey_D": [
    				"value_D",
    				"value_E"
    			],
    			"subkey_F": "value_F"
    		},
    		"key_G": "value_G"
    	}
    };
    event.response = {
        "claimsAndScopeOverrideDetails": {
            "idTokenGeneration": {
                "claimsToAddOrOverride": claims,
                "claimsToSuppress": ["email"]
            },
            "accessTokenGeneration": {
                "claimsToAddOrOverride": claims,
                "claimsToSuppress": ["email"],
                "scopesToAdd": scopes,
                "scopesToSuppress": ["aws.cognito.signin.user.admin"]
            }
        }
    };
    console.info("EVENT response\n" + JSON.stringify(event, (_, v) => typeof v === 'bigint' ? v.toString() : v, 2))
    console.info("EVENT response size\n" + JSON.stringify(event, (_, v) => typeof v === 'bigint' ? v.toString() : v).length)
    // Return to Amazon Cognito
    context.done(null, event);
};
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
    "version": "2",
    "triggerSource": "TokenGeneration_HostedAuth",
    "region": "us-west-2",
    "userPoolId": "us-west-2_EXAMPLE",
    "userName": "JaneDoe",
    "callerContext": {
        "awsSdkVersion": "aws-sdk-unknown-unknown",
        "clientId": "1example23456789"
    },
    "request": {
        "userAttributes": {
            "sub": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
            "cognito:user_status": "CONFIRMED"
            "email_verified": "true",
            "phone_number_verified": "true",
            "phone_number": "+12065551212",
            "email": "Jane.Doe@example.com"
        },
        "groupConfiguration": {
            "groupsToOverride": ["group-1", "group-2", "group-3"],
            "iamRolesToOverride": ["arn:aws:iam::123456789012:role/sns_caller1"],
            "preferredRole": ["arn:aws:iam::123456789012:role/sns_caller1"]
        },
        "scopes": [
            "aws.cognito.signin.user.admin",
            "phone",
            "openid",
            "profile",
            "email"
        ]
    },
    "response": {
        "claimsAndScopeOverrideDetails": []
    }
}
```

------

## トークン生成前イベントバージョン 1 の例: 新しいクレームの追加と既存のクレームの非表示
<a name="aws-lambda-triggers-pre-token-generation-version-1-add-claim"></a>

この例では、トークン生成前の Lambda 関数でバージョン 1 のトリガーイベントを使用して、新しいクレームを追加し、既存のクレームを抑制します。

------
#### [ Node.js ]

```
const handler = async (event) => {
  event.response = {
    claimsOverrideDetails: {
      claimsToAddOrOverride: {
        my_first_attribute: "first_value",
        my_second_attribute: "second_value",
      },
      claimsToSuppress: ["email"],
    },
  };

  return event;
};

export { handler };
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。コード例 ではリクエストパラメータを処理しないため、空のリクエストでテストイベントを使用できます。共通のリクエストパラメータの詳細については、「[ユーザープールの Lambda トリガーイベント](cognito-user-pools-working-with-lambda-triggers.md#cognito-user-pools-lambda-trigger-event-parameter-shared)」を参照してください。

------
#### [ JSON ]

```
{
  "request": {},
  "response": {}
}
```

------

## トークン生成前イベントバージョン 1 の例: ユーザーグループのメンバーシップの変更
<a name="aws-lambda-triggers-pre-token-generation-version-1-change-group"></a>

この例では、トークン生成前の Lambda 関数でバージョン 1 のトリガーイベントを使用し、ユーザーのグループメンバーシップを変更します。

------
#### [ Node.js ]

```
const handler = async (event) => {
  event.response = {
    claimsOverrideDetails: {
      groupOverrideDetails: {
        groupsToOverride: ["group-A", "group-B", "group-C"],
        iamRolesToOverride: [
          "arn:aws:iam::XXXXXXXXXXXX:role/sns_callerA",
          "arn:aws:iam::XXXXXXXXX:role/sns_callerB",
          "arn:aws:iam::XXXXXXXXXX:role/sns_callerC",
        ],
        preferredRole: "arn:aws:iam::XXXXXXXXXXX:role/sns_caller",
      },
    },
  };

  return event;
};

export { handler };
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
  "request": {},
  "response": {}
}
```

------

# ユーザー移行の Lambda トリガー
<a name="user-pool-lambda-migrate-user"></a>

パスワードによるサインイン時にユーザーがユーザープールに存在しない場合、またはユーザーがパスワードを忘れた場合のフローにいる場合に、Amazon Cognito は、このトリガーを呼び出します。Amazon Cognito は、Lambda 関数が正常に値を返した後でユーザーをユーザープールに作成します。ユーザー移行の Lambda トリガーを使用した認証フローの詳細については、「[ユーザー移行の Lambda トリガーを使用したユーザーのインポート](cognito-user-pools-import-using-lambda.md)」を参照してください。

サインイン時、またはパスワードを忘れた場合のフロー中に、ユーザーを既存のユーザーディレクトリから Amazon Cognito ユーザープールに移行するには、この Lambda トリガーを使用します。

**Topics**
+ [ユーザー移行の Lambda トリガーのソース](#user-pool-lambda-migrate-user-trigger-source)
+ [ユーザー移行の Lambda トリガーのパラメータ](#cognito-user-pools-lambda-trigger-syntax-user-migration)
+ [例: 既存のパスワードを使用したユーザーの移行](#aws-lambda-triggers-user-migration-example-1)

## ユーザー移行の Lambda トリガーのソース
<a name="user-pool-lambda-migrate-user-trigger-source"></a>


| triggerSource 値 | イベント | 
| --- | --- | 
| UserMigration\$1Authentication[1](#cognito-migrate-user-passwordless-note) | サインイン時のユーザーの移行。 | 
| UserMigration\$1ForgotPassword | パスワードを忘れた場合のフロー実行時のユーザー移行 | 

1 ユーザーが[パスワードなしのサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless)で認証する場合、Amazon Cognito はこのトリガーを呼び出しません。

## ユーザー移行の Lambda トリガーのパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-user-migration"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "userName": "string",
    "request": {
        "password": "string",
        "validationData": {
            "string": "string",
            . . .
        },
        "clientMetadata": {
            "string": "string",
      	. . .
        }
    },
    "response": {
        "userAttributes": {
            "string": "string",
            . . .
        },
        "finalUserStatus": "string",
        "messageAction": "string",
        "desiredDeliveryMediums": [ "string", . . .],
        "forceAliasCreation": boolean,
        "enableSMSMFA": boolean
    }
}
```

------

### ユーザー移行リクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-user-migration-request"></a>

**userName**  
ユーザーがサインイン時に入力するユーザー名。

**password**  
ユーザーがサインイン時に入力するパスワード。Amazon Cognito は、パスワードを忘れた場合のフローによって開始されたリクエストでこの値を送信しません。

**validationData**  
ユーザーサインインリクエストに検証データを含む 1 つ以上のキーバリューペア。このデータを Lambda 関数に渡すには、[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) API アクションで ClientMetadata パラメータを使用できます。

**clientMetadata**  
ユーザー移行のトリガーの Lambda 関数へのカスタム入力として提供できる 1 つ、または複数のキーバリューペア。このデータを Lambda 関数に渡すには、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) および [ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html) API アクションで ClientMetadata パラメータを使用できます。

### ユーザー移行レスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-user-migration-response"></a>

**userAttributes**  
このフィールドは必須です。  
このフィールドには、Amazon Cognito がユーザープール内のユーザープロファイルに保存され、ユーザー属性として使用される、名前と値のペアが 1 つ以上含まれている必要があります。標準およびカスタムの両方のユーザー属性を含めることができます。カスタム属性は、標準属性と区別するために、`custom:` プレフィックスを必要とします。詳細については、「[カスタム属性](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes.html)」を参照してください。  
パスワードを忘れた場合のフローでパスワードをリセットするには、ユーザーに検証済みの E メールアドレスまたは電話番号のどちらかが必要です。Amazon Cognito は、ユーザー属性にある E メールアドレスまたは電話番号宛てに、パスワードのリセットコードが含まれるメッセージを送信します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-lambda-migrate-user.html)

**finalUserStatus**  
このパラメータを `CONFIRMED` に設定すると、ユーザーが以前のパスワードでサインインできるように自動確認することができます。ユーザーを `CONFIRMED` に設定した場合は、サインインする前に追加のアクション操作を実行する必要はありません。この属性を `CONFIRMED` に設定しない場合は、`RESET_REQUIRED` に設定されます。  
`RESET_REQUIRED` の `finalUserStatus` は、サインイン時の移行後、ユーザーはすぐにパスワードを変更する必要があり、クライアントアプリは認証フロー中に `PasswordResetRequiredException` を処理する必要があることを意味します。  
Amazon Cognito は、Lambda トリガーを使用して移行中にユーザープールに設定したパスワード強度ポリシーを強制しません。パスワードが設定したパスワードポリシーを満たさない場合でも、Amazon Cognito は引き続きユーザーを移行できるように、パスワードを受け入れます。パスワード強度ポリシーを施行してポリシーを満たさないパスワードを拒否するには、コード内のパスワード強度を検証して、パスワードがポリシーを満たさない場合は、finalUserStatus を `RESET_REQUIRED` に設定します。

**messageAction**  
このパラメータを `SUPPRESS` に設定すると、通常、Amazon Cognito は新規ユーザーに送信するウェルカムメッセージの送信を拒否することができます。関数がこのパラメータを返さない場合、Amazon Cognito はウェルカムメッセージを送信します。

**desiredDeliveryMediums**  
このパラメータを `EMAIL` に設定すると E メールで、`SMS` に設定すると SMS でウェルカムメッセージを送信できます。関数がこのパラメータを返さない場合、Amazon Cognito は SMS でウェルカムメッセージを送信します。

**forceAliasCreation**  
このパラメータを `TRUE` に設定した場合、UserAttributes パラメータの E メールアドレスまたは電話番号がすでに別のユーザーのエイリアスとして存在していると、API の呼び出しで以前のユーザーのエイリアスが新しく作成されたユーザーに移行されます。以前のユーザーはそのエイリアスを使用してログインできなくなります。  
このパラメータを、`FALSE` に設定し、エイリアスが存在する場合、Amazon Cognito はユーザーを移行せず、クライアントアプリにエラーを返します。  
このパラメータを返さない場合、Amazon Cognito はその値が「false」であると見なします。

**enableSMSMFA**  
このパラメータを `true` に設定すると、移行したユーザーはサインインするために SMS テキストメッセージの多要素認証 (MFA) を完了することが必要になります。ユーザープールで MFA が有効になっている必要があります。リクエストパラメータのユーザー属性には、電話番号を含める必要があります。電話番号がないと、そのユーザーの移行は失敗します。

## 例: 既存のパスワードを使用したユーザーの移行
<a name="aws-lambda-triggers-user-migration-example-1"></a>

この例の Lambda 関数は、既存のパスワードを使用してユーザーを移行し、Amazon Cognito からのウェルカムメッセージを抑制します。

------
#### [ Node.js ]

```
exports.handler = (event, context, callback) => {
  var user;

  if (event.triggerSource == "UserMigration_Authentication") {
    // authenticate the user with your existing user directory service
    user = authenticateUser(event.userName, event.request.password);
    if (user) {
      event.response.userAttributes = {
        email: user.emailAddress,
        email_verified: "true",
      };
      event.response.finalUserStatus = "CONFIRMED";
      event.response.messageAction = "SUPPRESS";
      context.succeed(event);
    } else {
      // Return error to Amazon Cognito
      callback("Bad password");
    }
  } else if (event.triggerSource == "UserMigration_ForgotPassword") {
    // Lookup the user in your existing user directory service
    user = lookupUser(event.userName);
    if (user) {
      event.response.userAttributes = {
        email: user.emailAddress,
        // required to enable password-reset code to be sent to user
        email_verified: "true",
      };
      event.response.messageAction = "SUPPRESS";
      context.succeed(event);
    } else {
      // Return error to Amazon Cognito
      callback("Bad password");
    }
  } else {
    // Return error to Amazon Cognito
    callback("Bad triggerSource " + event.triggerSource);
  }
};
```

------

# カスタムメッセージの Lambda トリガー
<a name="user-pool-lambda-custom-message"></a>

ユーザーに送信する E メールメッセージと SMS メッセージの外部標準がある場合、または実行時に独自のロジックをユーザーメッセージのフォーマットに適用する場合は、カスタムメッセージトリガーをユーザープールに追加します。カスタムメッセージ Lambda は、ユーザープールが送信する前に、すべての E メールおよび SMS メッセージの内容を受信します。その後、Lambda 関数でメッセージの内容と件名を変更することができます。

Amazon Cognito は、E メールまたは電話による確認メッセージ、または多要素認証 (MFA) コードを送信する前にこのトリガーを呼び出します。カスタムメッセージトリガーを使用して、メッセージを動的にカスタマイズできます。

リクエストには `codeParameter` が含まれます。これは、Amazon Cognito がユーザーに配信するコードのプレースホルダーとなる文字列です。メッセージ本文で検証コードを表示する位置に `codeParameter` 文字列を挿入します。Amazon Cognito がこのレスポンスを受信すると、Amazon Cognito が `codeParameter` 文字列を実際の検証コードに置き換えます。

**注記**  
`CustomMessage_AdminCreateUser` をトリガーソースとするカスタムメッセージ Lambda 関数の入力イベントには、ユーザー名と検証コードが含まれています。管理者が作成したユーザーはユーザー名とコードの両方を受け取る必要があるため、関数からのレスポンスにはユーザー名とコードのプレースホルダ変数を含める必要があります。メッセージのプレースホルダーは、`request.usernameParameter` および `request.codeParameter` の値です。これらの値は通常 `{username}` と `{####}` です。ベストプラクティスとして、変数名をハードコーディングするのではなく、入力値を参照します。

**Topics**
+ [カスタムメッセージの Lambda トリガーのソース](#cognito-user-pools-lambda-trigger-syntax-custom-message-trigger-source)
+ [カスタムメッセージの Lambda トリガーのパラメータ](#cognito-user-pools-lambda-trigger-syntax-custom-message)
+ [サインアップのカスタムメッセージの例](#aws-lambda-triggers-custom-message-example)
+ [管理者作成ユーザーのカスタムメッセージの例](#aws-lambda-triggers-custom-message-admin-example)

## カスタムメッセージの Lambda トリガーのソース
<a name="cognito-user-pools-lambda-trigger-syntax-custom-message-trigger-source"></a>


| triggerSource 値 | イベント | 
| --- | --- | 
| CustomMessage\$1SignUp | カスタムメッセージ - サインアップ後に確認コードを送信するため。 | 
| CustomMessage\$1AdminCreateUser | カスタムメッセージ – 新規ユーザーに一時パスワードを送信するため。 | 
| CustomMessage\$1ResendCode | カスタムメッセージ – 既存ユーザーに確認コードを再送するため。 | 
| CustomMessage\$1ForgotPassword | カスタムメッセージ - 忘れたパスワードのリクエスト用の確認コードを送信するため。 | 
| CustomMessage\$1UpdateUserAttribute | カスタムメッセージ - ユーザーの E メールまたは電話番号が変更されると、このトリガーは検証コードをそのユーザーに自動的に送信します。他の属性には使用できません。 | 
| CustomMessage\$1VerifyUserAttribute | カスタムメッセージ – ユーザーが手動で新しい E メールや電話番号の認証コードをリクエストすると、このトリガーからユーザーに認証コードが送信されます。 | 
| CustomMessage\$1Authentication | カスタムメッセージ - 認証時に MFA コードを送信するため。 | 

## カスタムメッセージの Lambda トリガーのパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-custom-message"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
        "userAttributes": {
            "string": "string",
            . . .
        }
        "codeParameter": "####",
        "usernameParameter": "string",
        "clientMetadata": {
            "string": "string",
            . . .
        }
    },
    "response": {
        "smsMessage": "string",
        "emailMessage": "string",
        "emailSubject": "string"
    }
}
```

------

### カスタムメッセージリクエストパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-custom-message-request"></a>

**userAttributes**  
ユーザー属性を表す 1 つ以上の名前 - 値ペア。

**codeParameter**  
カスタムメッセージで、検証コードのプレースホルダーとして使用する文字列。

**usernameParameter**  
ユーザー名。Amazon Cognito は、管理者が作成したユーザーからのリクエストにこのパラメータを含めます。

**clientMetadata**  
カスタムメッセージのトリガーに指定する Lambda 関数へのカスタム入力として提供できる 1 つ、または複数のキー/値ペア。カスタムメッセージ関数を呼び出すリクエストには、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) および [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションの ClientMetadata パラメータで渡されたデータは含まれません。このデータを Lambda 関数に渡すには、以下の API アクションで ClientMetadata パラメータを使用できます。  
+  [AdminResetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html) 
+  [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) 
+  [AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html)
+  [ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html)
+  [GetUserAttributeVerificationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserAttributeVerificationCode.html)
+  [ResendConfirmationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html)
+  [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html)
+  [UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html)

### カスタムメッセージレスポンスパラメータ
<a name="cognito-user-pools-lambda-trigger-syntax-custom-message-response"></a>

レスポンスで、ユーザーへのメッセージに使用するカスタムテキストを指定します。これらのパラメータに対して Amazon Cognito が適用する文字列制約については、「[MessageTemplateType](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_MessageTemplateType.html)」を参照してください。

**smsMessage**  
ユーザーに送信されるカスタム SMS メッセージ。リクエストで受信する `codeParameter` 値を含める必要があります。

**emailMessage**  
ユーザーに送信するカスタム E メールメッセージ。`emailMessage` パラメータで HTML 書式を使用できます。リクエストで受信される `codeParameter` 値を変数 `{####}` として含める必要があります。Amazon Cognito は、ユーザープールの `EmailSendingAccount` 属性が `DEVELOPER` の場合のみ、`emailMessage` パラメータを使用できます。ユーザープールの `EmailSendingAccount` 属性が、`DEVELOPER` ではなく、`emailMessage` パラメータが返されると、Amazon Cognito は 400 エラーコード `com.amazonaws.cognito.identity.idp.model.InvalidLambdaResponseException` を生成します。Amazon Simple Email Service (Amazon SES) を使用して E メールメッセージを送信する場合、ユーザープールの `EmailSendingAccount` 属性は `DEVELOPER` です。それ以外の場合、値は `COGNITO_DEFAULT` です。

**emailSubject**  
カスタムメッセージの件名。`emailSubject` パラメータは、ユーザープールの EmailSendingAccount 属性が `DEVELOPER` の場合にのみ使用できます。ユーザープールの `EmailSendingAccount` 属性が `DEVELOPER` ではなく、Amazon Cognito が `emailSubject` パラメータを返した場合、Amazon Cognito は 400 エラーコード `com.amazonaws.cognito.identity.idp.model.InvalidLambdaResponseException` を生成します。Amazon Simple Email Service (Amazon SES) を使用して E メールメッセージを送信する場合、ユーザープールの `EmailSendingAccount` 属性は `DEVELOPER` です。それ以外の場合、値は `COGNITO_DEFAULT` です。

## サインアップのカスタムメッセージの例
<a name="aws-lambda-triggers-custom-message-example"></a>

この Lambda 関数の例は、サービスでアプリがユーザーへの検証コードの送信が必要とされる場合に、E メールまたは SMS メッセージをカスタマイズします。

Amazon Cognito は、登録後、検証コードの再送信時、パスワードを忘れた場合、ユーザー属性の検証時といった複数のイベントで Lambda トリガーを呼び出すことができます。レスポンスには、SMS と E メールの両方のメッセージが含まれます。メッセージにはコードのパラメータ `"####"` を含める必要があります。このパラメータは、ユーザーが受け取る検証コードのプレースホルダーです。

E メールメッセージの最大長は 20,000 UTF-8 文字です。この長さには検証コードが含まれます。これらの E メールメッセージでは、HTML タグを使用できます。

SMS メッセージの最大長は 140 UTF-8 文字です。この長さには検証コードが含まれます。

------
#### [ Node.js ]

```
const handler = async (event) => {
  if (event.triggerSource === "CustomMessage_SignUp") {
    const message = `Thank you for signing up. Your confirmation code is ${event.request.codeParameter}.`;
    event.response.smsMessage = message;
    event.response.emailMessage = message;
    event.response.emailSubject = "Welcome to the service.";
  }
  return event;
};

export { handler };
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
	"version": "1",
	"region": "us-west-2",
	"userPoolId": "us-west-2_EXAMPLE",
	"userName": "test-user",
	"callerContext": {
		"awsSdkVersion": "aws-sdk-unknown-unknown",
		"clientId": "1example23456789"
	},
	"triggerSource": "CustomMessage_SignUp",
	"request": {
		"userAttributes": {
			"sub": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
			"cognito:user_status": "CONFIRMED",
			"email_verified": "true",
			"phone_number_verified": "true",
			"phone_number": "+12065551212",
			"email": "test-user@example.com"
		},
		"codeParameter": "{####}",
		"linkParameter": "{##Click Here##}",
		"usernameParameter": "None"
	},
	"response": {
		"smsMessage": "None",
		"emailMessage": "None",
		"emailSubject": "None"
	}
}
```

------

## 管理者作成ユーザーのカスタムメッセージの例
<a name="aws-lambda-triggers-custom-message-admin-example"></a>

Amazon Cognito がこのカスタムメッセージ Lambda 関数のサンプルに送信したリクエストは、`triggerSource` 値が `CustomMessage_AdminCreateUser` で、ユーザー名と仮パスワードが含まれます。関数は、リクエストの仮パスワードから `${event.request.codeParameter}` を入力し、リクエストのユーザー名から `${event.request.usernameParameter}` を入力します。

カスタムメッセージは、レスポンスオブジェクトの `smsMessage` と `emailMessage` に `codeParameter` と `usernameParameter` の値を挿入する必要があります。この例では、関数は、レスポンスフィールド `event.response.smsMessage` と `event.response.emailMessage` に同じメッセージを書き込みます。

E メールメッセージの最大長は 20,000 UTF-8 文字です。この長さには検証コードが含まれます。これらの E メールでは HTML タグを使用できます。SMS メッセージの最大長は 140 UTF-8 文字です。この長さには検証コードが含まれます。

レスポンスには、SMS と E メールの両方のメッセージが含まれます。

------
#### [ Node.js ]

```
const handler = async (event) => {
  if (event.triggerSource === "CustomMessage_AdminCreateUser") {
    const message = `Welcome to the service. Your user name is ${event.request.usernameParameter}. Your temporary password is ${event.request.codeParameter}`;
    event.response.smsMessage = message;
    event.response.emailMessage = message;
    event.response.emailSubject = "Welcome to the service";
  }
  return event;
};

export { handler };
```

------

Amazon Cognito は Lambda 関数にイベント情報を渡します。関数はレスポンスで、同じイベントオブジェクトを変更と共に Amazon Cognito に返します。Lambda コンソールで、Lambda トリガーに関連するデータを使用したテストイベントをセットアップできます。以下は、このコードサンプルのテストイベントです。

------
#### [ JSON ]

```
{
  "version": 1,
  "triggerSource": "CustomMessage_AdminCreateUser",
  "region": "<region>",
  "userPoolId": "<userPoolId>",
  "userName": "<userName>",
  "callerContext": {
      "awsSdk": "<calling aws sdk with version>",
      "clientId": "<apps client id>",
      ...
  },
  "request": {
      "userAttributes": {
          "phone_number_verified": false,
          "email_verified": true,
           ...
      },
      "codeParameter": "####",
      "usernameParameter": "username"
  },
  "response": {
      "smsMessage": "<custom message to be sent in the message with code parameter and username parameter>"
      "emailMessage": "<custom message to be sent in the message with code parameter and username parameter>"
      "emailSubject": "<custom email subject>"
  }
}
```

------

# カスタム送信者の Lambda トリガー
<a name="user-pool-lambda-custom-sender-triggers"></a>

Lambda トリガーである `CustomEmailSender` と `CustomSMSSender` は、ユーザープールでサードパーティーの E メール通知および SMS 通知をサポートします。Lambda 関数コード内からユーザーに通知を送信するには、希望の SMS プロバイダーと E メールプロバイダーを選択して使用することができます。Amazon Cognito が、招待、確認コード、検証コード、および仮パスワードをユーザーに送信する必要がある場合、イベントは、設定された Lambda 関数を有効化します。Amazon Cognito は、有効化された Lambda 関数にコードと一時パスワード (シークレット) を送信します。Amazon Cognito は、 AWS KMS カスタマーマネージドキーと を使用してこれらのシークレットを暗号化します AWS Encryption SDK。 AWS Encryption SDK は、汎用データの暗号化と復号に役立つクライアント側の暗号化ライブラリです。

**[CustomEmailSender](user-pool-lambda-custom-email-sender.md)**  
Amazon Cognito は、E メール通知をユーザーに送信するためにこのトリガーを呼び出します。

**[CustomSMSSender](user-pool-lambda-custom-sms-sender.md)**  
Amazon Cognito は、SMS 通知をユーザーに送信するためにこのトリガーを呼び出します。

## 暗号化の概念
<a name="user-pool-lambda-custom-sender-triggers-resources"></a>

Amazon Cognito は、カスタム送信者トリガーに送信するイベントでユーザーのコードをプレーンテキストで送信しません。Lambda 関数は、イベント内のコードを復号する必要があります。次の概念は、ユーザーに配信できるコードを取得するために関数が使用する必要がある暗号化アーキテクチャです。

**AWS KMS**  
AWS KMS は、 AWS KMS キーを作成および制御するためのマネージドサービスです。これらのキーは、データを暗号化します。詳細については、「[AWS Key Management Serviceとは何ですか?](/kms/latest/developerguide/overview.html)」を参照してください。

**KMS キー**  
KMS キーは、暗号化キーの論理表現です。KMS キーには、キー ID、作成日、説明、キーステータスなどのメタデータが含まれます。KMS キーには、データの暗号化と復号に使用されるキーマテリアルも含まれています。詳細については、「[AWS KMS キーの削除](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys)」を参照してください。

**対称 KMS キー**  
対称 KMS キーは、暗号化されていない AWS KMS を終了しない 256 ビットの暗号化キーです。対称 KMS キーを使用するには、 を呼び出す必要があります AWS KMS。Amazon Cognito は対称キーを使用します。同じキーで暗号化と復号化が行われます。詳細については、「[KMS キーの削除](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks)」を参照してください。

## カスタム送信者 Lambda トリガーについて知っておくべきこと
<a name="user-pool-lambda-custom-sender-triggers-things-to-know"></a>
+ これらの Lambda トリガーを使用するようにユーザープールを設定するには、 AWS CLI または SDK を使用します。これらの設定は、Amazon Cognito コンソールからは利用できません。

  `UpdateUserPool` オペレーションは Lambda 設定を指定します。このオペレーションをリクエストする場合は、ユーザープールのすべてのパラメータ*および*変更対象のパラメータが必要です。関連するすべてのパラメータを指定しない場合、Amazon Cognito は不足しているパラメータの値をデフォルトに設定します。次の CLI AWS の例に示すように、ユーザープールに追加または保持するすべての Lambda 関数のエントリを含めます。詳細については、「[ユーザープールとアプリケーションクライアントの設定更新](cognito-user-pool-updating.md)」を参照してください。

  ```
      #Send this parameter in an 'aws cognito-idp update-user-pool' CLI command, including any existing 
      #user pool configurations. This snippet also includes a pre sign-up trigger for syntax reference. The pre sign-up trigger
      #doesn't have a role in custom sender triggers.
                
        --lambda-config "PreSignUp=lambda-arn, \
                         CustomSMSSender={LambdaVersion=V1_0,LambdaArn=lambda-arn}, \
                         CustomEmailSender={LambdaVersion=V1_0,LambdaArn=lambda-arn}, \
                         KMSKeyID=key-id"
  ```

  リクエストで `UpdateUserPool` の JSON 本文を使用する場合、次の `LambdaConfig` スニペットはカスタム SMS および E メール送信者関数をリクエストに割り当てます。

  ```
  "LambdaConfig": {
     "KMSKeyID": "arn:aws:kms:us-east-1:111122223333:key/a6c4f8e2-0c45-47db-925f-87854bc9e357",
     "CustomEmailSender": {
        "LambdaArn": "arn:aws:lambda:us-east-1:111122223333:function:MyFunction",
        "LambdaVersion": "V1_0"
     },
     "CustomSMSSender": {
        "LambdaArn": "arn:aws:lambda:us-east-1:111122223333:function:MyFunction",
        "LambdaVersion": "V1_0"
     }
  ```
+ `update-user-pool` AWS CLI コマンドを使用してカスタム送信者 Lambda トリガーを削除するには、 から `CustomSMSSender`または `CustomEmailSender`パラメータを省略し`--lambda-config`、ユーザープールで使用する他のすべてのトリガーを含めます。

  `UpdateUserPool` API リクエストを使用してカスタム送信者の Lambda トリガーを削除するには、ユーザープール設定の残りを含むリクエスト本文から `CustomSMSSender` または `CustomEmailSender` パラメータを省略します。
+ Amazon Cognito は、ユーザーの一時パスワードで `&lt;` (`<`) および `&gt;` (`>`) などの予約文字を HTML エスケープします。これらの文字は、Amazon Cognito がカスタム E メール送信者機能に送信する一時パスワードには表示される場合がありますが、一時的な確認コードには表示されません。一時パスワードを送信するには、Lambda 関数がパスワードを復号した後、ユーザーにメッセージを送信する前に、これらの文字をアンエスケープする必要があります。

## カスタム送信者 Lambda トリガーのアクティブ化
<a name="enable-custom-sender-lambda-trigger"></a>

カスタムロジックを使用して SMS または E メールメッセージをユーザープールに送信するには、カスタム送信者トリガーを設定します。以下の手順では、カスタム SMS トリガー、カスタム E メールトリガー、またはその両方をユーザープールに割り当てます。カスタム送信者トリガーを追加すると、Amazon Cognito は、SMS または E メールメッセージを送信するデフォルトの動作ではなく、電話番号やワンタイムコードなどのユーザー属性を常に Lambda 関数に送信します。

1.  AWS Key Management Service () で[対称暗号化キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks)を作成しますAWS KMS。Amazon Cognito は、シークレット (仮パスワード、検証コード、認証用のワンタイムパスワード、確認コード) を生成し、この KMS キーを使用してシークレットを [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) で暗号化します。その後、Lambda 関数 AWS Encryption SDK で を使用してシークレットを復号し、プレーンテキストでユーザーに送信できます。

1. ユーザープールを作成または更新する IAM プリンシパルは、Amazon Cognito がコードを暗号化するために使用する KMS キーに対して 1 回限りの付与を作成します。このプリンシパルに KMS キーへの `CreateGrant` アクセス許可を付与します。この例の KMS キーポリシーを有効にするには、ユーザープールを更新する管理者が、IAM ロール `arn:aws:iam::111222333444:role/my-example-administrator-role` で引き受けたロールセッションにサインインしている必要があります。

   次のリソースベースのポリシーを、環境に合わせて変更し、KMS キーに適用します。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
       {
           "Effect": "Allow",
           "Principal": {
               "AWS": "arn:aws:iam::111122223333:role/my-example-administrator-role"
           },
           "Action": "kms:CreateGrant",
           "Resource": "arn:aws:kms:us-west-2:111122223333:key/1example-2222-3333-4444-999example",
           "Condition": {
               "StringEquals": {
                  "kms:EncryptionContext:userpool-id": "us-west-2_EXAMPLE"
               }
           }
       },
       {
           "Sid": "Allow Lambda to decrypt",
           "Effect": "Allow",
           "Principal": {
               "AWS": "arn:aws:iam::111122223333:role/my-lambda-function-role"
           },
           "Action": "kms:Decrypt",
           "Resource": "*"
       }]
   }
   ```

------

1. カスタム送信者トリガーのための Lambda 関数を作成します。Amazon Cognito は [AWS 暗号化 SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) を使用してシークレット (一時パスワードまたはユーザーの API リクエストを承認するコード) を暗号化します。

   1. KMS キーに対して少なくとも `kms:Decrypt` アクセス許可を持つ [Lambda 実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)を割り当てます。

   1. メッセージを送信するための Lambda 関数コードを作成します。関数への入力イベントにはシークレットが含まれています。関数で、 を使用してシークレットを復号 AWS Encryption SDK し、関連するメタデータを処理します。次に、メッセージを配信するカスタム API に、コード、独自のカスタムメッセージ、宛先の電話番号を送信します。

   1. Lambda 関数 AWS Encryption SDK に を追加します。詳細については、「[AWS Encryption SDK プログラミング言語](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/programming-languages.html)」を参照してください。Lambda パッケージを更新するには、次のステップを完了します。

      1. Lambda 関数を.zip ファイルとして AWS マネジメントコンソールにエクスポートします。

      1. 関数を開き、 を追加します AWS Encryption SDK。詳細とダウンロードリンクについては、AWS Encryption SDK デベロッパーガイドの「[AWS Encryption SDK プログラミング言語](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/programming-languages.html)」を参照してください。

      1. SDK の依存関係を使用して関数を ZIP 圧縮し、その関数を Lambda にアップロードします。詳細については、「*AWS Lambda デベロッパーガイド*」の「[Lambda 関数の .zip ファイルアーカイブとしてのデプロイ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-zip.html#configuration-function-create)」を参照してください。

1. Amazon Cognito サービスプリンシパルに、Lambda 関数を呼び出すための `cognito-idp.amazonaws.com` へのアクセス権を付与します。

   次の AWS CLI コマンドは、Lambda 関数を呼び出すためのアクセス許可を Amazon Cognito に付与します。

   ```
   aws lambda add-permission --function-name lambda_arn --statement-id "CognitoLambdaInvokeAccess" --action lambda:InvokeFunction --principal cognito-idp.amazonaws.com
   ```

1. カスタム送信者 Lambda トリガーを追加する `LambdaConfig` パラメータを使用して [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストを生成します。Amazon Cognito コンソールでは、このタイプのトリガーを追加することはできません。カスタム送信者トリガーには、`KMSKeyID` に加えて、`CustomSMSSender` または `CustomEmailSender` (あるいは両方) の `LambdaConfig` パラメータが必要です。

# カスタム E メール送信者の Lambda トリガー
<a name="user-pool-lambda-custom-email-sender"></a>

ユーザープールにカスタム E メール送信者トリガーを割り当てると、ユーザーイベントで E メールメッセージの送信が必要になった時点で、Amazon Cognito がデフォルトの動作ではなく Lambda 関数を呼び出します。カスタム送信者トリガーを使用すると、 AWS Lambda 関数は選択した方法とプロバイダーを通じてユーザーに E メール通知を送信できます。関数のカスタムコードは、すべての e メールメッセージを、ユーザープールから処理して配信する必要があります。

このトリガーは、ユーザープールが E メールメッセージを送信する方法をより細かく制御するシナリオに役立ちます。Lambda 関数は、例えば、複数の検証済み ID またはクロス AWS リージョンを管理する場合など、Amazon SES API オペレーションへの呼び出しをカスタマイズできます。また、関数は、メッセージを別の配信メディアまたはサードパーティーサービスにリダイレクトすることもできます。

カスタム E メール送信者トリガーを設定する方法については、「[カスタム送信者 Lambda トリガーのアクティブ化](user-pool-lambda-custom-sender-triggers.md#enable-custom-sender-lambda-trigger)」を参照してください。

## カスタム E メール送信者の Lambda トリガーのソース
<a name="trigger-source"></a>

以下の表には、Lambda コード内のカスタム E メールトリガーのソースに対するトリガーイベントが記載されています。


| `TriggerSource value` | イベント | 
| --- | --- | 
| CustomEmailSender\$1SignUp | ユーザーがサインアップすると、Amazon Cognito がウェルカムメッセージを送信します。 | 
| CustomEmailSender\$1Authentication | ユーザーがサインインすると、Amazon Cognito が E メール OTP または MFA コードを送信します。 | 
| CustomEmailSender\$1ForgotPassword | ユーザーがパスワードをリセットするコードを要求します。 | 
| CustomEmailSender\$1ResendCode | ユーザーが代替アカウント確認コードをリクエストします。 | 
| CustomEmailSender\$1UpdateUserAttribute | ユーザーが E メールアドレスまたは電話番号の属性を更新すると、Amazon Cognito は属性を検証するためのコードを送信します。 | 
| CustomEmailSender\$1VerifyUserAttribute | ユーザーが新しい E メールアドレスまたは電話番号属性を作成し、Amazon Cognito は属性を検証するコードを送信します。 | 
| CustomEmailSender\$1AdminCreateUser | ユーザープールに新しいユーザーを作成すると、Amazon Cognito から一時パスワードが送信されます。 | 
| CustomEmailSender\$1AccountTakeOverNotification | Amazon Cognito は、ユーザーアカウントを引き継ぐ試みを検出し、ユーザーに通知を送信します。 | 

## カスタム E メール送信者の Lambda トリガーパラメータ
<a name="custom-email-sender-parameters"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
        "type": "customEmailSenderRequestV1",
        "code": "string",
        "clientMetadata": {
            "string": "string",
             . . .
            },
        "userAttributes": {
            "string": "string",
            . . .
         }
}
```

------

### カスタム E メール送信者のリクエストパラメータ
<a name="custom-email-sender-request-parameters"></a>

**型**  
リクエストバージョン。カスタム E メール送信者イベントの場合、この文字列の値は常に `customEmailSenderRequestV1` です。

**コード**  
関数が復号してユーザーに送信できる暗号化されたコード。

**clientMetadata**  
カスタム E メール送信者 Lambda 関数トリガーへのカスタム入力として提供できる 1 つ以上のキーバリューペア このデータを Lambda 関数に渡すには、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) および [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) API アクションで ClientMetadata パラメータを使用します。Amazon Cognito は、認証後関数に渡すリクエストの [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) および [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションの ClientMetadata パラメータからのデータを含めません。  
Amazon Cognito は、次のトリガーソースを持つイベントでカスタム E メールトリガー関数に `ClientMetadata` を送信します。  
+ `CustomEmailSender_ForgotPassword`
+ `CustomEmailSender_SignUp`
+ `CustomEmailSender_Authentication`
Amazon Cognito は、ソース `CustomEmailSender_AccountTakeOverNotification` を使用してトリガーイベントで `ClientMetadata` を送信しません。

**userAttributes**  
ユーザー属性を表す 1 つ以上のキーバリューペア。

### カスタム E メール送信者の応答パラメータ
<a name="custom-email-sender-response-parameters"></a>

Amazon Cognito は、カスタム E メール送信者のレスポンスに追加の情報が返されることを期待しません。Lambda 関数は、イベントを解釈し、コードを復号してから、メッセージコンテンツを配信する必要があります。一般的な関数は E メールメッセージをアセンブルし、サードパーティーの SMTP リレーに誘導します。

## コード例
<a name="custom-email-sender-code-examples"></a>

次の Node.js 例は、カスタム E メール送信者の Lambda 関数で E メールメッセージイベントを処理します。この例では、関数に 2 つの環境変数が定義されていることを前提としています。

**`KEY_ID`**  
ユーザーのコードの暗号化と復号に使用する KMS キーの ID。

**`KEY_ARN`**  
ユーザーのコードを暗号化および復号化するために使用する KMS キーの Amazon リソースネーム (ARN)。

**この関数をデプロイするには**

1. デベロッパーワークスペースに最新バージョンの NodeJS をインストールします。

1. ワークスペースに新しい NodeJS プロジェクトを作成します。

1. `npm init -y` でプロジェクトを初期化します。

1. Lambda 関数のスクリプトを作成します (`touch index.mjs`)。

1. 以下の例の内容を `index.mjs` に貼り付けます。

1. プロジェクトの依存関係をダウンロードします AWS Encryption SDK。 `npm install @aws-crypto/client-node`

1. プロジェクトディレクトリをファイルに圧縮します (`zip -r my_deployment_package.zip .`)。

1. [ZIP ファイルを関数にデプロイします](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-package.html)。

このサンプル関数はコードを復号し、サインアップイベントの場合は、ユーザーの E メールアドレスへの E メールメッセージの送信をシミュレートします。

```
import { KmsKeyringNode, buildClient, CommitmentPolicy } from '@aws-crypto/client-node';

// Configure the encryption SDK client with the KMS key from the environment variables
const { encrypt, decrypt } = buildClient(
    CommitmentPolicy.REQUIRE_ENCRYPT_ALLOW_DECRYPT
);

const generatorKeyId = process.env.KEY_ID;
const keyIds = [process.env.KEY_ARN];
const keyring = new KmsKeyringNode({ generatorKeyId, keyIds });

// Example function to simulate sending email.
// This example logs message details to CloudWatch Logs from your Lambda function.
// Update this function with custom logic that sends an email message to 'emailaddress' with body 'message'.
const sendEmail = async (emailAddress, message) => {
    // Log the destination with the email address masked.
    console.log(`Simulating email send to ${emailAddress.replace(/[^@.]/g, '*')}`);
    // Log the message with the code masked.
    console.log(`Message content: ${message.replace(/\b\d{6,8}\b/g, '********')}`);
    // Simulate API delay
    await new Promise(resolve => setTimeout(resolve, 100));
    console.log('Email sent successfully');
    return true;
};

export const handler = async (event) => {
    try {
        // Decrypt the secret code using encryption SDK
        let plainTextCode;
        if (event.request.code) {
            const { plaintext, messageHeader } = await decrypt(keyring, Buffer.from(event.request.code, 'base64'));
            plainTextCode = Buffer.from(plaintext).toString('utf-8');
        }

        // Handle different trigger sources
        if (event.triggerSource == 'CustomEmailSender_SignUp') {
            const emailAddress = event.request.userAttributes.email;
            const message = `Welcome! Your verification code is: ${plainTextCode}`;
            await sendEmail(emailAddress, message);
        }
        else if (event.triggerSource == 'CustomEmailSender_ResendCode') {
            // Handle resend code
        }
        else if (event.triggerSource == 'CustomEmailSender_ForgotPassword') {
            // Handle forgot password
        }
        else if (event.triggerSource == 'CustomEmailSender_UpdateUserAttribute') {
            // Handle update attribute
        }
        else if (event.triggerSource == 'CustomEmailSender_VerifyUserAttribute') {
            // Handle verify attribute
        }
        else if (event.triggerSource == 'CustomEmailSender_AdminCreateUser') {
            // Handle admin create user
        }
        else if (event.triggerSource == 'CustomEmailSender_Authentication') {
            // Handle authentication
        }
        else if (event.triggerSource == 'CustomEmailSender_AccountTakeOverNotification') {
            // Handle account takeover notification
        }

        return;
    } catch (error) {
        console.error('Error in custom email sender:', error);
        throw error;
    }
};
```

# カスタム SMS 送信者の Lambda トリガー
<a name="user-pool-lambda-custom-sms-sender"></a>

ユーザープールにカスタム SMS 送信者トリガーを割り当てると、ユーザーイベントで SMS メッセージの送信が必要になった時点で、Amazon Cognito がデフォルトの動作ではなく Lambda 関数を呼び出します。カスタム送信者トリガーを使用すると、 AWS Lambda 関数は選択したメソッドとプロバイダーを通じて SMS 通知をユーザーに送信できます。関数のカスタムコードは、すべての SMS メッセージを、ユーザープールから処理して配信する必要があります。

このトリガーは、ユーザープールが SMS メッセージを送信する方法をより細かく制御するシナリオを提供します。Lambda 関数は、複数の発信元 ID またはクロス AWS リージョンを管理する場合など、Amazon SNS API オペレーションへの呼び出しをカスタマイズできます。また、関数は、メッセージを別の配信メディアまたはサードパーティーサービスにリダイレクトすることもできます。

カスタム E メール送信者トリガーを設定する方法については、「[カスタム送信者 Lambda トリガーのアクティブ化](user-pool-lambda-custom-sender-triggers.md#enable-custom-sender-lambda-trigger)」を参照してください。

## カスタム SMS 送信者の Lambda トリガーのソース
<a name="trigger-source"></a>

以下の表には、Lambda コード内のカスタム SMS トリガーのソースに対するトリガーイベントが記載されています。


| `TriggerSource value` | イベント | 
| --- | --- | 
| CustomSMSSender\$1SignUp | ユーザーがサインアップすると、Amazon Cognito がウェルカムメッセージを送信します。 | 
| CustomSMSSender\$1ForgotPassword | ユーザーがパスワードをリセットするコードを要求します。 | 
| CustomSMSSender\$1ResendCode | ユーザーは、登録を確認するために新しいコードをリクエストします。 | 
| CustomSMSSender\$1VerifyUserAttribute | ユーザーが新しい E メールアドレスまたは電話番号の属性を作成すると、Amazon Cognito は属性を検証するコードを送信します。 | 
| CustomSMSSender\$1UpdateUserAttribute | ユーザーが E メールアドレスまたは電話番号の属性を更新すると、Amazon Cognito は属性を検証するためのコードを送信します。 | 
| CustomSMSSender\$1Authentication | ユーザーがサインインすると、Amazon Cognito が SMS OTP または MFA コードを送信します。 | 
| CustomSMSSender\$1AdminCreateUser | ユーザープールに新しいユーザーを作成すると、Amazon Cognito から一時パスワードが送信されます。 | 

## カスタム SMS 送信者の Lambda トリガーパラメータ
<a name="custom-sms-sender-parameters"></a>

Amazon Cognito がこの Lambda 関数に渡すリクエストは、以下のパラメータと Amazon Cognito がすべてのリクエストに追加する[共通パラメータ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-shared)を組み合わせたものです。

------
#### [ JSON ]

```
{
    "request": {
        "type": "customSMSSenderRequestV1",
        "code": "string",
        "clientMetadata": {
            "string": "string",
             . . .
            },
        "userAttributes": {
            "string": "string",
            . . .
         }
}
```

------

### カスタム SMS 送信者のリクエストパラメータ
<a name="custom-sms-sender-request-parameters"></a>

**型**  
リクエストバージョン。カスタム SMS 送信者イベントの場合、この文字列の値は常に `customSMSSenderRequestV1` です。

**コード**  
関数が復号してユーザーに送信できる暗号化されたコード。

**clientMetadata**  
カスタム SMS 送信者 Lambda 関数トリガーへのカスタム入力として提供できる 1 つ以上のキーバリューペア このデータを Lambda 関数に渡すには、[AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) および [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) API アクションで ClientMetadata パラメータを使用します。Amazon Cognito は、認証後関数に渡すリクエストの [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) および [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションの ClientMetadata パラメータからのデータを含めません。

**userAttributes**  
ユーザー属性を表す 1 つ以上のキーバリューペア。

### カスタム SMS 送信者の応答パラメータ
<a name="custom-sms-sender-response-parameters"></a>

Amazon Cognito は、レスポンスに追加の返品情報を期待しません。関数では、API オペレーションを使用してリソースをクエリして変更したり、イベントメタデータを外部システムに記録することができます。

## コード例
<a name="custom-sms-sender-code-examples"></a>

次の Node.js 例は、カスタム SMS 送信者 Lambda 関数で SMS メッセージイベントを処理します。この例では、関数に 2 つの環境変数が定義されていることを前提としています。

**`KEY_ID`**  
ユーザーのコードの暗号化と復号に使用する KMS キーの ID。

**`KEY_ARN`**  
ユーザーのコードを暗号化および復号化するために使用する KMS キーの Amazon リソースネーム (ARN)。

**この関数をデプロイするには**

1. デベロッパーワークスペースに最新バージョンの NodeJS をインストールします。

1. ワークスペースに新しい NodeJS プロジェクトを作成します。

1. `npm init -y` でプロジェクトを初期化します。

1. Lambda 関数のスクリプトを作成します (`touch index.mjs`)。

1. 以下の例の内容を `index.mjs` に貼り付けます。

1. プロジェクトの依存関係をダウンロードします AWS Encryption SDK。 `npm install @aws-crypto/client-node`

1. プロジェクトディレクトリをファイルに圧縮します (`zip -r my_deployment_package.zip .`)。

1. [ZIP ファイルを関数にデプロイします](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-package.html)。

```
import { KmsKeyringNode, buildClient, CommitmentPolicy } from '@aws-crypto/client-node';

// Configure the encryption SDK client with the KMS key from the environment variables
const { encrypt, decrypt } = buildClient(
    CommitmentPolicy.REQUIRE_ENCRYPT_ALLOW_DECRYPT
);

const generatorKeyId = process.env.KEY_ID;
const keyIds = [process.env.KEY_ARN];
const keyring = new KmsKeyringNode({ generatorKeyId, keyIds });

// Example function to simulate sending SMS.
// This example logs message details to CloudWatch Logs from your Lambda function.
// Update this function with custom logic that sends an SMS message to 'phoneNumber' with body 'message'.
const sendSMS = async (phoneNumber, message) => {
    // Log the destination with the phone number masked.
    console.log(`Simulating SMS send to ${phoneNumber.replace(/[^+]/g, '*')}`);
    // Log the message with the code masked.
    console.log(`Message content: ${message.replace(/\b\d{6,8}\b/g, '********')}`);    
    // Simulate API delay
    await new Promise(resolve => setTimeout(resolve, 100));
    console.log('SMS sent successfully');
    return true;
};

export const handler = async (event) => {
    try {
        // Decrypt the secret code using encryption SDK
        let plainTextCode;
        if (event.request.code) {
            const { plaintext, messageHeader } = await decrypt(keyring, Buffer.from(event.request.code, 'base64'));
            plainTextCode = Buffer.from(plaintext).toString('utf-8');
        }

        // Handle different trigger sources
        if (event.triggerSource == 'CustomSMSSender_SignUp') {
            const phoneNumber = event.request.userAttributes.phone_number;
            const message = `Welcome! Your verification code is: ${plainTextCode}`;
            await sendSMS(phoneNumber, message);
        }
        else if (event.triggerSource == 'CustomSMSSender_ResendCode') {
            // Handle resend code
        }
        else if (event.triggerSource == 'CustomSMSSender_ForgotPassword') {
            // Handle forgot password
        }
        else if (event.triggerSource == 'CustomSMSSender_UpdateUserAttribute') {
            // Handle update attribute
        }
        else if (event.triggerSource == 'CustomSMSSender_VerifyUserAttribute') {
            // Handle verify attribute
        }
        else if (event.triggerSource == 'CustomSMSSender_AdminCreateUser') {
            // Handle admin create user
        }
        return;
    } catch (error) {
        console.error('Error in custom SMS sender:', error);
        throw error;
    }
};
```

**Topics**
+ [カスタム SMS 送信者の Lambda トリガーのソース](#trigger-source)
+ [カスタム SMS 送信者の Lambda トリガーパラメータ](#custom-sms-sender-parameters)
+ [コード例](#custom-sms-sender-code-examples)
+ [カスタム SMS 送信者関数で SMS メッセージ機能を評価する](#sms-to-email-example)

## カスタム SMS 送信者関数で SMS メッセージ機能を評価する
<a name="sms-to-email-example"></a>

カスタム SMS 送信者 Lambda 関数は、ユーザープールが送信する SMS メッセージを受け入れ、関数はカスタムロジックに基づいてコンテンツを配信します。Amazon Cognito は関数に [カスタム SMS 送信者の Lambda トリガーパラメータ](#custom-sms-sender-parameters) を送信します。この情報を使用して、関数はユーザーが望むことを実行できます。例えば、Amazon Simple Notification Service (Amazon SNS) トピックにコードを送信できます。Amazon SNS トピックのサブスクライバーは、SMS メッセージ、HTTPS エンドポイント、または E メールアドレスです。

カスタム SMS 送信者 Lambda 関数を使用して Amazon Cognito SMS メッセージングのテスト環境を作成するには、[GitHub 上の aws-samples ライブラリ](https://github.com/aws-samples)の「[amazon-cognito-user-pool-development-and-testing-with-sms-redirected-to-email](https://github.com/aws-samples/amazon-cognito-user-pool-development-and-testing-with-sms-redirected-to-email)」を参照してください。リポジトリには、新しいユーザープールを作成したり、既に持っているユーザープールを操作したりできる AWS CloudFormation テンプレートが含まれています。これらのテンプレートでは、Lambda 関数と Amazon SNS トピックが作成されます。テンプレートがカスタム SMS 送信者トリガーとして割り当てる Lambda 関数は、SMS メッセージを Amazon SNS トピックのサブスクライバーにリダイレクトします。

このソリューションをユーザープールにデプロイすると、Amazon Cognito が通常送信するすべてのメッセージが SMS メッセージングを介して送信され、代わりに Lambda 関数が中央の E メールアドレスに送信します。このソリューションを使用して、SMS メッセージをカスタマイズおよびプレビューし、Amazon Cognito が SMS メッセージを送信する原因となるユーザープールイベントをテストします。テストが完了したら、CloudFormation スタックをロールバックするか、ユーザープールからカスタム SMS 送信者関数の割り当てを削除します。

**重要**  
[amazon-cognito-user-pool-development-and-testing-with-sms-redirected-to-email](https://github.com/aws-samples/amazon-cognito-user-pool-development-and-testing-with-sms-redirected-to-email) のテンプレートは使用して、本番環境を構築しないでください。ソリューション内のカスタム SMS 送信者 Lambda 関数は SMS メッセージを*シミュレートします*が、Lambda 関数はそれらすべてを単一の中央の E メールアドレスに送信します。本番環境の Amazon Cognito ユーザープールで SMS メッセージを送信する前に、[Amazon Cognito ユーザープール用の SMS メッセージ設定](user-pool-sms-settings.md) に示す要件を満たす必要があります。

# ユーザープール内のユーザーを管理する
<a name="managing-users"></a>

ユーザープールを作成した後で、ユーザーアカウントの作成、確認、および管理を行うことができます。Amazon Cognito グループでは、IAM ロールをグループにマップすることによって、ユーザーと、ユーザーのリソースへのアクセスを管理できます。

Amazon Cognito ユーザープール内のユーザーを管理するには、さまざまな設定オプションと管理タスクが必要です。ユーザープールは数百万のユーザーにスケールできます。このスケールのユーザーディレクトリには、それと同様にスケーラブルで反復可能な管理ツールが必要です。多数のユーザープロファイルの作成、非アクティブなユーザーの管理、ガバナンスやコンプライアンスのレポート作成、ほとんどの作業をユーザーが行うセルフサービスツールの設定が必要になります。ユーザープールを作成したら、E メールや電話番号の検証を要求するなど、ユーザーのサインアップ方法とアカウントの確認方法を制御できます。また、管理者は、ユーザーアカウントの直接作成や、ウェルカムメッセージとパスワードの要件のカスタマイズもできます。

ユーザープールには、ユーザーのグループメンバーシップに基づいてリソースへのアクセスを管理できるユーザーグループが含まれます。これらのグループに IAM ロールを割り当てて、アイデンティティプールを使用して AWS のサービス へのアクセスを管理できます。ユーザーのグループメンバーシップは、ID トークンとアクセストークンの両方に存在します。この情報を使用して、アプリケーション内で、または Amazon Verified Permissions などのポリシーエンジンを用いて、実行時にアクセスコントロールを決定できます。

ユーザープールに多数のユーザーが含まれていることがよくあります。ユーザーアカウントを検索して更新する作業が多くなります。Amazon Cognito コンソールと API は、ユーザー名、E メール、電話番号などの標準属性に基づくユーザーのクエリをサポートします。管理者は、パスワードのリセット、アカウントの無効化、ユーザーイベント履歴の表示を行うこともできます。

既存のユーザーデータの移行については、Amazon Cognito には、CSV ファイルからユーザーをインポートするオプションや、ユーザーが初めてサインインしたときに [Lambda トリガー](user-pool-lambda-migrate-user.md)を使用してユーザーを自動的に移行させるオプションがあります。これらのオプションは、他のユーザーディレクトリからユーザープールへのユーザー移行をサポートします。

ユーザープールのユーザー管理機能を使用して、ユーザーライフサイクルと認証エクスペリエンスをきめ細かく制御できます。セルフサービスサインアップ、管理者が作成したアカウント、グループ、移行ツールを組み合わせて活用することで、Amazon Cognito ユーザープールは柔軟なユーザーディレクトリになります。

**Topics**
+ [ユーザー作成ポリシーの設定](user-pool-settings-admin-create-user-policy.md)
+ [ユーザーアカウントのサインアップと確認](signing-up-users-in-your-app.md)
+ [管理者としてのユーザーアカウントの作成](how-to-create-user-accounts.md)
+ [ユーザープールにグループを追加する](cognito-user-pools-user-groups.md)
+ [ユーザーアカウントの管理と検索](how-to-manage-user-accounts.md)
+ [パスワード、アカウント復旧、パスワードポリシー](managing-users-passwords.md)
+ [ユーザープールへのユーザーのインポート](cognito-user-pools-import-users.md)
+ [ユーザー属性の操作](user-pool-settings-attributes.md)

# ユーザー作成ポリシーの設定
<a name="user-pool-settings-admin-create-user-policy"></a>

ユーザープールでは、ユーザーにサインアップを許可するか、ユーザーを管理者として作成できます。また、サインアップ後の検証と確認のプロセスを、どの程度ユーザーに委ねるかを制御できます。例えば、サインアップを確認して、外部の検証プロセスに基づいてサインアップを承認できます。この設定 (管理者作成ユーザーポリシー) では、ユーザーが自分のユーザーアカウントを確認できなくなるまでの時間も設定します。**

Amazon Cognito は、ソフトウェアのカスタマー ID およびアクセス管理 (CIAM) プラットフォームとして、一般顧客のニーズに応えることができます。サインアップを受け入れてアプリケーションクライアントを持っているユーザープールは、マネージドログインの有無にかかわらず、パブリックに検出可能なアプリクライアント ID を知っていてサインアップをリクエストするインターネット上のすべてのユーザーに対して、ユーザープロファイルを作成します。サインアップしたユーザープロファイルは、アクセストークンと ID トークンを受け取り、アプリケーション用に承認されたリソースにアクセスできます。ユーザープールでサインアップを有効にする前に、オプションを確認し、設定がセキュリティ基準に準拠していることを確認してください。**[自己登録を有効化]** と `AllowAdminCreateUserOnly` を、以下の手順で説明するように注意して設定します。

------
#### [ AWS マネジメントコンソール ]

ユーザープールの **[サインアップ]** メニューには、ユーザープール内のユーザーのサインアップと管理者による作成に関する設定の一部が含まれています。

**サインアップエクスペリエンスを設定するには**

1. **[Cognito による検証と確認]** で、**[Cognito が検証と確認のためのメッセージを自動的に送信することを許可]** するかどうかを選択します。この設定を有効にすると、Amazon Cognito はユーザープールに提示する必要があるコードを含む E メールまたは SMS メッセージを新規ユーザーに送信します。これにより、E メールアドレスまたは電話番号の所有権が確認され、同等の属性が検証済みとして設定され、ユーザーアカウントのサインインが確認されます。選択した **[検証する属性]** により、検証メッセージの配信方法と送信先が決まります。

1. **[属性変更の確認]** は、ユーザーの作成時には重要ではありませんが、属性の検証に関係します。[[サインイン属性]](user-pool-settings-attributes.md#user-pool-settings-aliases.title) を変更したが、まだ検証していないユーザーに対して、新しい属性値または元の属性値を使用して引き続きサインインすることを許可できます。詳細については、「[ユーザーが E メールまたは電話番号を変更するときに確認する](signing-up-users-in-your-app.md#verifying-when-users-change-their-email-or-phone-number)」を参照してください。

1. **[必須の属性]** には、ユーザーのサインアップやユーザーの作成前に値を指定する必要がある属性が表示されます。必須属性は、ユーザープールの作成時にのみ設定できます。

1. **カスタム属性**は、ユーザーの作成とサインアップのプロセスにとって重要です。イミュータブルなカスタム属性の値を設定できるのは、ユーザーの初回作成時のみであるためです。**カスタム属性の詳細については、「[カスタム属性](user-pool-settings-attributes.md#user-pool-settings-custom-attributes)」を参照してください。

1. [認証されていない](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pools-API-operations.html#user-pool-apis-auth-unauth) `SignUp` API を使用して新しいアカウントを生成することをユーザーに許可する場合は、**[セルフサービスのサインアップ]** で、**[自己登録を有効化]** を設定します。自己登録を無効にした場合は、Amazon Cognito コンソールまたは [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html) API リクエストで新しいユーザーを管理者としてのみ作成できます。自己登録が非アクティブなユーザープールでは、[SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) API リクエストが `NotAuthorizedException` を返し、マネージドログインに **[サインアップ]** リンクが表示されません。

管理者としてユーザーを作成する予定のユーザープールでは、**[認証方法]** メニューの **[管理者が設定した仮パスワードの有効期限]** で仮パスワードの有効期間を設定できます。

管理者としてのユーザーを作成する場合の別の重要な要素は、招待メッセージです。新しいユーザーを作成すると、Amazon Cognito はアプリへのリンクを含むメッセージをユーザーに送信し、初回のサインインができるようにします。このメッセージテンプレートを **[認証方法]** メニューの **[メッセージテンプレート]** でカスタマイズします。

[[機密アプリクライアント]](user-pool-settings-client-apps.md#user-pool-settings-client-app-client-types.title) (通常はウェブアプリケーション) には、アプリクライアントシークレットがないとサインアップできないようにするクライアントシークレットを設定できます。セキュリティ上のベストプラクティスとして、パブリックアプリクライアント (通常はモバイルアプリ) にはアプリクライアントシークレットを配布しないでください。クライアントシークレットを持つアプリケーションクライアントは、Amazon Cognito コンソールの **[アプリケーションクライアント]** メニューで作成できます。

------
#### [ Amazon Cognito user pools API ]

ユーザープールのユーザーを作成するためのパラメータは、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) または [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストを使用してプログラムで設定できます。

[AdminCreateUserConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-AdminCreateUserConfig) 要素は、ユーザープールの以下のプロパティの値を設定します。

1. セルフサービスのサインアップの有効化

1. 管理者が新規作成したユーザーに送信する招待メッセージ

次の例を API リクエスト本文全体に追加すると、セルフサービスのサインアップが無効なユーザープールと、基本的な招待メールが設定されます。

```
"AdminCreateUserConfig": { 
      "AllowAdminCreateUserOnly": true,
      "InviteMessageTemplate": { 
         "EmailMessage": "Your username is {username} and temporary password is {####}.",
         "EmailSubject": "Welcome to ExampleApp",
         "SMSMessage": "Your username is {username} and temporary password is {####}."
      }
   }
```

[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) または [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストの以下の追加パラメータは、新規ユーザーの作成を制御します。

[AutoVerifiedAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-AutoVerifiedAttributes)  
新しいユーザーを登録するときに[自動的にメッセージを送信](user-pool-settings-email-phone-verification.md#user-pool-settings-email-phone-verification.title)する先の属性、メールアドレス、または電話番号。

[ポリシー](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-Policies)  
ユーザープールの[パスワードポリシー](managing-users-passwords.md#user-pool-settings-policies.title)。

[Schema](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-Schema)  
ユーザープールの[カスタム属性](user-pool-settings-attributes.md#user-pool-settings-custom-attributes.title)。イミュータブルなカスタム属性の値を設定できるのはユーザーの初回作成時のみであるため、カスタム属性はユーザーの作成とサインアップのプロセスにとって重要です。**  
このパラメータでは、ユーザープールの必須の属性も設定します。次のテキストを API リクエスト本文全体の `Schema` 要素に挿入すると、`email` 属性が必要に応じて設定されます。  

```
{
            "Name": "email",
            "Required": true
}
```

------

# ユーザーアカウントのサインアップと確認
<a name="signing-up-users-in-your-app"></a>

ユーザーアカウントは次の方法の 1 つでユーザープールに追加されます。
+ ユーザーは、ユーザープールのクライアントアプリにサインアップします。これはモバイルまたはウェブアプリです。
+ ユーザープールにユーザーのアカウントをインポートできます。詳細については、「[CSV ファイルからユーザープールへのユーザーのインポート](cognito-user-pools-using-import-tool.md)」を参照してください。
+ ユーザープールにユーザーのアカウントを作成し、サインインへユーザーを招待することができます。詳細については、「[管理者としてのユーザーアカウントの作成](how-to-create-user-accounts.md)」を参照してください。

サインアップするユーザーは、サインインする前に確認が求められます。インポートされ作成されたユーザーはすでに確認されていますが、初めてサインインするときはパスワードを作成する必要があります。以下のセクションで、確認プロセス、E メール、電話確認について説明します。

**サインアップ時のパスワード**  
Amazon Cognito では、以下の条件を除き、サインアップ時にすべてのユーザーにパスワードの入力を求めます。以下の条件を*すべて*満たしている場合は、サインアップオペレーションでパスワードを省略できます。

1. [[パスワードなしのサインイン]](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless) がユーザープールとアプリケーションクライアントでアクティブになっている。

1. アプリケーションは AWS SDK の認証モジュールを使用してカスタムビルドされます。マネージドログインとホストされた UI には、常にパスワードが必要です。

1. ユーザーが、許可されたパスワードなしのサインイン方法 (E メールまたは SMS メッセージのワンタイムパスワード (OTP) など) の属性値を指定している。例えば、E メールと電話の OTP によるサインインが許可されている場合、ユーザーは電話番号または E メールアドレスを指定できますが、E メールによるサインインのみが許可されている場合は、E メールアドレスを指定する必要があります。

1. ユーザープールが、パスワードなしのサインインでユーザーが使用できる属性を[自動的に検証](#allowing-users-to-sign-up-and-confirm-themselves)する。

1. どの [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) リクエストでも、ユーザーは [Password](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html#CognitoUserPools-SignUp-request-Password) パラメータの値を指定しない。

## ユーザーアカウント確認の概要
<a name="signup-confirmation-verification-overview"></a>

次の図は確認プロセスを示しています。

![\[ユーザーが確認コードを入力すると、自動的に E メールまたは電話を確認します。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/amazon-cognito-sign-in-confirm-user.png)


ユーザーアカウントは、以下のいずれかの状態になります。

**登録済み (未確認)**  
ユーザーは正常にサインアップできますが、ユーザーアカウントを確認するまではサインインできません。ユーザーは有効ですが、この状態で確認されていません。  
サインアップする新しいユーザーはこの状態から開始します。

**確認済み**  
ユーザーアカウントが確認され、ユーザーはサインインできます。ユーザーがユーザーアカウントを確認するためにコードを入力したり、E メールのリンクをたどったりすると、その E メールや電話番号が自動的に認証されます。コードまたはリンクは 24 時間有効です。  
ユーザーアカウントが管理者またはサインアップ前の Lambda トリガーによって確認された場合は、検証済みの E メールまたは電話番号がアカウントに関連付けられていないことがあります。

**パスワードのリセットが必要**  
ユーザーアカウントは確認されましたが、ユーザーはサインインする前にコードをリクエストし、自身のパスワードをリセットする必要があります。  
管理者またはデベロッパーがインポートしたユーザーアカウントは、この状態から開始します。

**パスワードの強制変更**  
ユーザーアカウントが確認され、ユーザーは一時パスワードを使用してサインインできますが、初回のサインイン時に他の操作を行う前にパスワードを新しい値に変更する必要があります。  
管理者またはデベロッパーが作成したユーザーアカウントは、この状態から開始します。

**Disabled**  
ユーザーアカウントを削除する前に、そのユーザーのサインインアクセスを無効にする必要があります。

**その他のリソース**
+ [Amazon Cognito による非アクティブなユーザーアカウントの検出と修正](https://aws.amazon.com/blogs/security/detecting-and-remediating-inactive-user-accounts-with-amazon-cognito/)

## サインアップ時に連絡先情報を検証する
<a name="allowing-users-to-sign-up-and-confirm-themselves"></a>

新しいユーザーがアプリにサインアップする際、1 つ以上の連絡先の入力を求める必要があります。たとえば、ユーザーの連絡先情報は、以下のように使用されます。
+ ユーザーが自分のパスワードをリセットする際、仮パスワードを送信する。
+ ユーザーの個人情報または財務情報が更新された際に通知する。
+ プロモーションメッセージ (特価販売や割引など) を送信する。
+ アカウントの概要または請求日のお知らせを送信する。

このようなユースケースでは、検証済みの送信先にメッセージを送信することが重要です。そうしないと、誤入力された無効な E メールアドレスまたは電話番号にメッセージが送信される可能性があります。さらに悪いケースでは、ユーザーを騙る悪人に機密情報が送信される可能性があります。

適切なユーザーにのみメッセージが送信されることを確実にするには、サインアップ時にユーザーが以下の情報を入力することを必須とするように Amazon Cognito ユーザープールを設定します。

1. E メールアドレスおよび電話番号。

1. Amazon Cognito がその E メールアドレスまたは電話番号に送信する検証コード。24 時間が経過し、ユーザーのコードまたはリンクが有効でなくなった場合は、[ResendConfirmationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html) API オペレーションを呼び出して、新しいコードまたはリンクを生成して送信します。

検証コードを入力することで、コードを受信したメールボックスまたは電話へのアクセス権があるユーザーであることが証明されます。ユーザーがコードを入力すると、Amazon Cognito が以下を行うことによってユーザープールのユーザーに関する情報を更新します。
+ ユーザーのステータスを `CONFIRMED` に設定する。
+ ユーザーの属性を更新し、E メールアドレスまたは電話番号が検証されていることを示す。

この情報は、Amazon Cognito コンソールを使用して表示できます。または、 `AdminGetUser` API オペレーション、 で `admin-get-user` コマンド AWS CLI、またはいずれかの AWS SDKs で対応するアクションを使用できます。

ユーザーに検証済みの連絡方法がある場合は、ユーザーがパスワードリセットをリクエストする時に、Amazon Cognito が自動的にメッセージをユーザーに送信します。

### ユーザー属性を確認および検証するその他のアクション
<a name="allowing-users-to-sign-up-and-confirm-themselves-other-actions"></a>

次のユーザーアクティビティでは、ユーザー属性を検証します。これらの属性を自動的に検証するように設定する必要はありません。リストされたアクションは、すべてのケースで属性を検証済みとしてマークします。

**E メールアドレス**  

1. E メールのワンタイムパスワード (OTP) を使用した[パスワードなしの認証](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless)が正常に完了しました。

1. E メール OTP を使用した[多要素認証 (MFA)](user-pool-settings-mfa.md) が正常に完了しました。

**Phone number (電話番号)**  

1. SMS OTP を使用した[パスワードなしの認証](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless)が正常に完了しました。

1. SMS OTP を使用した [MFA](user-pool-settings-mfa.md) が正常に完了しました。

### E メールまたは電話による検証を求めるようにユーザープールを設定するには
<a name="verification-configure"></a>

ユーザーの E メールアドレスと電話番号を確認することで、ユーザーに連絡できることを確認します。の次の手順を実行して AWS マネジメントコンソール 、ユーザーが E メールアドレスまたは電話番号を確認するようにユーザープールを設定します。

**注記**  
アカウントにまだユーザープールがない場合は、「[ユーザープールの開始方法](getting-started-user-pools.md)」を参照してください。

**ユーザープールを設定するには**

1. [Amazon Cognitoコンソール](https://console.aws.amazon.com/cognito/home) に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. ナビゲーションペインで、**[User Pools]** (ユーザープール) を選択します。リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[サインアップ]** メニューを選択し、**[属性の検証とユーザーアカウントの確認]** を見つけます。**[編集]** を選択します。

1. **[Cognito による検証と確認]** で、**[Cognito が検証と確認のためのメッセージを自動的に送信することを許可]** するかどうかを選択します。この設定を有効にすると、Amazon Cognito は、ユーザーのサインアップ時またはユーザープロファイルの作成時に選択したユーザー連絡先属性にメッセージを送信します。サインイン用の属性を検証し、ユーザープロファイルを確認するために、Amazon Cognito はコードまたはリンクをメッセージでユーザーに送信します。次に、ユーザーは UI にコードを入力し、アプリが `ConfirmSignUp` または `AdminConfirmSignUp` API リクエストで確認できるようにする必要があります。
**注記**  
**[Cognito-assisted verification and confirmation]** (Cognito アシストの検証と確認) を無効にして、API アクションまたは Lambda トリガーを使用して属性を検証し、ユーザーを確認することもできます。  
このオプションを選択すると、Amazon Cognito はユーザーのサインアップ時に検証コードを送信しません。このオプションは、Amazon Cognito からの検証コードを使用せずに、少なくとも 1 つの連絡方法を検証するカスタムの認証フローを使用している場合に選択します。例えば、特定のドメインに属する E メールアドレスを自動的に確認するサインアップ前 Lambda トリガーを使用することができます。  
ユーザーの連絡先情報を検証しない場合は、アプリケーションを使用できない場合があります。以下を行うには、ユーザーの連絡情報の検証が必要となる点にご注意ください。  
**[Reset their passwords]** (パスワードのリセット) — ユーザーが `ForgotPassword` API アクションを呼び出すオプションをアプリケーションで選択すると、Amazon Cognito はユーザーの E メールアドレスまたは電話番号に一時パスワードを送信します。Amazon Cognito がこのパスワードを送信するのは、ユーザーが検証済みの連絡方法を少なくとも 1 つ持っている場合のみです。
**[Sign in by using an email address or phone number as an alias]** (E メールアドレスまたは電話番号をエイリアスとして使用してサインインする) — これらのエイリアスを許可するようにユーザープールを設定した場合、ユーザーは、検証済みである場合にのみ、そのエイリアスを使用してサインインできます。詳細については、「[ログイン属性のカスタマイズ](user-pool-settings-attributes.md#user-pool-settings-aliases)」を参照してください。

1. **[Attributes to verify]** (検証する属性) を以下から選択します。  
**SMS メッセージを送信し、電話番号を確認する**  
ユーザーがサインアップすると Amazon Cognito が SMS メッセージで検証コードを送信します。通常 SMS メッセージでユーザーと通信する場合は、このオプションを選択してください。例えば、配信通知、予約確認、または警告を送信する場合は、検証済みの電話番号を使用します。アカウントが確認されると、ユーザーの電話番号が検証済み属性になります。ユーザーの E メールアドレスを確認して通信するには、追加のアクションを実行する必要があります。  
**E メールメッセージを送信し、E メールアドレスを確認する**  
ユーザーがサインアップすると Amazon Cognito が E メール経由で検証コードを送信します。通常 E メールでユーザーと通信する場合は、このオプションを選択してください。たとえば、請求明細、注文書、特価販売を使用する場合は、検証済みの E メールアドレスを使用する必要があります。アカウントが確認されると、ユーザーのメールアドレスが検証済み属性になります。ユーザーの電話番号を確認して通信するには、追加のアクションを実行する必要があります。  
**電話番号が利用可能な場合は SMS メッセージを送信し、そうでない場合は E メールメッセージを送信する**  
すべてのユーザーに同じ検証済みの連絡方法を要求する必要がない場合は、このオプションを選択してください。この場合、アプリのサインアップページで、希望する連絡方法のみを検証するようにユーザーに求めることができます。Amazon Cognito が検証コードを送信するときは、アプリからの `SignUp` リクエストで指定された連絡方法にコードが送信されます。ユーザーが E メールアドレスと電話番号の両方を入力し、アプリが `SignUp` リクエストに両方の連絡方法を指定する場合、Amazon Cognito は検証コードを電話番号のみに送信します。  
ユーザーが E メールアドレスと電話番号の両方を検証することを必須としている場合は、このオプションを選択してください。Amazon Cognito は、ユーザーのサインアップ時に 1 つの連絡方法を検証するので、アプリがユーザーのサインイン後にもう一方の連絡方法を検証する必要があります。詳細については、「[ユーザーに E メールアドレスと電話番号の両方の確認を要求する場合](#verification-email-plus-phone)」を参照してください。

1. **[Save changes]** (変更の保存) をクリックします。

### E メールアドレスまたは電話による検証を使用した認証フロー
<a name="verification-flow"></a>

ユーザープールで連絡先情報の検証をユーザーに要求する場合、ユーザーがアプリにサインアップした後のフローを容易にする必要があります。

1. ユーザーは、ユーザー名、メールアドレス、電話番号やその他の属性を入力してアプリにサインアップします。

1. Amazon Cognito サービスは、アプリからサインアップリクエストを受け取ります。サインアップに必要なすべての属性がリクエストに含まれることを確認した後で、サービスはサインアッププロセスを完了し、確認コードをユーザーの電話 (SMS メッセージ) または E メールに送信します。コードは 24 時間有効です

1. サービスは、サインアップが完了しユーザーアカウントが確認保留であることを返します。応答には、確認コードの送信先に関する情報が含まれます。この時点でユーザーアカウントは未確認状態になり、ユーザーのメールアドレスと電話番号は未確認です。

1. アプリは、ユーザーに確認コードを入力するよう求めるメッセージを表示できます。ユーザーは、コードをすぐに入力する必要はありません。ただし、確認コードを入力するまでユーザーはサインインできません。

1. ユーザーがアプリに確認コードを入力します。

1. アプリは、Amazon Cognito サービスにコードを送信する [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html) を呼び出します。これは、コードを検証し、コードが正しい場合はユーザーのアカウントを確認済み状態に設定します。ユーザーアカウントが正常に確認されると、Amazon Cognito サービスが自動的に、E メールアドレスまたは電話番号を確認するために使用された属性を検証済みとしてマークします。この属性の値が変更されていない場合、ユーザーはそれを再度確認する必要はありません。

1. この時点で、ユーザーアカウントは確認済みの状態になっており、ユーザーはサインインできます。

### ユーザーに E メールアドレスと電話番号の両方の確認を要求する場合
<a name="verification-email-plus-phone"></a>

Amazon Cognito は、ユーザーのサインアップ時に 1 つの連絡方法しか検証しません。Amazon Cognito が E メールアドレスまたは電話番号のどちらを検証するかを選択する必要がある場合は、SMS メッセージ経由で検証コードを送信して電話番号を検証することを選択します。例えば、ユーザーが E メールアドレスと電話番号のいずれかを検証できるようにユーザープールを設定する場合、およびアプリがサインアップ時にこれら両方の属性を提供する場合、Amazon Cognito は電話番号のみを検証します。ユーザーが電話番号を検証したら、Amazon Cognito がユーザーのステータスを `CONFIRMED` に設定し、ユーザーはアプリにサインインできるようになります。

ユーザーがアプリにサインインした後、サインアップ時に検証されなかった連絡方法を検証するオプションを提示することができます。この 2 つ目の方法を検証するには、アプリで `VerifyUserAttribute` API アクションを呼び出します。このアクションには `AccessToken` パラメータが必要で、Amazon Cognito は認証されたユーザーにアクセストークンしか提供しないことに注意してください。したがって、2 つ目の連絡方法は、ユーザーがサインインした後にのみ検証できます。

E メールアドレスと電話番号の両方を検証するようにユーザーに求める場合は、以下のように行います。

1. E メールアドレスまたは電話番号を検証することをユーザーに許可するようにユーザープールを設定します。

1. アプリのサインアップフローで、E メールアドレスおよび電話番号の両方を入力するようユーザーに求めます。[https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) API アクションを呼び出し、`UserAttributes` パラメータの E メールアドレスおよび電話番号を指定します。この時点で、Amazon Cognito がユーザーの携帯電話に検証コードを送信します。

1. アプリのインターフェイスで、ユーザーが検証コードを入力する確認ページを提示します。ユーザーを確認するには、[https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html) API アクションを呼び出します。この時点で、ユーザーのステータスは `CONFIRMED` となり、ユーザーの電話番号は検証されますが、E メールアドレスはまだ検証されていません。

1. サインインページを提示し、ユーザーを認証するには、[https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API アクションを呼び出します。ユーザーが認証されると、Amazon Cognito がアプリにアクセストークンを返します。

1. [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserAttributeVerificationCode.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserAttributeVerificationCode.html) API アクションを呼び出します。リクエストで次のパラメータを指定します。
   + `AccessToken` – ユーザーのサインイン時に Amazon Cognito が返したアクセストークン。
   + `AttributeName` – `"email"` を属性値として指定します。

   Amazon Cognito がユーザーの E メールアドレスに検証コードを送信します。

1. ユーザーが検証コードを入力する確認ページを提示します。ユーザーがコードを入力したら、[https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifyUserAttribute.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifyUserAttribute.html) API アクションを呼び出します。リクエストで次のパラメータを指定します。
   + `AccessToken` – ユーザーのサインイン時に Amazon Cognito が返したアクセストークン。
   + `AttributeName` – `"email"` を属性値として指定します。
   + `Code` – ユーザーが提供した検証コード。

   この時点で、E メールアドレスが検証されます。

## ユーザーにアプリケーションへのサインアップを許可するがユーザープール管理者として確認する
<a name="signing-up-users-in-your-app-and-confirming-them-as-admin"></a>

ユーザープールで確認メッセージを自動的に送信しないにも関わらず、誰でもアカウントにサインアップできるようにしたい場合があります。このモデルでは、たとえば、新しい登録リクエストを人間が確認したり、サインアップの一括検証と処理を行ったりする余地があります。Amazon Cognito コンソール、または IAM 認証された API オペレーション [AdminConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminConfirmSignUp.html) を使用して新しいユーザーアカウントを確認できます。ユーザープールが確認メッセージを送信するかどうかにかかわらず、ユーザーアカウントを管理者として確認できます。

この方法では、ユーザーのセルフサービスサインアップを確認することしかできません。管理者として作成したユーザーを確認するには、`Permanent` を `True` に設定した [AdminSetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html) API リクエストを作成します。

1. ユーザーは、ユーザー名、メールアドレス、電話番号やその他の属性を入力してアプリにサインアップします。

1. Amazon Cognito サービスは、アプリからサインアップリクエストを受け取ります。サインアップに必要なすべての属性がリクエストに含まれることを確認した後で、サービスはサインアッププロセスを完了し、アプリにサインアップが完了し確認が保留中であることをアプリに返します。この時点でユーザーのアカウントは未確認状態です。アカウントが確認されるまで、ユーザーはサインインすることはできません。

1. ユーザーのアカウントを確認します。アカウントを確認するには、 にサインイン AWS マネジメントコンソール するか、 AWS 認証情報を使用して API リクエストに署名する必要があります。

   1. Amazon Cognito コンソールでユーザーを確認するには、**[ユーザー]** メニューに移動して、確認するユーザーを選択し、**[アクション]** メニューの **[確認]** を選択します。

   1.  AWS API または CLI でユーザーを確認するには、[AdminConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminConfirmSignUp.html) API リクエストを作成するか、 で [admin-confirm-sign-up](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/admin-confirm-sign-up.html) を作成します AWS CLI。

1. この時点で、ユーザーアカウントは確認済みの状態になっており、ユーザーはサインインできます。

## シークレットハッシュ 値の計算
<a name="cognito-user-pools-computing-secret-hash"></a>

ベストプラクティスとして、機密アプリケーションクライアントにクライアントシークレットを割り当てます。アプリケーションクライアントにクライアントシークレットを割り当てる場合、Amazon Cognito ユーザープール API リクエストには、リクエスト本文にクライアントシークレットを含むハッシュを含める必要があります。以下のリストにある API オペレーションのクライアントシークレットに関する知識を検証するには、クライアントシークレットをアプリケーションのクライアント ID とユーザーのユーザー名と連結し、その文字列を base64 でエンコードします。

シークレットハッシュを持つクライアントにアプリがユーザーをサインインすると、ユーザープールのサインイン属性の値をシークレットハッシュのユーザー名要素として使用できます。アプリが `REFRESH_TOKEN_AUTH` による認証オペレーションで新しいトークンをリクエストする場合、ユーザー名要素の値はサインイン属性によって異なります。ユーザープールにサインイン属性として `username` がない場合は、ユーザーのアクセストークンまたは ID トークンの `sub` クレームからのシークレットハッシュユーザー名の値を設定します。`username` がサインイン属性である場合は、`username` クレームからのシークレットハッシュユーザー名の値を設定します。

以下の Amazon Cognito ユーザープール API は、`SecretHash` パラメータにクライアントシークレットのハッシュ値を受け入れます。
+ [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html)
+ [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html)
+ [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html)
+ [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html)
+ [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html)

また、以下の API は、認証パラメータまたはチャレンジレスポンス内の `SECRET_HASH` パラメータにクライアントシークレットのハッシュ値を受け入れます。


| API オペレーション: | SECRET\$1HASH の親パラメータ | 
| --- |--- |
| InitiateAuth | AuthParameters | 
| AdminInitiateAuth | AuthParameters | 
| RespondToAuthChallenge | ChallengeResponses | 
| AdminRespondToAuthChallenge | ChallengeResponses | 

シークレットハッシュ値は、Base 64 でエンコードされたキー付きハッシュメッセージ認証コード (HMAC) であり、ユーザープールクライアントおよびユーザー名、さらにメッセージ内のクライアント ID を使用して計算されたものです。次の擬似コードは、この値の計算方法を示します。この擬似コードで `+` は連結を表し、`HMAC_SHA256` は HmacSHA256 を使用して HMAC 値を生成する関数を、`Base64` は Base-64 でエンコードされたバージョンのハッシュ出力を生成する関数を示します。

```
Base64 ( HMAC_SHA256 ( "Client Secret Key", "Username" + "Client Id" ) )
```

`SecretHash` パラメータの計算方法と使用方法の詳細な概要については、 AWS ナレッジセンターの[Amazon Cognito ユーザープール API からのクライアント <client-id> エラーのシークレットハッシュを検証できない」のトラブルシューティング方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/cognito-unable-to-verify-secret-hash/)

サーバー側の Java アプリケーションコードで、次のコード例を使用できます。

------
#### [ Shell ]

```
echo -n "[username][app client ID]" | openssl dgst -sha256 -hmac [app client secret] -binary | openssl enc -base64
```

------
#### [ Java ]

```
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
 
public static String calculateSecretHash(String userPoolClientId, String userPoolClientSecret, String userName) {
    final String HMAC_SHA256_ALGORITHM = "HmacSHA256";
    
    SecretKeySpec signingKey = new SecretKeySpec(
            userPoolClientSecret.getBytes(StandardCharsets.UTF_8),
            HMAC_SHA256_ALGORITHM);
    try {
        Mac mac = Mac.getInstance(HMAC_SHA256_ALGORITHM);
        mac.init(signingKey);
        mac.update(userName.getBytes(StandardCharsets.UTF_8));
        byte[] rawHmac = mac.doFinal(userPoolClientId.getBytes(StandardCharsets.UTF_8));
        return Base64.getEncoder().encodeToString(rawHmac);
    } catch (Exception e) {
        throw new RuntimeException("Error while calculating ");
    }
}
```

------
#### [ Python ]

```
import sys
import hmac, hashlib, base64 
username = sys.argv[1] 
app_client_id = sys.argv[2] 
key = sys.argv[3] 
message = bytes(sys.argv[1]+sys.argv[2],'utf-8') 
key = bytes(sys.argv[3],'utf-8') 
secret_hash = base64.b64encode(hmac.new(key, message, digestmod=hashlib.sha256).digest()).decode() 
print("SECRET HASH:",secret_hash)
```

------

## E メールまたは電話番号の確認なしでユーザーアカウントを確認する
<a name="confirming-user-without-verification-of-email-or-phone-number"></a>

検証コードを要求したり、E メールまたは電話番号を検証したりすることなくサインアップ時にユーザーアカウントを自動的に確認するには、サインアップ前の Lambda トリガーを使用できます。この方法で確認されたユーザーは、コードを受け取らないですぐにサインインできます。

このトリガーによって検証されたユーザーのメールまたは電話番号をマーキングすることもできます。

**注記**  
これはユーザーが始めるにあたって便利な方法ですが、E メールまたは電話番号を少なくとも 1 つ自動検証することをお勧めします。そうしないと、ユーザーがパスワードを忘れた際に復旧できないままになる場合があります。

ユーザーがサインアップ時に検証コードを受信して入力することを必須とせず、サインアップ前の Lambda トリガーで E メールと電話番号を自動検証しない場合は、そのユーザーアカウントに検証済みの E メールアドレスまたは電話番号が存在しないリスクが生じます。ユーザーはメールアドレスまたは電話番号を後で確認できます。ただし、パスワードを忘れて確認済みの E メールアドレスまたは電話番号がない場合、パスワードを忘れた場合のフローで検証コードをユーザーに送信するために確認済みの E メールまたは電話番号が必要となるため、ユーザーはアカウントからロックアウトされます。

## ユーザーが E メールまたは電話番号を変更するときに確認する
<a name="verifying-when-users-change-their-email-or-phone-number"></a>

複数のサインイン名で設定したユーザープールでは、ユーザーはサインイン時にユーザー名として電話番号または E メールアドレスを入力できます。アプリケーションで E メールアドレスまたは電話番号を更新すると、Amazon Cognito は新しい属性値の所有権を検証するコードを含むメッセージをすぐに送信できます。これらの検証コードの自動送信を有効にするには、「[E メールまたは電話による検証の設定](user-pool-settings-email-phone-verification.md)」を参照してください。

検証コードを受け取ったユーザーは、[VerifyUserAttribute](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifyUserAttribute.html) リクエストでそのコードを Amazon Cognito に返す必要があります。コードを返すと、その属性が検証済みとしてマークされます。通常、ユーザーが E メールアドレスまたは電話番号を更新した場合、更新した値を使用してサインインしてメッセージを受信する前に、ユーザーが更新した値の所有者であることを確認する必要があります。ユーザープールには、ユーザーが E メールアドレスや電話番号の更新を確認する必要があるかどうかを決定する設定可能なオプションがあります。

このオプションは、ユーザープールのプロパティ `AttributesRequireVerificationBeforeUpdate` です。これを設定するには、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-UserAttributeUpdateSettings) または [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html#CognitoUserPools-UpdateUserPool-request-UserAttributeUpdateSettings) リクエストを使用するか、Amazon Cognito コンソールの **[サインアップ]** メニューで **[更新が保留中のときに元の属性値をアクティブのままにする]** を使用します。

ユーザープールが E メールアドレスと電話番号の更新を処理する方法は、ユーザープールのユーザー名設定に関連しています。ユーザープールのユーザー名は、*[ユーザー名属性]* 設定に含めることができます。この設定では、E メールアドレス、電話番号、またはその両方がサインイン名となります。また、*[エイリアス属性]* 設定に含めることもできます。この設定では、`username` 属性がサインイン名となり、E メールアドレス、電話番号、または希望するユーザー名が代替サインイン名となります。詳細については、「[ログイン属性のカスタマイズ](user-pool-settings-attributes.md#user-pool-settings-aliases)」を参照してください。

 カスタムメッセージの Lambda トリガーを使用して確認メッセージをカスタマイズすることもできます。詳細については、「[カスタムメッセージの Lambda トリガー](user-pool-lambda-custom-message.md)」を参照してください。ユーザーの E メールアドレスや電話番号が未確認の場合、アプリケーションはユーザーに属性を確認する必要があることを通知し、新しい E メールアドレスや電話番号を確認するためのボタンやリンクを提供する必要があります。

次の表は、ユーザーがサインイン属性の値を変更したときに、`AttributesRequireVerificationBeforeUpdate` およびエイリアス設定でどのように結果を決定するかを示しています。


| ユーザー名の設定 | ユーザーが新しい属性を確認する必要がある場合の動作 | ユーザーが新しい属性を確認する必要がない場合の動作 | 
| --- | --- | --- | 
| ユーザー名属性 | 元の属性は、検証済みで、サインイン可能であり、元の値のままです。ユーザーが新しい値を確認すると、Amazon Cognito は属性値を更新し、検証済みとしてマークし、サインイン可能にします。 | Amazon Cognito は属性を新しい値に更新します。新しい値でサインイン可能になります。ユーザーが新しい値を確認すると、Amazon Cognito はそれを検証済みとしてマークします。 | 
| エイリアス属性 | 元の属性は、検証済みで、サインイン可能であり、元の値のままです。ユーザーが新しい値を確認すると、Amazon Cognito は属性値を更新し、検証済みとしてマークし、サインイン可能にします。 | Amazon Cognito は属性を新しい値に更新します。元の属性値でも新しい属性値でもサインインできません。ユーザーが新しい値を確認すると、Amazon Cognito は属性値を更新し、検証済みとしてマークし、サインイン可能にします。 | 

**例 1**  
ユーザー 1 は、E メールアドレス `user1@example.com` でアプリケーションにサインインし、ユーザー名 `user1` (エイリアス属性) を持っています。ユーザープールは、サインイン属性の更新を検証し、検証メッセージを自動的に送信するように設定されています。ユーザーは E メールアドレスを `user1+foo@example.com` に更新するようリクエストします。ユーザーは、確認 E メールを `user1+foo@example.com` で受け取り、E メールアドレス `user1@example.com` のみを使用して*再度サインインできます*。その後、確認コードを入力し、E メールアドレス `user1+foo@example.com` のみを使用して再度サインインできます。

**例 2**  
ユーザー 2 は、E メールアドレス `user2@example.com` を使用してアプリケーションにサインインし、ユーザー名 (エイリアス属性) を持っています。ユーザープールは、サインイン属性の更新を検証したり、検証メッセージを自動的に送信したり*しない*ように設定されています。ユーザーは E メールアドレスを `user2+bar@example.com` に更新するようリクエストします。ユーザーは `user2+bar@example.com` で確認 E メールを受け取り、*再度サインインすることはできません*。その後、確認コードを入力し、E メールアドレス `user2+bar@example.com` のみを使用して再度サインインできます。

**例 3**  
ユーザー 3 は、E メールアドレス `user3@example.com` を使用してアプリケーションにサインインします。ユーザー名 (ユーザー名属性) は持っていません。ユーザープールは、サインイン属性の更新を検証したり、検証メッセージを自動的に送信したり*しない*ように設定されています。ユーザーは E メールアドレスを `user3+baz@example.com` に更新するようリクエストします。ユーザーは確認 E メールを `user3+baz@example.com` で受け取りますが、検証コードで追加のアクションを実行することなく、*即座にサインインできます*。

## 管理者またはデベロッパーが作成するユーザーアカウントの確認および検証プロセス
<a name="confirmation-and-verification-of-users-whose-accounts-youve-created"></a>

管理者またはデベロッパーが作成したユーザーアカウントは常に確認済み状態にあるため、ユーザーは確認コードを入力する必要はありません。Amazon Cognito サービスがこれらのユーザーに送信する招待メッセージには、ユーザー名と一時パスワードが含まれています。ユーザーは、サインインする前にパスワードを変更する必要があります。詳細について、は、「[E メールメッセージと SMS メッセージのカスタマイズ](how-to-create-user-accounts.md#creating-a-new-user-customize-messages)」の「[管理者としてのユーザーアカウントの作成](how-to-create-user-accounts.md)」と「[Lambda トリガーを使用したユーザープールワークフローのカスタマイズ](cognito-user-pools-working-with-lambda-triggers.md)」のカスタムメッセージのトリガーを参照してください。

## インポート済みユーザーアカウントの確認および検証プロセス
<a name="confirmation-and-verification-of-users-whose-accounts-youve-imported"></a>

、CLI AWS マネジメントコンソール、または API のユーザーインポート機能を使用して作成されたユーザーアカウント (「」を参照[CSV ファイルからユーザープールへのユーザーのインポート](cognito-user-pools-using-import-tool.md)) は既に確認済み状態であるため、ユーザーは確認コードを入力する必要はありません。招待メッセージは送信されません。ただし、インポートされたユーザーアカウントでは、サインインする前にまず `ForgotPassword` API を呼び出してコードをリクエストし、次に、提供されたコードを使用して `ConfirmForgotPassword` API を呼び出すことによってパスワードを作成する必要があります。詳細については、「[インポートされたユーザーにパスワードをリセットするように要求](cognito-user-pools-using-import-tool.md#cognito-user-pools-using-import-tool-password-reset)」を参照してください。

ユーザーアカウントがインポートされたときに、ユーザーの E メールまたは電話番号は確認済みとしてマークする必要があります。したがって、ユーザーがサインインする際に認証は必要ありません。

## アプリケーションのテスト中に E メールを送信する
<a name="managing-users-accounts-email-testing"></a>

ユーザープールのクライアントアプリでアカウントを作成および管理する場合は、Amazon Cognito がユーザーに E メールメッセージを送信します。E メール検証を必須とするようにユーザープールを設定した場合は、以下のタイミングで Amazon Cognito が E メールを送信します。
+ ユーザーのサインアップ時。
+ ユーザーが E メールアドレスを更新する際。
+ ユーザーが `ForgotPassword` API アクションを呼び出すアクションを実行する際。
+ 管理者としてユーザーアカウントを作成する際。

E メールを開始するアクションに応じて、検証コードまたは仮パスワードが含まれます。ユーザーは、これらの E メールを受け取り、メッセージを理解する必要があります。そうしないと、アプリにサインインして使用できない場合があります。

E メールが正常に送信され、メッセージの内容が正しいことを確認するには、Amazon Cognito からの E メール配信を開始するアプリのアクションをテストします。たとえば、アプリでサインアップページを使用するか、`SignUp` API アクションを使用して、テスト用メールアドレスでサインアップすることで E メールを配信できます。この方法でテストする場合は、次の点に注意してください。

**[重要]**  
Amazon Cognito からの E メールを開始するアクションをテストするために E メールアドレスを使用する場合は、偽の E メールアドレス (メールボックスが存在しないメールアドレス) は使用しないでください。*ハードバウンス*を発生させずに Amazon Cognito からの E メールを受信する実際の E メールアドレスを使用します。  
ハードバウンスは、Amazon Cognito が受取人のメールボックスへの E メールの配信に失敗した場合に発生します。これは、常にメールボックスが存在しない場合に発生します。  
Amazon Cognito は、永続的にハードバウンスが発生する AWS アカウントによって送信できる E メールの数を制限します。

E メールを配信するアクションをテストする場合、次のいずれかの E メールアドレスを使用してハードバウンスを回避します。
+ テスト用に所有し、使用している E メールアカウントのメールアドレス。独自の E メールアドレスを使用すると、Amazon Cognito が送信する E メールを受け取ります。この E メールでは、検証コードを使用して、アプリのサインアップエクスペリエンスをテストできます。ユーザープールの E メールメッセージをカスタマイズした場合は、正しく表示されていることを確認します。
+ メールボックスシミュレーターのアドレス (*success@simulator.amazonses.com*)。シミュレーターのアドレスを使用する場合、Amazon Cognito は E メールを正常に送信しますが、それを表示することはできません。このオプションは、検証コードを使用する必要がなく、E メールのメッセージを確認する必要がない場合に役立ちます。
+ *success\$1user1@simulator.amazonses.com* または *success\$1user2@simulator.amazonses.com* などの、任意のラベルを使用するメールボックスシミュレーターのアドレス。Amazon Cognito はこれらのアドレスに E メールを正常に送信しますが、送信された E メールを表示することはできません。このオプションは、複数のテストユーザーをユーザープールに追加してサインアッププロセスをテストし、各テストユーザーに一意の E メールアドレスがある場合に便利です。

# E メールまたは電話による検証の設定
<a name="user-pool-settings-email-phone-verification"></a>

E メールまたは電話の検証の設定は、**[認証方法]** メニューで選択できます。多要素認証 (MFA) の詳細については、「[SMS テキストメッセージ MFA](user-pool-settings-mfa-sms-email-message.md)」を参照してください。

Amazon Cognito は、SMS メッセージの送信に Amazon SNS を使用します。Amazon Cognito または他の から SMS メッセージを送信したことがない場合 AWS のサービス 、Amazon SNS はアカウントを SMS サンドボックスに配置することがあります。アカウントをサンドボックスから本番環境に削除する前に、検証済みの電話番号にテストメッセージを送信することをお勧めします。さらに、米国の宛先電話番号に SMS メッセージを送信する場合は、Amazon Pinpoint から発信元 ID または送信者 ID を取得する必要があります。SMS メッセージ用に Amazon Cognito ユーザープールを設定するには、「[Amazon Cognito ユーザープール用の SMS メッセージ設定](user-pool-sms-settings.md)」を参照してください。

Amazon Cognito は、E メールアドレスまたは電話番号を自動的に検証できます。この検証を行うために、Amazon Cognito は検証コードまたは検証リンクを送信します。E メールアドレスの場合、Amazon Cognito は、コードまたはリンクを E メールメッセージで送信できます。Amazon Cognito コンソールの **[メッセージテンプレート]** メニューで **[検証メッセージ]** テンプレートを編集するときに、**[検証タイプ]** として **[コード]** または **[リンク]** を選択できます。詳細については、「[E メール検証メッセージのカスタマイズ](cognito-user-pool-settings-message-customizations.md#cognito-user-pool-settings-email-verification-message-customization)」を参照してください。

電話番号の場合、Amazon Cognito は、コードを SMS テキストメッセージで送信します。

Amazon Cognito は、ユーザーを確認し、パスワードを忘れた場合の回復を支援するために、電話番号または E メールアドレスを検証する必要があります。または、サインアップ前の Lambda トリガーまたは [AdminConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminConfirmSignUp.html) API オペレーションを使用することで、ユーザーを自動的に確認できます。詳細については、「[ユーザーアカウントのサインアップと確認](signing-up-users-in-your-app.md)」を参照してください。

確認コードまたはリンクは 24 時間有効です。

E メールアドレスや電話番号の検証を必須とした場合、Amazon Cognito はユーザーのサインアップ時に自動的に検証コードまたはリンクを送信します。ユーザープールに [カスタム SMS 送信者の Lambda トリガー](user-pool-lambda-custom-sms-sender.md) または [カスタム E メール送信者の Lambda トリガー](user-pool-lambda-custom-email-sender.md) を設定すると、その関数が代わりに呼び出されます。

**注意事項**  
電話番号の検証に SMS テキストメッセージングを使用すると、Amazon SNS の料金が別途請求されます。E メールメッセージを送信しても料金はかかりません。Amazon SNS の料金については、「[Worldwide SMS Pricing](https://aws.amazon.com/sns/sms-pricing/)」を参照してください。SMS メッセージを利用可能な国の最新のリストについては、「[サポートされるリージョンと国](https://docs.aws.amazon.com/sns/latest/dg/sms_supported-countries.html)」を参照してください。
Amazon Cognito からの E メールメッセージを生成するアプリ内のアクションをテストするときは、Amazon Cognito がハードバウンスを発生させずに送信できる実際の E メールアドレスを使用してください。詳細については、「[アプリケーションのテスト中に E メールを送信する](signing-up-users-in-your-app.md#managing-users-accounts-email-testing)」を参照してください。
パスワードを忘れた場合のフローでは、ユーザーのメールまたはユーザーの電話番号が検証される必要があります。

**重要**  
ユーザーが電話番号と E メールアドレスの両方にサインアップし、ユーザープール設定で両方の属性の確認が必要な場合は、Amazon Cognito は、検証コードを SMS メッセージ経由で電話番号に送信します。Amazon Cognito はまだ E メールアドレスを検証していないため、アプリは [GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) を呼び出して、E メールアドレスが検証待ちかどうかを確認する必要があります。検証が必要な場合、アプリは、[GetUserAttributeVerificationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserAttributeVerificationCode.html) を呼び出し、E メール検証フローを開始する必要があります。その後、[VerifyUserAttribute](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifyUserAttribute.html) を呼び出して検証コードを送信する必要があります。

 AWS アカウント および個々のメッセージの SMS メッセージの支出クォータを調整できます。制限は SMS メッセージを送信するコストにのみ適用されます。詳細については、[Amazon SNS よくある質問](https://aws.amazon.com/sns/faqs/)の「**アカウントレベルとメッセージレベルの支出クォータとは何ですか。また、どのように機能しますか。**」を参照してください。

Amazon Cognito は、ユーザープールを作成した AWS リージョン または次の表のレガシー Amazon SNS 代替リージョンのいずれかで、Amazon SNS リソースを使用して SMS メッセージを送信します。 ** Amazon SNS ** 例外は、アジアパシフィック (ソウル) リージョンの Amazon Cognito ユーザープールです。これらのユーザープールは、アジアパシフィック (東京) リージョンで Amazon SNS 設定を使用します。詳細については、「[SMS メッセージの AWS リージョン を選択する](user-pool-sms-settings.md#sms-choose-a-region)」を参照してください。


| Amazon Cognito リージョン | レガシー Amazon SNS 代替リージョン | 
| --- | --- | 
| 米国東部(オハイオ) | 米国東部 (バージニア北部) | 
| アジアパシフィック (ムンバイ) | アジアパシフィック (シンガポール) | 
| アジアパシフィック (ソウル) | アジアパシフィック (東京) | 
| カナダ (中部) | 米国東部 (バージニア北部) | 
| 欧州 (フランクフルト) | 欧州 (アイルランド) | 
| 欧州 (ロンドン) | 欧州 (アイルランド) | 

**例: **Amazon Cognito のユーザープールがアジアパシフィック (ムンバイ) にあり、ap-southeast-1 で使用制限を引き上げている場合は、ap-south-1 で別途引き上げる要求をしないでください。代わりに、アジアパシフィック (シンガポール) で Amazon SNS リソースを使用できます。

## E メールアドレスと電話番号の更新を検証する
<a name="user-pool-settings-verifications-verify-attribute-updates"></a>

E メールアドレスまたは電話番号の属性は、ユーザーが値を変更した直後にアクティブになり、検証されない場合があります。Amazon Cognito は、Amazon Cognito が属性を更新する前に、ユーザーに新しい値を検証するように要求することもできます。ユーザーが新しい値を最初に検証することを要求する場合、新しい値を検証するまでは、サインインおよびメッセージの受信に元の値を使用することができます。

ユーザーがユーザープールの E メールアドレスまたは電話番号をサインインエイリアスとして使用できる場合、更新された属性のサインイン名は、更新された属性の検証が必要かどうかによって異なります。更新された属性を検証する必要がある場合、新しい値を検証するまで、ユーザーは元の属性値を使用してサインインできます。更新された属性を検証する必要がない場合、新しい値を検証するまで、ユーザーは新しい属性値または元の属性値でサインインまたはメッセージを受信することはできません。

例えば、ユーザープールでは、E メールアドレスのエイリアスでのサインインが許可され、ユーザーが更新時に E メールアドレスを検証する必要があるとします。`sue@example.com` としてサインインしている Sue は、自分の E メールアドレスを `sue2@example.com` に変更しようとしましたが、誤って `ssue2@example.com` と入力してしまいました。Sue は確認用の E メールを受信していないので、`ssue2@example.com` を検証することができません。`sue@example.com` としてサインインし、アプリでフォームを再送信して、E メールアドレスを `sue2@example.com` に更新します。この E メールを受信し、アプリに確認コードを提供して、`sue2@example.com` としてサインインを開始します。

**ユーザーが属性を更新し、ユーザープールが新しい属性値を検証する場合**
+ コードを確認する前は、元の属性値でサインインして新しい値を確認できます。
+ コードを確認した後は、新規の属性値でサインインして新しい値を確認できます。
+ [AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) API  リクエストで `email_verified` または `phone_number_verified` を `true` に設定すると、Amazon Cognito から送信されたコードを確認する前にサインインできるようになります。

**ユーザーが属性を更新し、ユーザープールが新しい属性値を検証しない場合**
+ 元の属性値を使用してサインインしたり、元の属性値でメッセージを受信したりすることはできません。
+ 新しい値を確認するコードを確認するま、新しい属性値を使用してサインインしたり、確認コード以外のメッセージを受信したりすることはできません。
+ [AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) API  リクエストで `email_verified` または `phone_number_verified` を `true` に設定すると、Amazon Cognito から送信されたコードを確認する前にサインインできるようになります。

## ユーザーが E メールアドレスまたは電話番号を更新するときに属性の検証を要求するには


1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)にサインインします。プロンプトが表示されたら、 AWS 認証情報を入力します。

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

1. **[サインアップ]** メニューで、**[属性の検証とユーザーアカウントの確認]** の **[編集]** を選択します。

1. **[Keep original attribute value active when an update is pending]** (更新が保留中の場合、元の属性値をアクティブに保つ) を選択します。

1. **[Active attribute values when an update is pending]** (更新が保留中の場合にアクティブな属性値) から、Amazon Cognito が値を更新する前にユーザーに検証を要求する属性を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

Amazon Cognito API で属性更新の検証を要求するには、[UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) リクエストで `AttributesRequireVerificationBeforeUpdate` パラメータを設定します。

## SMS メッセージを代理送信するために Amazon Cognito を承認します。
<a name="user-pool-settings-verifications-iam-role-for-sms"></a>

SMS メッセージをユーザーに代理送信するには、Amazon Cognito に許可が必要です。そのアクセス許可を付与するには、 AWS Identity and Access Management (IAM) ロールを作成します。Amazon Cognito コンソールの **[認証方法]** メニューの [SMS] で、**[編集]** を選択してロールを設定します。

# MFA、認証、検証、招待メッセージの設定
<a name="cognito-user-pool-settings-message-customizations"></a>

Amazon Cognito を使用すると、SMS や E メールの認証、検証、およびユーザー招待メッセージをカスタマイズして、アプリケーションのセキュリティとユーザーエクスペリエンスを強化できます。一部のメッセージでは、コードベースの検証またはワンクリックリンクによる検証を選択できます。このトピックでは、Amazon Cognito コンソールで認証と検証の通信をパーソナライズする方法について説明します。

**[メッセージテンプレート]** メニューで、以下をカスタマイズできます。
+ ワンタイムパスワード (OTP) と多要素認証 (MFA) 用の E メールおよび SMS メッセージテンプレート
+ SMS と E メールの検証メッセージ
+ E メールの検証タイプ (コードまたはリンク)
**注記**  
Amazon Cognito は、ユーザーがサインアップまたは確認コードを再送信するときに、リンクとリンクベースのテンプレートを含む検証メッセージを送信します。コードテンプレートは、属性の更新オペレーションとパスワードのリセットオペレーションに関連する E メールで使用します。
+ ユーザーの招待メッセージ
+ ユーザープールを介するメールの FROM および REPLY-TO E メールアドレス

**注記**  
SMS と E メールの検証メッセージテンプレートは、電話番号と E メールの検証を必須にした場合にのみ表示されます。同様に、SMS MFA メッセージのテンプレートは、MFA 設定が **[required]** (必要) または **[optional]** (任意) の場合にのみ表示されます。

**Topics**
+ [メッセージテンプレート](#cognito-user-pool-settings-message-templates)
+ [E メールと SMS の MFA メッセージのカスタマイズ](#cognito-user-pool-settings-SMS-message-customization)
+ [E メール検証メッセージのカスタマイズ](#cognito-user-pool-settings-email-verification-message-customization)
+ [ユーザー招待メッセージのカスタマイズ](#cognito-user-pool-settings-user-invitation-message-customization)
+ [E メールアドレスのカスタマイズ](#cognito-user-pool-settings-email-address-customization)
+ [Amazon SES E メールを代理送信するための Amazon Cognito の承認 (カスタム REPLY-TO E メールアドレスからの送信)](#cognito-user-pool-settings-ses-authorization-to-send-email)

## メッセージテンプレート
<a name="cognito-user-pool-settings-message-templates"></a>

メッセージテンプレートを使用して、メッセージにプレースホルダーを挿入できます。Amazon Cognito はプレースホルダーを、対応する値に置き換えます。これらの値はすべてのメッセージタイプに存在するわけではありませんが、任意のタイプのメッセージテンプレートで*ユニバーサルテンプレートプレースホルダー*を参照できます。


**ユニバーサルテンプレートプレースホルダー**  

|  説明  |  トークン  | メッセージタイプ | 
| --- | --- | --- | 
| 検証コード | \$1\$1\$1\$1\$1\$1 | 検証、確認、MFA メッセージ | 
| 一時パスワード | \$1\$1\$1\$1\$1\$1 | パスワードを忘れた場合と招待メッセージ | 
| ユーザー名 | \$1username\$1 | 招待メッセージと高度なセキュリティメッセージ | 

[脅威保護](cognito-user-pool-settings-threat-protection.md)で利用可能な自動レスポンスの 1 つは、Amazon Cognito が潜在的に悪意のあるアクティビティを検出したことをユーザーに知らせることです。アドバンスドセキュリティのテンプレートのプレースホルダーを使用して、以下を行うことができます。
+ IP アドレス、市、国、サインイン時間、デバイス名など、イベントに関する具体的な詳細を記載します。Amazon Cognito の脅威保護は、これらの詳細を分析できます。
+ ワンクリックリンクが有効であるかどうかを確認します。
+ イベント ID、フィードバックトークン、およびユーザー名を使用して独自のワンクリックリンクを構築します。

**注記**  
ワンクリックリンクを生成し、アドバンスドセキュリティ E メールテンプレートで `{one-click-link-valid}` および `{one-click-link-invalid}` プレースホルダーを使用するには、ユーザープール用にドメインが既に設定されている必要があります。

脅威保護では、以下のプレースホルダーを追加してメッセージテンプレートに挿入できるようにします。これらのプレースホルダーは、**アダプティブ認証メッセージ**に適用されます。このメッセージは、ユーザーのセッションがリスクレベルの評価を受けた場合に、Amazon Cognito からユーザーに送信する通知です。これらの変数を使用してメッセージテンプレートを設定するには、Amazon Cognito コンソールで脅威保護の **[フル機能]** 設定を更新するか、[SetRiskConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetRiskConfiguration.html) リクエストでテンプレートを送信します。


**アドバンスドセキュリティのテンプレートのプレースホルダー**  

|  説明  |  トークン  | 
| --- | --- | 
| IP アドレス | \$1ip-address\$1 | 
| City | \$1city\$1 | 
| Country | \$1country\$1 | 
| ログイン時間 | \$1login-time\$1 | 
| デバイス名 | \$1device-name\$1 | 
| オンクリックリンクが有効 | \$1one-click-link-valid\$1 | 
| オンクリックリンクが無効 | \$1one-click-link-invalid\$1 | 
| Event ID | \$1event-id\$1 | 
| フィードバックトークン | \$1feedback-token\$1 | 

## E メールと SMS の MFA メッセージのカスタマイズ
<a name="cognito-user-pool-settings-SMS-message-customization"></a>

[多要素認証 (MFA)](user-pool-settings-mfa.md) に関する SMS と E メールのメッセージをカスタマイズするには、Amazon Cognito ユーザープールコンソールの **[メッセージテンプレート]** メニューで、**[MFA メッセージ]** を編集します。

**重要**  
カスタムメッセージには、`{####}`プレースホルダーを含む必要があります。このプレースホルダーは、メッセージが送信される前に認証コードへ置き換えられます。

Amazon Cognito では、認証コードも含めて、SMS メッセージの最大長を 140 UTF-8 文字に設定しています。

### SMS 検証メッセージのカスタマイズ
<a name="cognito-user-pool-settings-SMS-verification-message-customization"></a>

電話番号検証用の SMS メッセージをカスタマイズするには、ユーザープールの **[メッセージテンプレート]** メニューで **[検証メッセージ]** テンプレートを編集します。

**重要**  
カスタムメッセージには、`{####}`プレースホルダーを含む必要があります。このプレースホルダーは、メッセージが送信される前に検証コードへ置き換えられます。

メッセージの最大長は検証コードを含めて UTF-8 で 140 文字です。

## E メール検証メッセージのカスタマイズ
<a name="cognito-user-pool-settings-email-verification-message-customization"></a>

Amazon Cognito でユーザープール内のユーザーの E メールアドレスを確認するには、ユーザーが選択できるリンクを記載した E メールメッセージをユーザーに送信するか、ユーザーが入力できるコードを送信します。

E メールアドレス検証メッセージの E メールの件名と本文をカスタマイズするには、ユーザープールの **[メッセージテンプレート]** メニューで **[検証メッセージ]** テンプレートを編集します。**[検証メッセージ]** テンプレートを編集するときに、**[検証タイプ]** として **[コード]** または **[リンク]** を選択できます。

検証タイプとして**コード**を選択した場合、カスタムメッセージには `{####}` プレースホルダーを含める必要があります。メッセージを送信するときに、検証コードはこのプレースホルダーを置き換えます。

検証タイプとして**リンク**を選択した場合、カスタムメッセージにはプレースホルダーを `{##Verify Your Email##}` の形式で含める必要があります。プレースホルダー文字間のテキスト文字列は、`{##Click here##}` のように変更できます。*E メールを検証する*というタイトルの検証リンは、このプレースホルダーを置き換えます。

E メール検証メッセージのリンクは、ユーザーを次の例のような URL に誘導します。

```
https://<your user pool domain>/confirmUser/?client_id=abcdefg12345678&user_name=emailtest&confirmation_code=123456
```

メッセージの最大長は検証コード (ある場合) を含めて UTF-8 で 20,000 文字です。このメッセージでは、HTML タグを使用してコンテンツの書式を設定できます。

## ユーザー招待メッセージのカスタマイズ
<a name="cognito-user-pool-settings-user-invitation-message-customization"></a>

Amazon Cognito が SMS または E メールメッセージを使用して新規ユーザーに送信するユーザー招待メッセージをカスタマイズするには、**[メッセージテンプレート]** メニューで **[招待メッセージ]** テンプレートを編集できます。

**重要**  
カスタムメッセージには、`{username}` および `{####}` のプレースホルダーを含む必要があります。Amazon Cognito が招待メッセージを送信すると、これらのプレースホルダーはユーザーのユーザー名とパスワードに置き換えられます。

SMS メッセージの最大長は検証コードを含めて UTF-8 で 140 文字です。E メールメッセージの最大長は検証コードを含めて UTF-8 で 20,000 文字です。E メールメッセージに HTML タグを使用して、コンテンツの書式を設定できます。

## E メールアドレスのカスタマイズ
<a name="cognito-user-pool-settings-email-address-customization"></a>

デフォルトでは、Amazon Cognito は、**no-reply@verificationemail.com** からユーザープール内のユーザーに E メールメッセージを送信します。**no-reply@verificationemail.com** の代わりにカスタムの FROM と REPLY-TO メールアドレスを指定するか選択できます。

**FROM と REPLY-TO の E メールアドレスをカスタマイズするには**

1. [[Amazon Cognito console]](https://console.aws.amazon.com/cognito/home) (Amazon Cognito コンソール) に移動し、**[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[認証方法]** メニューを選択します。**[Email]** (E メール) で、**[Edit]** (編集) を選択します。

1. **[SES Region]** (SES リージョン)を選択します。

1. 選択した **[SES Region]** (SES リージョン) の Amazon SES で検証した E メールアドレスリストから **[FROM email address]** (FROM E メールアドレス) を選択します。検証済みドメインの E メールアドレスを使用するには、 AWS Command Line Interface または AWS API で E メール設定を設定します。詳細については、*Amazon Simple Email Service デベロッパーガイド*の「[Amazon SES での E メールアドレスとドメインの検証](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/verify-addresses-and-domains.html)」を参照してください。

1. 選択した**[SES Region]** (SES リージョン)の構成セットのリストから、**[Configuration set]** (構成セット) を選択します。

1. E メールメッセージ用に、わかりやすい **[FROM sender name]** (FROM 送信者名) を`John Stiles <johnstiles@example.com>`の形式で入力します。

1. 返信先 E メールアドレスをカスタマイズするには、[**REPLY-TO email address (返信先 E メールアドレス)**] フィールドに有効な E メールアドレスを入力します。

## Amazon SES E メールを代理送信するための Amazon Cognito の承認 (カスタム REPLY-TO E メールアドレスからの送信)
<a name="cognito-user-pool-settings-ses-authorization-to-send-email"></a>

Amazon Cognito は、デフォルトのアドレスではなく、カスタムの FROM メールアドレスからメールを送信するように設定できます。カスタムアドレスを使用するには、Amazon SES で検証済みの ID から E メールメッセージを送信できる許可を Amazon Cognito に付与する必要があります。ほとんどの場合、送信承認ポリシーを作成することで許可が付与できます。詳細については、*Amazon Simple Email Service デベロッパーガイド*の「[Amazon SES での送信承認の使用](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-authorization.html)」を参照してください。

メールメッセージに Amazon SES の使用許可をユーザープールを設定すると、Amazon Cognito はアカウントに `AWSServiceRoleForAmazonCognitoIdpEmailService` ロールを作成して、Amazon SES へのアクセスを許可します。`AWSServiceRoleForAmazonCognitoIdpEmailService` サービスにリンクされたロールが使用される場合、送信承認ポリシーは必要ありません。ユーザープールのデフォルト E メール機能*と、*検証済みの Amazon SES ID の両方を FROM アドレスとして使用する場合のみ、送信承認ポリシーを追加する必要があります。

Amazon Cognito が作成するサービスリンクロールの詳細については、「[Amazon Cognito のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。

次の送信承認ポリシーの例では、Amazon SES 検証済み ID を使用するための限定された権限が Amazon Cognito に付与されています。Amazon Cognito は、条件 `aws:SourceArn` のユーザープールと条件 `aws:SourceAccount` のアカウントの両方に代わって送信する場合にのみ、E メールメッセージを送信できます。その他の例については、「*Amazon Simple Email Service デベロッパーガイド*」の「[Amazon SES 送信承認ポリシーの例](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-authorization-policy-examples.html)」を参照してください。

**注記**  
この例では、「Sid」値はステートメントを一意に識別する任意の文字列です。ポリシー構文の詳細については、「*Amazon Simple Email Service デベロッパーガイド*」の「[Amazon SES 送信承認ポリシー](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-authorization-policies.html)」を参照してください。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "stmnt1234567891234",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "email.cognito-idp.amazonaws.com"
                ]
            },
            "Action": [
                "SES:SendEmail",
                "SES:SendRawEmail"
            ],
            "Resource": "arn:aws:ses:us-east-1:111122223333:identity/support@example.com",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:cognito-idp:us-east-1:111122223333:userpool/us-east-1_EXAMPLE"
                }
            }
        }
    ]
}
```

------

Amazon Cognito コンソールは、ドロップダウンメニューから Amazon SES の ID を選択するときに同様のポリシーを追加します。CLI または API を使用してユーザープールを設定する場合は、前の例のように構造化されたポリシーを Amazon SES アイデンティティにアタッチする必要があります。

# 管理者としてのユーザーアカウントの作成
<a name="how-to-create-user-accounts"></a>

ユーザープールは、インターネット上の誰でもアプリケーション内のユーザープロファイルにサインアップできるという、Customer Identity and Access Management (CIAM) のユーザーディレクトリであるだけでありません。セルフサービスサインアップを無効にすることができます。顧客の本人確認が済んでいる場合に、事前に認可された顧客のみを認めることをお勧めします。[プライベート SAML 2.0 または OIDC ID プロバイダー](cognito-user-pools-identity-federation.md)を使用して、アプリケーションの周囲に手動認証ガードレールを配置するには、[ユーザーをインポート](cognito-user-pools-import-users.md)するか、[サインアップ時にユーザーをスクリーニング](user-pool-lambda-pre-sign-up.md)するか、または、管理 API オペレーションを使用してユーザーを作成します。ユーザーの管理作成ワークフローは、プログラムによることでも、別のシステムに登録した後にユーザーをプロビジョニングすることでも、Amazon Cognito コンソールでケースバイケースやテストベースで作成することでも可能です。

ユーザーを管理者として作成すると、Amazon Cognito は、ユーザーの一時的なパスワードを設定し、ウェルカムメッセージまたは招待メッセージを送信します。招待メッセージのリンクに従って初回のサインインを行い、パスワードを設定し、アカウントを確認できます。次のページでは、新しいユーザーを作成し、ウェルカムメッセージを設定する方法について説明します。ユーザープール API と AWS SDK または CDK を使用したユーザー作成の詳細については、[AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html)」を参照してください。

ユーザープールを作成したら、 AWS マネジメントコンソール、、 AWS Command Line Interface または Amazon Cognito API を使用してユーザーを作成できます。ユーザープールで新しいユーザーのプロファイルを作成し、サインアップ手順を含めたウェルカムメッセージをそのユーザーに SMS または E メールで送信できます。

管理者がユーザープール内のユーザーを管理する方法の例を以下に示します。
+ Amazon Cognito コンソールまたは `AdminCreateUser` API オペレーションを使用して新しいユーザープロファイルを作成します。
+ ユーザー名パスワード、パスワードなし、パスキー、カスタム[認証フロー](amazon-cognito-user-pools-authentication-flow-methods.md)を、ユーザープールとアプリケーションクライアントで利用できるようにします。
+ ユーザー属性値を設定します。
+ カスタム属性を作成します。
+ `AdminCreateUser` API リクエストに、イミュータブルな[カスタム属性](user-pool-settings-attributes.md#user-pool-settings-custom-attributes)の値を設定します。この機能は Amazon Cognito コンソールでは利用できません。
+ 仮パスワードを指定するか、パスワードなしでユーザーを作成するか、または Amazon Cognito にパスワードの自動生成を許可します。
+ 新しいユーザーを作成し、アカウントの確認、E メールアドレスの検証、または電話番号の検証を自動的に行います。
+ またはカスタムメッセージ、カスタム SMS 送信者、カスタム E メール送信者などの AWS マネジメントコンソール Lambda トリガーを使用して、新規ユーザーのカスタム SMS および [E メール](user-pool-lambda-custom-email-sender.md)招待[メッセージ](user-pool-lambda-custom-message.md)を指定します。 [カスタム SMS 送信者の Lambda トリガー](user-pool-lambda-custom-sms-sender.md)
+ 招待メッセージが SMS、E メール、その両方のいずれで送信されるかを指定する。
+ `AdminCreateUser` パラメータに `RESEND` を指定して、`MessageAction` API を呼び出すことで、既存のユーザーにウェルカムメッセージを再送信する。
+ ユーザー作成時の招待メッセージの送信を[抑制](#admincreateuserwalkthrough-step-invitationmessage)します。
+ 新規ユーザーアカウントの有効期限を最大 90 日に指定します。
+ ユーザーに自己サインアップを許可したり、管理者にのみ新しいユーザーの追加を許可したりする。

管理者は、サーバー側のアプリケーションで AWS 認証情報を使用してユーザーにサインインすることもできます。詳細については、「[API 認証と SDK 認証の認可モデル](authentication-flows-public-server-side.md)」を参照してください。

## ユーザー認証フローとユーザーの作成
<a name="how-to-create-user-accounts-flows"></a>

管理者がユーザーを作成する場合、ユーザープールの設定に応じて異なるオプションを使用できます。*認証フロー* (ユーザーがサインインと MFA に使用できる方法) に応じて、ユーザーの作成方法とユーザーへの送信メッセージが変わる場合があります。ユーザープールで使用できる認証フローをいくつか以下に示します。
+ ユーザー名とパスワード
+ パスキー
+ サードパーティの IdP によるサインイン
+ E メールおよび SMS ワンタイムパスワード (OTP) によるパスワードなしのサインイン
+ E メール、SMS、Authenticator アプリケーション OTP による多要素認証
+ Lambda トリガーによるカスタム認証

これらのサインイン要素の設定方法の詳細については、「[Amazon Cognito ユーザープールによる認証](authentication.md)」を参照してください。

## パスワードなしでユーザーを作成する
<a name="how-to-create-user-accounts-thingstoknow-passwordless"></a>

ユーザープールでパスワードなしのサインインを有効にしている場合は、パスワードなしでユーザーを作成できます。パスワードなしでユーザーを作成するには、使用可能なパスワードなしのサインイン要素の属性値を指定する必要があります。例えば、E メール OTP によるパスワードなしのサインインがユーザープールで使用可能な場合は、パスワードなしで、E メールアドレス属性を持つユーザーを作成できます。新規ユーザーが使用できる認証フローにパスワード (パスキー、ユーザー名パスワードなど) のみが必要である場合は、新規ユーザーごとに仮パスワードを作成または生成する必要があります。

**パスワードなしの新規ユーザーを作成するには**
+ Amazon Cognito コンソールで **[パスワードを設定しない]** を選択します。
+ `AdminCreateUser` API リクエストの `TemporaryPassword` パラメータを省略するか、空白のままにします。

**パスワードなしのユーザーは自動的に確認される**  
通常、新規ユーザーは作成時に仮パスワードを取得し、`FORCE_CHANGE_PASSWORD` ステータスになります。パスワードなしのユーザーを作成すると、すぐに `CONFIRMED` 状態になります。`CONFIRMED` 状態のユーザーに確認コードを再送信することはできません。

**パスワードなしのユーザーの場合、招待メッセージは変更される**  
デフォルトでは、Amazon Cognito から新規ユーザーに送信される[招待メッセージ](cognito-user-pool-settings-message-customizations.md#cognito-user-pool-settings-user-invitation-message-customization)は、「`Your username is {userName} and your password is {####}.`」という内容です。パスワードなしのユーザーを作成すると、メッセージの内容は「`Your username is {userName}.`」となります。ユーザーのパスワードを設定するかどうかを反映するには、招待メッセージをカスタマイズします。パスワードなしの認証モデルで `{####}` パスワード変数を省略します。

**パスワードなしの要素が利用可能な場合、パスワードは自動生成できない**  
E メールまたは電話の OTP によるパスワードなしのサインインをサポートするようにユーザープールを設定している場合、パスワードを自動生成することはできません。パスワードを持つユーザーごとに、プロファイルの作成時に、仮パスワードを設定する必要があります。

**パスワードなしのユーザーは、すべての必須属性の値を持っている必要がある**  
パスワード*なし*のユーザーを作成する場合、リクエストが成功するのは、ユーザープールで必須としてマークされたすべての属性の値をユーザーが提供した場合のみです。これは、OTP 配信に必要な電話番号と E メールアドレスの属性だけでなく、すべての必須属性に適用されます。

## 後で必須属性の値を提供するユーザーを作成する
<a name="how-to-create-user-accounts-thingstoknow-password-restrictions"></a>

ユーザープールで属性を必須に設定できますが、管理者によるユーザーの作成後に、アプリケーション内でユーザーとやり取りしながら、これらの属性を収集することもできます。管理者は、*仮パスワードを使用*してユーザーを作成するときに、必須属性の値を省略できます。パスワードなしのユーザーの場合、必須属性の値を省略することはできません。

ユーザーが必須属性の値が不足したまま仮パスワードを使用すると、初回サインイン時に [NEW\$1PASSWORD\$1REQUIRED](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html#CognitoUserPools-RespondToAuthChallenge-request-ChallengeResponses) チャレンジを受け取ります。この場合、不足している必須属性の値を `requiredAttributes` パラメータで指定できます。すべての必須属性が[変更可能](user-pool-settings-attributes.md#user-pool-settings-custom-attributes)である場合にのみ、パスワードを持つが必須属性を持たないユーザーを作成できます。ユーザーは、サインインに使用したアプリケーションクライアントから必須属性が[書き込み可能](user-pool-settings-client-apps.md#cognito-user-pools-app-idp-settings-about)である場合に限り、`NEW_PASSWORD_REQUIRED` チャレンジと必須属性の値を使用してサインインを完了できます。

管理者が作成したユーザーに永続的なパスワードを設定すると、ステータスは `CONFIRMED` に変わり、ユーザープールは初回サインイン時に新しいパスワード*または*必須属性の入力を求めません。

## で新しいユーザーを作成する AWS マネジメントコンソール
<a name="creating-a-new-user-using-the-console"></a>

Amazon Cognito コンソールを使用して、ユーザーパスワードの要件を設定し、ユーザーに送信される招待メッセージと確認メッセージを設定し、新しいユーザーを追加できます。

### パスワードポリシーを設定し、自己登録を有効にする
<a name="set-user-password-policy"></a>

パスワードの複雑さを最小限に抑え、ユーザープールでパブリック API を使用してユーザーがサインアップできるかどうかを設定できます。

**パスワードポリシーの設定**

1. [[Amazon Cognito console]](https://console.aws.amazon.com/cognito/home) (Amazon Cognito コンソール) に移動し、**[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[認証方法]** メニューを選択し、**[パスワードポリシー]** を見つけます。**[編集]** を選択します。

1. **[Custom]** (カスタム) の **[Password policy mode]** (パスワードポリシーモード) を選択します。

1. **[Password minimum length]** (パスワードの最小長) を選択します。パスワード長要件の制限については、「[ユーザープールのリソースクォータ](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#limits-hard)」を参照してください。

1. **[Password complexity]** (パスワードの複雑さ) 要件を選択してください。

1. 管理者が設定したパスワードの有効期間を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

**セルフサービスサインアップを許可する**

1. [[Amazon Cognito console]](https://console.aws.amazon.com/cognito/home) (Amazon Cognito コンソール) に移動し、**[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[サインアップ]** メニューを選択し、**[セルフサービスのサインアップ]** を見つけます。**[Edit]** (編集) を選択します。

1. **[Enable self-registration]** (自己登録を有効化) するかどうかを選択します。自己登録は通常、クライアントシークレットまたは AWS Identity and Access Management (IAM) API 認証情報を配布せずにユーザープールに新しいユーザーを登録する必要があるパブリックアプリケーションクライアントで使用されます。
**自己登録の無効化**  
自己登録を有効にしない場合は、IAM API 認証情報、またはフェデレーションプロバイダーとのサインインを使用して管理 API アクションで新しいユーザーを作成する必要があります。

1. **[Save changes]** (変更の保存) をクリックします。

### E メールメッセージと SMS メッセージのカスタマイズ
<a name="creating-a-new-user-customize-messages"></a>

**ユーザーメッセージのカスタマイズ**

Amazon Cognito がユーザーにサインインするように招待したとき、ユーザーがユーザーアカウントへのサインアップ、またはサインインして多要素認証 (MFA) を要求される際に Amazon Cognito はユーザーに送信するメッセージをカスタマイズできます。
**注記**  
**[Invitation message]** (招待メッセージ) はユーザープールにユーザーを作成し、サインインに招待すると送信されます。Amazon Cognito はユーザーの E メールアドレスまたは電話番号に初期サインイン情報を送信します。  
**検証メッセージ**は、ユーザーがユーザープールのユーザーアカウントに登録したときに送信されます。Amazon Cognito はユーザーにコードを送信します。ユーザーが Amazon Cognito にコードを提供すると、連絡先情報を確認し、サインインのためにアカウントを確認します。検証コードは 24 時間有効です。  
**[MFA message]** (MFA メッセージ) は、ユーザープールで SMS MFA を有効にし、SMS MFA を構成したユーザーがサインインして MFA を要求されたときに送信されます。

1. [[Amazon Cognito console]](https://console.aws.amazon.com/cognito/home) (Amazon Cognito コンソール) に移動し、**[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[メッセージテンプレート]** メニューを選択して、**[検証メッセージ]**、**[招待メッセージ]**、または **[MFA メッセージ]** を選択し、**[編集]** を選択します。

1. 選択したメッセージタイプのメッセージをカスタマイズします。
**注記**  
メッセージをカスタマイズするときは、メッセージテンプレート内のすべての変数を含める必要があります。例えば、変数の場合 **\$1\$1\$1\$1\$1\$1** は含まれません。ユーザーにはメッセージアクションを完了するのに十分な情報がありません。  
詳細については、「[メッセージテンプレート](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-message-templates.html)」を参照してください。

1. 

   1. **検証メッセージ**

      1. **[Email]** (E メール) メッセージの **[Verification type]** (検証タイプ) を選択します。**[Code]** (コード) 検証は、ユーザーが入力する必要がある数値コードを送信します。**[Link]** (リンク) 検証は、ユーザーがクリックして連絡先情報を検証できるリンクを送信します。変数内のテキスト **[Link]** (リンク) メッセージはハイパーリンクテキストとして表示されます。例えば、変数 \$1\$1 \$1Click here\$1\$1\$1 を使用したメッセージテンプレートは、E メールメッセージで「[Click here]() (ここをクリックしてください) 」というように表示されます。

      1. **[Email]** (E メール) メッセージの **[Email subject]** (E メールの件名) を入力します。

      1. **[Email]** (E メール) メッセージのカスタムの **[Email message]** (E メールメッセージ) のテンプレートを入力します。このテンプレートは HTML でカスタマイズできます。

      1. **[SMS]** メッセージのカスタムの **[SMS message]** (SMS メッセージ) のテンプレートを入力します。

      1. **[Save changes]** (変更の保存) をクリックします。

   1. **[Invitation messages]** (招待メッセージ)

      1. **[Email]** (E メール) メッセージの **[Email subject]** (E メールの件名) を入力します。

      1. **[Email]** (E メール) メッセージのカスタムの **[Email message]** (E メールメッセージ) のテンプレートを入力します。このテンプレートは HTML でカスタマイズできます。

      1. **[SMS]** メッセージのカスタムの **[SMS message]** (SMS メッセージ) のテンプレートを入力します。

      1. **[Save changes]** (変更の保存) をクリックします。

   1. **MFA メッセージ**

      1. **[SMS]** メッセージのカスタムの **[SMS message]** (SMS メッセージ) のテンプレートを入力します。

      1. **[Save changes]** (変更の保存) をクリックします。

### ユーザーの作成
<a name="creating-a-new-user-using-the-users-tab"></a>

**ユーザーの作成**

Amazon Cognito コンソールからユーザープールの新しいユーザーを作成できます。通常、ユーザーはパスワードを設定した後にサインインできます。E メールアドレスでサインインするには、ユーザーは `email` 属性を確認する必要があります。電話番号でサインインするには、ユーザーは `phone_number` 属性を確認する必要があります。アカウントを管理者として確認するには、 AWS CLI または API を使用するか、フェデレーティッド ID プロバイダーでユーザープロファイルを作成することもできます。詳細については、「[Amazon Cognito API Reference](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/)」を参照してください。

1. [[Amazon Cognito console]](https://console.aws.amazon.com/cognito/home) (Amazon Cognito コンソール) に移動し、**[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[ユーザー]** メニュー、**[ユーザーを作成]** の順に選択します。

1. パスワード要件、使用可能なアカウント回復方法、およびユーザープールのエイリアス属性に関するガイダンスは、「**ユーザープールのサインインとセキュリティ要件**」を参照してください。

1. <a name="admincreateuserwalkthrough-step-invitationmessage"></a>**招待メッセージ**の送信方法を選択します。SMS メッセージ、E メールメッセージ、または両方を選択します。招待メッセージを抑制するには、**[招待を送信しない]** を選択します。
**注記**  
招待メッセージを送信する前に、ユーザープールの **[認証方法]** メニューで、Amazon Simple Notification Service および Amazon Simple Email Service により、送信者と AWS リージョン を設定します。受信者メッセージとデータレートが適用されます。Amazon SES は、メールメッセージの請求を別途請求し、Amazon SNS は SMS メッセージについて別途請求します。

1. 新規ユーザー用に **[Username]** (ユーザー名) を選択します。

1. **[Create a password]** (パスワードを作成する) または、Amazon Cognito にユーザーの **[Generate a password]** (パスワードを生成する) を許可するかどうかを選択してください。[[パスワードなしのサインイン]](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless) がユーザープールで利用可能な場合、パスワードを生成するオプションは使用できません。一時パスワードは、ユーザープールのパスワードポリシーに準拠する必要があります。

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

1. **[ユーザー]** メニューを選択し、**[ユーザー名]** でユーザー名を入力します。**[User attributes]** (ユーザー属性) および **[Group memberships]** (グループメンバーシップ) を追加して編集します。**ユーザーイベント履歴**の確認

# ユーザープールにグループを追加する
<a name="cognito-user-pools-user-groups"></a>

Amazon Cognito ユーザープール内のグループのサポートにより、ユーザーの作成と管理、グループへのユーザーの追加、およびグループからのユーザーの削除が可能になります。グループを使用して、ユーザーのコレクションを作成してそのアクセス権限を管理したり、異なるタイプのユーザーを表したりできます。 AWS Identity and Access Management (IAM) ロールをグループに割り当てると、グループのメンバーのアクセス許可を定義できます。

グループを使用して、ユーザープールでユーザーのコレクションを作成できます。この操作は、これらのユーザーのアクセス権限を設定するためによく行われます。例えば、ウェブサイトやアプリの読者、寄稿者、および編集者であるユーザーに対して別個のグループを作成できます。また、グループに関連付けられた IAM ロールを使用することで、これらの異なるグループに異なる許可を設定して、コントリビュータのみがコンテンツを Amazon S3 に配置し、エディタのみが Amazon API Gateway の API を通じてコンテンツをパブリッシュできるようにすることも可能です。

Amazon Cognito は、ユーザープールに追加する OIDC、SAMl、ソーシャル [ID プロバイダー](cognito-user-pools-identity-federation.md#cognito-user-pools-identity-federation-how-it-works) (IdP) ごとにユーザーグループを作成します。グループ名の形式は `[user pool ID]_[IdP name]` です (例: `us-east-1_EXAMPLE_MYSSO`、`us-east-1_EXAMPLE_Google`)。自動生成された一意の各 IdP ユーザープロファイルは、このグループに自動的に追加されます。[リンクされたユーザー](cognito-user-pools-identity-federation-consolidate-users.md)は、このグループに自動的に追加されませんが、そのプロファイルを別のプロセスでグループに追加できます。

ユーザープールでグループを作成および管理するには AWS マネジメントコンソール、、 APIs、および CLI を使用します。開発者 ( AWS 認証情報を使用) は、ユーザープールのグループを作成、読み取り、更新、削除、一覧表示できます。また、グループに対してユーザーを追加、削除できます。

ユーザープール内のグループを使用しても追加コストは発生しません。詳細については、「[Amazon Cognito の料金](https://aws.amazon.com/cognito/pricing/)」を参照してください。

## グループへの IAM ロールの割り当て
<a name="assigning-iam-roles-to-groups"></a>

グループを使用して、IAM ロールでリソースへの許可を制御できます。IAM ロールには、信頼ポリシーと許可ポリシーが含まれます。ロールの[信頼](https://docs.aws.amazon.com/cognito/latest/developerguide/role-trust-and-permissions.html)ポリシーでは、ロールを使用できるユーザーを指定します。[アクセス許可](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies)ポリシーでは、グループメンバーがアクセスできるアクションとリソースを指定します。IAM ロールを作成するときに、グループユーザーがロールを引き受けることを許可するロールの信頼ポリシーを設定します。ロールの許可ポリシーで、グループに付与する許可を指定します。

Amazon Cognito でグループを作成するときは、ロールの [ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns)を指定して IAM ロールを指定します。グループメンバーが Amazon Cognito を使用してサインインすると、ID プールから一時的な認証情報を受け取ることができます。それらの許可は、関連付けられた IAM ロールによって決まります。

各ユーザーは複数のグループに属することができます。デベロッパーとして、ユーザーが複数のグループに属している場合に IAM ロールを自動的に選択するための以下のオプションがあります。
+ 各グループに優先順位の値を割り当てることができます。優先順位が高い (低い) グループが選択され、それに関連付けられた IAM ロールが適用されます。
+ また、アプリは、ID プールを通じてユーザーの AWS 認証情報をリクエストするときに、[GetCredentialsForIdentity](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_GetCredentialsForIdentity.html) `CustomRoleARN` パラメータでロール ARN を指定して、利用できるロールから選択できます。指定された IAM ロールは、ユーザーが利用できるロールに一致する必要があります。

## グループへの優先順位の値の割り当て
<a name="assigning-precedence-values-to-groups"></a>

ユーザーは複数のグループに属することができます。ユーザーのアクセストークンと ID トークンの `cognito:groups` クレームには、ユーザーが属するすべてのグループのリストが含まれます。`cognito:roles` クレームには、グループに対応するロールのリストが含まれます。

ユーザーは複数のグループに属することができるので、各グループに優先順位を割り当てることができます。これは、ユーザーがユーザープールで属するその他のグループに対するこのグループの優先順字を指定する正数です。ゼロが最優先順位値です。低い優先順位の値を持つグループは、高い優先順位の値または null 値を持つグループよりも優先されます。ユーザーが複数のグループに属している場合、ユーザーの ID トークンの `cognito:preferred_role` クレームに適用される IAM ロールは、優先順位の値が最も低いグループのものになります。

2 つのグループは、同じ優先順位の値を持つことができます。その場合は、どちらのグループも他方に対して優先されません。同じ優先順位の値を持つ 2 つのグループのロール ARN が同じである場合、そのロールは、各グループのユーザーの ID トークンの `cognito:preferred_role` クレームで使用されます。2 つのグループのロール ARN が異なる場合、`cognito:preferred_role` クレームは、ユーザーの ID トークンで設定されません。

## Amazon API Gateway を使用した許可の管理でのグループの使用
<a name="using-groups-to-control-permission-with-amazon-api-gateway"></a>

Amazon API Gateway を使用した許可の管理には、ユーザープールのグループを使用することができます。ユーザーがメンバーであるグループは、IDトークンと `cognito:groups` クレームのユーザープールからのアクセストークンの両方に含まれています。リクエストとともに ID またはアクセストークンを Amazon API Gateway に送信し、REST API に Amazon Cognito ユーザープールオーソライザーを使用できます。詳細については、[API Gateway デベロッパーガイド](https://docs.aws.amazon.com/apigateway/latest/developerguide/)の「[Amazon Cognito ユーザープールをオーソライザーとして使用して REST API へのアクセスを制御する](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)」を参照してください

カスタム JWT オーソライザーを使用して Amazon API Gateway HTTP API へのアクセスを承認することもできます。詳細については、[API Gateway デベロッパーガイド](https://docs.aws.amazon.com/apigateway/latest/developerguide/)の「[JWT オーソライザーを使用した HTTP API へのアクセスの制御](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html)」を参照してください。

## グループの制限
<a name="user-pool-user-groups-limitations"></a>

ユーザーグループには、次の制限が適用されます。
+ 作成できるグループの数は、[Amazon Cognito サービスクォータ](quotas.md)によって制限されます。
+ グループはネストできません。
+ グループのユーザーを検索することはできません。
+ グループを名前で検索することはできませんが、グループをリストすることはできます。

## で新しいグループを作成する AWS マネジメントコンソール
<a name="creating-a-new-group-using-the-console"></a>

以下の手順に従って、新しいグループを作成します。

**新しいグループを作成する**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[グループ]** メニュー、**[グループを作成]** の順に選択します。

1. **[Create a group]** (グループを作成する) ページで、**[Group name]** (グループ名) に新しいグループのフレンドリ名を入力します。

1. オプションで、次のフィールドのいずれかを使用して、このグループに関する追加情報を指定できます。
   + **[Description]** (説明) - この新しいグループの使用目的の詳細を入力します。
   + **[Precedence]** (優先順位) - Amazon Cognito は、優先度が低いグループに属するグループに基づいて、特定のユーザーに対するすべてのグループ権限を評価し、適用します。優先順位が低いグループが選択され、それに関連付けられた IAM ロールが適用されます。詳細については、「[グループへの優先順位の値の割り当て](#assigning-precedence-values-to-groups)」を参照してください。
   + **[IAM role]** (IAM ロール) -リソースへのアクセス許可を制御する必要がある場合は、グループに IAM ロールを割り当てることができます。ID プールを持つユーザープールを統合する場合、[**IAM ロール**] の設定によって、トークンからロールを選択するよう ID プールが設定されているときに、ユーザーの ID トークンに割り当てられるロールが決定されます。詳細については、「[グループへの IAM ロールの割り当て](#assigning-iam-roles-to-groups)」を参照してください。
   + **[Add users to this group]** (ユーザーをこのグループに追加する) - 既存のユーザーを作成した後、このグループのメンバーとして追加します。

1. **[Create]** (作成) を選択して確定します。

# ユーザーアカウントの管理と検索
<a name="how-to-manage-user-accounts"></a>

ユーザープールには数百万のユーザーを含めることができます。このサイズのデータセットを使用するのは管理者にとって課題になります。Amazon Cognito には、ユーザープロファイルの検索や変更を行うツールがあります。ユーザーを検索する主な方法は、Amazon Cognito コンソールの **[ユーザー]** メニューと [ListUsers](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html) を使用することです。ユーザーに関する情報を取得する方法としては、[[AdminGetUser]](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminGetUser.html) などとは異なり、コストに影響しないオプションです。

本ガイドのこのセクションには、ユーザープール内のユーザープロファイルの検索と更新に関する情報が記載されています。

## ユーザー属性の表示
<a name="manage-user-accounts-viewing-user-attributes"></a>

Amazon Cognito コンソールでユーザー属性を表示するには、以下の手順に従います。

**ユーザー属性を表示するには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[ユーザー]** メニューを選択し、リストからユーザーを選択します。

1. ユーザーの詳細ページの **[User attributes]** (ユーザー属性) で、ユーザーに関連付けられている属性を表示できます。

## ユーザーのパスワードのリセット
<a name="manage-user-accounts-reset-user-password"></a>

Amazon Cognito コンソールでユーザーのパスワードをリセットするには、以下の手順に従います。

**ユーザーのパスワードのリセット**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[ユーザー]** メニューを選択し、リストからユーザーを選択します。

1. ユーザーの詳細ページで、**[Actions]** (アクション)、**[Reset password]** (パスワードのリセット) を選択します。

1. **[Reset password]** (パスワードのリセット) ダイアログで、情報を確認し、準備ができたら **[Reset]** (リセット) を選択します。

   この行動により、確認コードがユーザーに即時送信され、ユーザーの状態が `RESET_REQUIRED` に変更されることでユーザーの現在のパスワードが無効にされます。**[Reset password]** (ユーザーパスワードのリセット) コードは、1 時間有効です。

## ユーザーアカウントの有効化、無効化、削除
<a name="manage-user-accounts-enable-disable"></a>

使用されていないユーザープロファイルを削除できます。一時的にアクセスを制限する場合は、無効にすることもできます。ユーザーは自分のアカウントを削除できますが、ユーザーアカウントを有効または無効にできるのはユーザープール管理者のみです。

**削除の影響**  
ユーザーは、削除済みのユーザーアカウントでサインインすることはできません。アクセスを回復するには、サインアップするか、再度作成する必要があります。

**アカウントの無効化の影響**  
ユーザーアカウントを無効にすると、Amazon Cognito はすべての認証済みセッションを自動的に無効にし、サインイン用のユーザーアカウントを非アクティブ化して、[アクセストークンと更新トークンの取り消し](token-revocation.md)を行います。無効化したアカウントにユーザーがサインインしようとすると、Amazon Cognito は `invalid_request` エラーとともにメッセージ `User is not enabled` を返します。この動作は、アプリケーションクライアントの[ユーザー存在の開示設定](cognito-user-pool-managing-errors.md)では変更されません。ローカルユーザーアカウントと、フェデレーションユーザーアカウントのローカルプロファイルを無効にすることができます。ユーザーがマネージドログインまたはクラシックのホストされた UI を使用してサインインし、その後アカウントを無効にした場合、認証されたセッションを維持するブラウザ Cookie を通じて再度サインインしようとすると、Amazon Cognito によってログインページにリダイレクトされます。

**アカウントの有効化の影響**  
ユーザーは、アカウントを有効にすると、すぐにサインインできます。ユーザーアカウントはデフォルトで有効になります。ユーザーの属性とパスワードは、アカウントが無効になる前と同じままです。アプリケーションで取り消したトークンは、ユーザーアカウントを無効にしたか、更新トークンを別個に取り消したかにかかわらず、トークンを所有していたユーザーアカウントを有効にした後も無効のままになります。

------
#### [ Delete a user account (console) ]

**ユーザーアカウントを削除するには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[ユーザー]** メニューを選択し、リスト内のユーザーのユーザー名の横にあるラジオボタンを選択します。

1. **[削除]** を選択します。

1. **[アクセスの無効化]** を選択します。

1. **[削除]** を選択します。

------
#### [ Delete a user account (API) ]

ユーザーは、セルフサービスのアクセストークンで認可された [DeleteUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUser.html) API オペレーションを使用してアカウントを削除できます。`DeleteUser` リクエスト本文の例を次に示します。

```
{
   "AccessToken": "eyJra456defEXAMPLE"
}
```

管理者は、IAM で認可された [AdminDeleteUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminDeleteUser.html) API オペレーションを使用してユーザーアカウントを削除できます。`AdminDeleteUser` リクエスト本文の例を次に示します。

```
{
   "Username": "testuser",
   "UserPoolId": "us-west-2_EXAMPLE"
}
```

------
#### [ Disable a user account (console) ]

**ユーザーアカウントを無効にするには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[ユーザー]** メニューを選択し、リストからユーザーのユーザー名を選択します。

1. ユーザーの詳細ページで、**[アクション]**、**[ユーザーアクセスの無効化]** の順に選択します。

1. 表示されたダイアログで、**[無効化]** を選択します。

------
#### [ Disable a user account (API) ]

管理者は、IAM で認可された [AdminDisableUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminDisableUser.html) API オペレーションを使用してユーザーアカウントを無効化できます。`AdminDisableUser` リクエスト本文の例を次に示します。

```
{
   "Username": "testuser",
   "UserPoolId": "us-west-2_EXAMPLE"
}
```

------
#### [ Enable a user account (console) ]

**ユーザーアカウントを有効にするには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[ユーザー]** メニューを選択し、リストからユーザーのユーザー名を選択します。

1. ユーザーの詳細ページで、**[アクション]**、**[ユーザーアクセスの有効化]** の順に選択します。

1. 表示されたダイアログで、**[有効化]** を選択します。

------
#### [ Enable a user account (API) ]

管理者は、IAM で認可された [AdminEnableUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminEnableUser.html) API オペレーションを使用してユーザーアカウントを有効化できます。`AdminEnableUser` リクエスト本文の例を次に示します。

```
{
   "Username": "testuser",
   "UserPoolId": "us-west-2_EXAMPLE"
}
```

------

## ユーザー属性の検索
<a name="manage-user-accounts-searching-user-attributes"></a>

ユーザープールがすでに作成されている場合は、 AWS マネジメントコンソールの [**Users**] (ユーザー) パネルから検索できます。また、**[Filter]** (フィルター) パラメータを受け入れる Amazon Cognitoの [ListUsers API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html) も使用できます。

以下のどの標準属性でも検索できます。カスタム属性は検索できません。
+ username (大文字と小文字が区別されます)
+ email
+ phone\$1number
+ name
+ given\$1name
+ family\$1name
+ preferred\$1username
+ cognito:user\$1status (コンソールでは [**Status (ステータス)**] となっています) (大文字と小文字が区別されません)
+ status (コンソールでは [**Enabled (有効)**] となっています) (大文字と小文字が区別されます)
+ sub

**注記**  
また、クライアント側のフィルターを使用してユーザーを一覧表示することもできます。サーバー側のフィルターは、1 つ以上の属性に一致しません。高度な検索を行うには、 AWS Command Line Interfaceでの `list-users` のアクションの `--query` パラメータを用いたクライアント側のフィルターを使用します。クライアント側のフィルターを使用すると、ListUsers は 0 人以上のユーザーからなるページ分割されたリストを返します。結果がゼロで、複数のページを連続して受信できます。Null ページネーショントークン値を受け取るまで、返される各ページネーショントークンでクエリを繰り返し、組み合わせた結果を確認します。  
サーバー側およびクライアント側のフィルタリングの詳細については、 AWS Command Line Interface 「 ユーザーガイド」の[「出力のフィルタリング AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-filter.html)」を参照してください。

## でユーザーを検索する AWS マネジメントコンソール
<a name="cognito-user-pools-manage-user-accounts-searching-for-users-using-console"></a>

ユーザープールがすでに作成されている場合は、 AWS マネジメントコンソールの [**Users**] (ユーザー) パネルから検索できます。

AWS マネジメントコンソール 検索は常にプレフィックス (「starts with」) 検索です。

**Amazon Cognito コンソールでユーザーを検索する**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。 AWS 認証情報の入力を求められる場合があります。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[ユーザー]** メニューを選択し、検索フィールドにユーザー名を入力します。**[Username]** (ユーザーネーム) など、一部の属性値では、大文字と小文字が区別される点に注意してください。

   また、検索フィルターを調整して、スコープを他のユーザープロパティ (**[Email]** (E メール)、**[Phone number]** (電話番号)、または **[Last name]** (姓)など) に絞り込むことで、ユーザーを検索することもできます。

## `ListUsers` API を使用したユーザーの検索
<a name="cognito-user-pools-searching-for-users-using-listusers-api"></a>

 アプリからユーザーを検索するには、Amazon Cognito の [ListUsers API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html) を使用します。この API は以下のパラメータを使用します。
+  `AttributesToGet`: 文字列の配列です。各文字列は、検索結果でユーザーごとに返されるユーザー属性の名前です。すべての属性を取得するには、`AttributesToGet` パラメータを含めないか、またはリテラル文字列の値 `null` を使って `AttributesToGet` をリクエストしてください。
+  `Filter`: 「 ""」形式のフィルター文字列です。`AttributeName``Filter-Type``AttributeValue`フィルター文字列内の引用符は、円記号 (`\`) を使用してエスケープする必要があります。例えば、`"family_name = \"Reddy\""`。フィルター文字列が空の場合、`ListUsers` はユーザープールのすべてのユーザーを返します。
  +  `AttributeName`: 検索する属性の名前。同時に検索できる属性は 1 つのみです。
**注記**  
標準属性のみを検索できます。カスタム属性は検索できません。これはインデックスが付けられた属性のみが検索可能なためで、カスタム属性にインデックスを作成することはできません。
  +  `Filter-Type`: 完全一致を検索する場合は、`=` を使用します (`given_name = "Jon"` など)。プレフィックス (「先頭の文字」) 一致を検索する場合、`^=` を使用します (`given_name ^= "Jon"` など)。
  +  `AttributeValue`: ユーザーごとに一致する必要がある属性値です。
+  `Limit`: 返されるユーザーの最大数です。
+  `PaginationToken`: 前の検索からさらに結果を取得するためのトークンです。Amazon Cognito は 1 時間後にページ分割トークンを期限切れにします。
+  `UserPoolId`: 検索を実行する必要があるユーザープールのユーザープール ID です。

すべての検索で大文字と小文字が区別されません。検索結果は、`AttributeName` 文字列により指定された属性によって昇順に並べ替えられます。

## `ListUsers` API の使用例
<a name="cognito-user-pools-searching-for-users-listusers-api-examples"></a>

次の例はすべてのユーザーを返します。すべての属性が含まれています。

```
{
    "AttributesToGet": null,
    "Filter": "",
    "Limit": 10,
    "UserPoolId": "us-east-1_samplepool"
}
```

次の例は、電話番号の先頭が「\$11312」のすべてのユーザーを返します。また、すべての属性が含まれています。

```
{
    "AttributesToGet": null,
    "Filter": "phone_number ^= \"+1312\"",
    "Limit": 10,
    "UserPoolId": "us-east-1_samplepool"
}
```

次の例は、姓が「Reddy」の先頭 10 人のユーザーを返します。各ユーザーの検索結果には、ユーザーの名、電話番号、E メールアドレスが含まれています。ユーザープールに存在する一致ユーザーが 10 人を超える場合、レスポンスにはページ分割トークンが含まれています。

```
{
    "AttributesToGet": [
        "given_name", 
        "phone_number", 
        "email"
    ],
    "Filter": "family_name = \"Reddy\"",
    "Limit": 10,
    "UserPoolId": "us-east-1_samplepool"
}
```

前の例でページ分割トークンが返された場合、次の例は同じフィルター文字列と一致する次の 10 人のユーザーを返します。

```
{
    "AttributesToGet": [
        "given_name", 
        "phone_number", 
        "email"
    ],
    "Filter": "family_name = \"Reddy\"",
    "Limit": 10,
    "PaginationToken": "pagination_token_from_previous_search",
    "UserPoolId": "us-east-1_samplepool"
}
```

# パスワード、アカウント復旧、パスワードポリシー
<a name="managing-users-passwords"></a>

ユーザープールにサインインするすべてのユーザーには、それが[フェデレーションユーザー](cognito-terms.md#terms-federateduser)であっても、ユーザープロファイルにパスワードが割り当てられます。[ローカルユーザー](cognito-terms.md#terms-localuser)と[リンクされたユーザー](cognito-terms.md#terms-linkeduser)は、サインイン時にパスワードを指定する必要があります。フェデレーションユーザーは、ユーザープールのパスワードを使用しないで、ID プロバイダー (IdP) でサインインします。ユーザー独自のパスワードのリセット、管理者としてのパスワードのリセットや変更、パスワードの複雑さや履歴に関する[ポリシーの設定](#user-pool-settings-policies)を、ユーザーに許可できます。

Amazon Cognito はユーザーパスワードをプレーンテキストで保存しません。代わりに、各ユーザーのパスワードのハッシュをユーザー固有の Salt とともに保存します。このため、ユーザープールのユーザープロファイルから既存のパスワードを取得できません。ベストプラクティスとして、プレーンテキストのユーザーパスワードはどこにも保存しないでください。ユーザーがパスワードを忘れたときにパスワードリセットを実行します。

## パスワードのリセットと復旧
<a name="user-pool-password-reset-and-recovery"></a>

ユーザーがパスワードを忘れることがあります。その場合、パスワードのリセットをユーザー自らができるようにしておくことや、管理者がパスワードのリセットをユーザーに要求することが考えられます。Amazon Cognito ユーザープールでは、両方のモデルのオプションを用意しています。本ガイドのこのパートでは、ユーザープールの設定と、パスワードリセットの API オペレーションについて説明します。

[ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html) API オペレーションと、マネージドログインの **[パスワードを忘れた場合]** オプションでは、ユーザーが正しいコードを持っていることを確認したときに、[ConfirmForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html) を使用して、新しいパスワードを設定できるコードを送信します。これはセルフサービスのパスワード復旧モデルです。

**未検証ユーザーの復旧**  
E メールアドレスまたは電話番号を確認したユーザーには、復旧メッセージを送信できます。ユーザーが確認済みの復旧 E メールまたは電話を持っていない場合、ユーザープール管理者はユーザーの E メールアドレスまたは電話番号を検証済みとしてマークできます。Amazon Cognito コンソールでユーザーの**ユーザー属性**を編集し、**[電話番号を検証済みとしてマークする]** または **[E メールアドレスを検証済みとしてマークする]** の横にあるチェックボックスをオンにします。または、[AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) リクエストで `email_verified` または `phone_number_verified` を true に設定することもできます。新規ユーザーの場合は、[ResendConfirmationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html) API オペレーションからユーザーの E メールアドレスまたは電話番号に新しいコードが送信され、ユーザーはセルフサービスで確認と検証を完了できます。

**管理者としてパスワードをリセットする**  
[AdminSetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html) API オペレーションと [AdminResetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html) API オペレーションは、管理者が開始するパスワードリセット方法です。`AdminSetUserPassword` は、一時的または永続的なパスワードを設定し、`AdminResetUserPassword` は、`ForgotPassword` と同じ方法でパスワードリセットコードをユーザーに送信します。

### パスワードのリセットと復旧を設定する
<a name="user-pool-password-reset-and-recovery-configure"></a>

Amazon Cognito は、コンソールでのユーザープールの作成時に選択した必須属性とサインインオプションに基づいて、アカウント復旧オプションを自動的に選択します。デフォルト設定は変更できます。

ユーザーが希望する MFA の方法は、パスワードの復旧に使用できる方法に影響します。希望する MFA を E メールメッセージにしたユーザーは、パスワードリセットコードを E メールで受信できません。希望する MFA を SMS メッセージにしたユーザーは、パスワードリセットコードを SMS で受信できません。

希望するパスワードリセット方法の対象にユーザーがなっていない場合、[[パスワード復旧]](#user-pool-password-reset-and-recovery) 設定で代替オプションを提供する必要があります。例えば、復旧メカニズムで E メールが最優先事項になっており、E メール MFA がユーザープールのオプションである場合があります。この場合、SMS メッセージによるアカウント復旧を 2 番目のオプションとして追加するか、管理 API オペレーションを使用してこれらのユーザーのパスワードをリセットします。

Amazon Cognito は、有効な復旧方法を持たないユーザーからのパスワードリセットリクエストに対して、`InvalidParameterException` エラーレスポンスで応答します。

**注記**  
ユーザーは、MFA とパスワードのリセットコードを、同じ E メールアドレスや電話番号で受け取ることはできません。E メールメッセージのワンタイムパスワード (OTP) を MFA に使用する場合、アカウントの復旧には SMS メッセージを使用する必要があります。SMS メッセージの OTP を MFA に使用する場合、アカウントの復旧には E メールメッセージを使用する必要があります。MFA を使用するユーザープールでは、属性として E メールアドレスがあっても電話番号がないか、電話番号があっても E メールアドレスがない場合、ユーザーはセルフサービスのパスワード復旧を完了できない可能性があります。  
この設定でユーザーがユーザープールのパスワードをリセットできない状況を防ぐには、`email` および `phone_number` [属性を必須](user-pool-settings-attributes.md)に設定します。別の方法として、ユーザーのサインアップ時や管理者によるユーザープロファイルの作成時に、これらの属性を常に収集して設定するようにプロセスを設定することもできます。ユーザーが両方の属性を持っている場合、Amazon Cognito は、ユーザーの MFA 要素*ではない*送信先にパスワードリセットコードを自動的に送信します。

次の手順では、ユーザープールでセルフサービスのアカウント復旧を設定します。

------
#### [ Configure self-service password reset (API/SDK) ]

`AccountRecoverySetting` パラメータは、ユーザーが [ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html) API リクエストを使用するか、マネージドログインで **[パスワードを忘れた場合]** を選択したときに、パスワードの復旧に使用できる方法を設定するユーザープールパラメータです。`ForgotPassword` は、検証済みの E メールまたは検証済みの電話番号に復旧コードを送信します。回復用コードは 1 時間有効です。ユーザープールに [AccountRecoverySetting](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AccountRecoverySettingType.html) を指定すると、Amazon Cognito は、設定した優先度に基づいてコードの配信先を選択します。

`AccountRecoverySetting` を定義し、ユーザーに SMS MFA が設定されている場合、SMS をアカウント復旧メカニズムとして使用することはできません。この設定の優先度は、`1` を最も高い優先度として決定されます。Amazon Cognito は、指定された方法の 1 つだけに検証を送信します。次の `AccountRecoverySetting` 例では、アカウント復旧コードのプライマリ送信先として E メールアドレスを設定します。ユーザーに E メールアドレス属性がない場合は SMS メッセージにフォールバックします。

```
"AccountRecoverySetting": { 
   "RecoveryMechanisms": [ 
      { 
         "Name": "verified_email",
         "Priority": 1
      },
      { 
         "Name": "verified_phone_number",
         "Priority": 2
      }
   ]
}
```

この値 `admin_only` では、セルフサービスのアカウント復旧がオフになるため、ユーザーは代わりに管理者に連絡してパスワードをリセットする必要があります。他のアカウント復旧メカニズムでは `admin_only` を使用できません。次の例を参照してください。

```
"AccountRecoverySetting": { 
   "RecoveryMechanisms": [ 
      { 
         "Name": "admin_only",
         "Priority": 1
      }
   ]
}
```

`AccountRecoverySetting` を指定しない場合、Amazon Cognito は、まず検証済みの電話番号に復旧コードを送信します。ユーザーに電話番号属性がない場合は、検証済みの E メールアドレスに送信します。

`AccountRecoverySetting` の詳細については「[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html)」と「[UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html)」を参照してください。

------
#### [ Configure self-service password reset (console) ]

ユーザープールの **[サインイン]** メニューから、アカウント復旧オプションとパスワードリセットオプションを設定します。

**ユーザーアカウントの復旧を設定するには**

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

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[サインイン]** メニューを選択します。**[ユーザーアカウントの復旧]** を見つけて**[編集]** を選択します

1. ユーザーが自分のパスワードをリセットできるようにするには、**[セルフサービスのアカウントの復旧を有効化]** を選択します。

1. ユーザープールからユーザーに送信する、パスワードの復旧コードの配信方法を設定します。**[ユーザーアカウントの復旧メッセージの配信方法]** で、使用可能なオプションを選択します。ベストプラクティスとして、メッセージの送信にセカンダリ方法があるオプション (**利用可能な場合は E メール、それ以外の場合は SMS** など) を選択します。セカンダリ配信方法を使用すると、Amazon Cognito は MFA とは異なる方法でパスワードをリセットするようユーザーにコードを送信できます。

1. **[変更を保存]** を選択します。

------

### パスワードを忘れた場合の対応
<a name="forgot-password"></a>

ユーザーがパスワードを忘れた場合や忘れたパスワードを確認する場合のアクションの一環として、パスワードのリセットコードをリクエストしたり、入力したりする試行を所定時間内に 5～20 回許可します。正確な回数は、リクエストに関連付けられたリスクパラメータによって異なります。この対応は変更される場合があることに注意してください。

## ユーザープールのパスワードの追加要件
<a name="user-pool-settings-policies"></a>

強力で複雑なパスワードは、ユーザープールのセキュリティ上のベストプラクティスです。特にインターネットに公開されているアプリケーションでは、パスワードが弱いと、パスワードを推測してデータにアクセスしようとするシステムに対して、ユーザーの認証情報が漏洩する可能性があります。パスワードが複雑であればあるほど、推測しにくくなります。Amazon Cognito には、[脅威保護](cognito-user-pool-settings-threat-protection.md#cognito-user-pool-settings-threat-protection.title)や [AWS WAF ウェブ ACL](user-pool-waf.md#user-pool-waf.title) など、セキュリティを重視する管理者向けの追加のツールがありますが、パスワードポリシーは、ユーザーディレクトリのセキュリティにおいて中心となる要素です。

Amazon Cognito ユーザープールのローカルユーザーのパスワードは、自動的に期限切れになることはありません。ベストプラクティスとして、ユーザーパスワードのリセットの日時やメタデータを外部システムでログに記録します。パスワード利用期間の外部ログを使用すると、アプリケーションまたは Lambda トリガーは、ユーザーのパスワード利用期間を検索し、特定の期間が経過した後にリセットを要求できます。

ユーザープールは、セキュリティ標準に準拠するパスワードの最小限の複雑さを要求するように設定できます。複雑なパスワードは、長さが 8 文字以上です。大文字、数字、特殊文字を組み合わせたパスワードも複雑なパスワードに含まれます。

エッセンシャルまたはプラス機能階層では、パスワードの再利用ポリシーを設定することもできます。ユーザーによるパスワードのリセットにあたって、新しいパスワードの設定を、現在のパスワードに加えて、追加で最大 23 個の以前のパスワード (合計 24 個までのパスワード) に一致できないようにすることができます。

**ユーザープールのパスワードポリシーを設定するには**

1. ユーザープールを作成して **[セキュリティ要件を設定]** ステップに移動するか、既存のユーザープールにアクセスして **[認証方法]** メニューに移動します。

1. **[パスワードポリシー]** に移動します。

1. **[パスワードポリシーモード]** を選択します。**[Cognito のデフォルト]** では、推奨最小設定でユーザープールを設定します。**[カスタム]** パスワードポリシーを選択することもできます。

1. **[パスワードの最小文字数]** を設定します。すべてのユーザーは、この値以上の長さのパスワードでサインアップまたは作成する必要があります。この最小値は 99 まで設定できますが、ユーザーは最大 256 文字のパスワードを設定できます。

1. **[パスワードの要件]** でパスワードの複雑さのルールを設定します。各ユーザーのパスワードで少なくとも 1 つは必須とする文字タイプ (数字、特殊文字、大文字、小文字) を選択します。

   パスワードに以下の文字が最低 1 個は含まれることを要件として設定できます。Amazon Cognito がパスワードに最低限の必須文字が含まれていることを検証したら、ユーザーのパスワードには、任意のタイプで追加の文字を、パスワードの最大の長さまで含めることができます。
   + 大文字と小文字の[基本的なラテン](https://en.wikipedia.org/wiki/ISO_basic_Latin_alphabet)文字
   + 数字
   + 以下の特殊文字。

     ```
     ^ $ * . [ ] { } ( ) ? " ! @ # % & / \ , > < ' : ; | _ ~ ` = + - 
     ```
   + 先頭でも末尾にもない空白文字。

1. **[管理者が設定した一時パスワードの有効期限]** に値を設定します。この期間が過ぎると、Amazon Cognito コンソールまたは `AdminCreateUser` で作成した新しいユーザーは、サインインして新しいパスワードを設定できなくなります。一時パスワードでサインインすると、ユーザーアカウントが期限切れになることはありません。Amazon Cognito ユーザープール API のパスワード有効期間を更新するには、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) または [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストで [TemporaryPasswordValidityDays](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_PasswordPolicyType.html#CognitoUserPools-Type-PasswordPolicyType-TemporaryPasswordValidityDays) の値を設定します。

1. 可能な場合は、**[以前のパスワードの使用を防止]** の値を設定します。この機能を使用するには、ユーザープールでエッセンシャルまたはプラス[機能階層](cognito-sign-in-feature-plans.md)を選択します。このパラメータの値は、ユーザーによるパスワードのリセット時に新しいパスワードの設定で一致ささせないようにする以前のパスワードの数です。

期限切れのユーザーアカウントのアクセス権をリセットするには、以下のいずれかを実行します。
+ 新しい仮パスワードを送信し、`MessageAction` が `RESEND` に設定されている [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html) API リクエストを使用して有効期限をリセットします。
+ ユーザープロファイルを削除し、新しいものを作成します。
+ [AdminResetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html) API リクエストで新しい確認コードを生成します。

# ユーザープールへのユーザーのインポート
<a name="cognito-user-pools-import-users"></a>

既存のユーザーディレクトリまたはユーザーデータベースから Amazon Cognito にユーザーをインポートまたは移行する方法は 2 つあります。1 つは、ユーザー移行の Lambda トリガーを使用して、ユーザーが Amazon Cognito を使用して初めてサインインするときにユーザーを移行する方法です。この方法では、ユーザーが既存のパスワードを引き続き使用でき、ユーザープールへの移行後にパスワードをリセットする必要はありません。もう 1 つは、すべてのユーザーのユーザープロファイル属性を含む CSV ファイルをアップロードして、ユーザーを一括で移行する方法です。以降のセクションでは、これらの両方のアプローチについて説明します。

**その他のリソース**
+ [Amazon Cognito ユーザープールへのユーザー移行方法](https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools/)
+ [AWS re:Inforce 2023 - Amazon Cognito への移行](https://www.youtube.com/watch?v=OkDj9uXWwCc)

**Topics**
+ [ユーザー移行の Lambda トリガーを使用したユーザーのインポート](cognito-user-pools-import-using-lambda.md)
+ [CSV ファイルからユーザープールへのユーザーのインポート](cognito-user-pools-using-import-tool.md)

# ユーザー移行の Lambda トリガーを使用したユーザーのインポート
<a name="cognito-user-pools-import-using-lambda"></a>

このアプローチでは、ユーザーがアプリケーションで初めてサインインするとき、またはパスワードのリセットをリクエストするときに、既存のユーザーディレクトリからユーザープールにユーザーをシームレスに移行できます。[ユーザー移行の Lambda トリガー](user-pool-lambda-migrate-user.md) 関数をユーザープールに追加すると、サインインしようとするユーザーに関するメタデータを受け取り、外部 ID ソースからユーザープロファイル情報を返します。この Lambda トリガーの詳細 (リクエストとレスポンスのパラメータなど) とサンプルコードについては、「[ユーザー移行の Lambda トリガーのパラメータ](user-pool-lambda-migrate-user.md#cognito-user-pools-lambda-trigger-syntax-user-migration)」を参照してください。

ユーザーの移行を開始する前に、 AWS アカウントでユーザー移行の Lambda 関数を作成し、ユーザープールに Lambda 関数 をユーザー移行トリガーとして設定します。Lambda 関数の呼び出しと、独自のユーザープールのコンテキスト内でのみの実行を、Amazon Cognito サービスアカウントプリンシパルである `cognito-idp.amazonaws.com` のみに許可する認可ポリシーを Lambda 関数に追加します。詳細については、「[AWS Lambda のリソースベースのポリシーを使用する (Lambda 関数ポリシー)](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html)」を参照してください。

**サインインプロセス**

1. ユーザーがアプリケーションを開き、Amazon Cognito ユーザープール API またはマネージドログインを使用してサインインします。Amazon Cognito API でサインインを容易にする方法の詳細については、「[Amazon Cognito の認証と認可を、ウェブアプリケーションとモバイルアプリケーションに統合する](cognito-integrate-apps.md)」を参照してください。

1. アプリケーションはユーザー名とパスワードを Amazon Cognito に送信します。アプリに AWS SDK で構築したカスタムサインイン UI がある場合、アプリは `USER_PASSWORD_AUTH`または `ADMIN_USER_PASSWORD_AUTH`フローで [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) を使用する必要があります。アプリがこれらのフローのいずれかを使用する場合、SDK はパスワードをサーバーに送信します。
**注記**  
ユーザー移行トリガーを追加する前に、アプリケーションクライアントの設定で `USER_PASSWORD_AUTH` または `ADMIN_USER_PASSWORD_AUTH` フローを有効化します。デフォルトの `USER_SRP_AUTH`フロー の代わりにこれらのフローを使用する必要があります。Amazon Cognito は、他のディレクトリでのユーザーの認証を検証できるように、Lambda 関数にパスワードを送信する必要があります。SRP は、Lambda 関数からユーザーのパスワードを隠します。

1. Amazon Cognito は、送信されたユーザー名がユーザープール内のユーザー名またはエイリアスと一致するかどうかをチェックします。ユーザーの電子メールアドレス、電話番号、または優先ユーザー名を、ユーザープールのエイリアスとして設定できます。ユーザーが存在しない場合、Amazon Cognito は、ユーザー名やパスワードなどのパラメータを [ユーザー移行の Lambda トリガー](user-pool-lambda-migrate-user.md) 関数に送信します。

1. [ユーザー移行の Lambda トリガー](user-pool-lambda-migrate-user.md) 関数は、既存のユーザーディレクトリまたはユーザーデータベースを使用してユーザーをチェックまたは認証します。この関数は、Amazon Cognito がユーザープールのユーザープロファイルに保存するユーザー属性を返します。送信されたユーザー名がエイリアス属性と一致する場合にのみ、`username` パラメータを返します。ユーザーが既存のパスワードを引き続き使用できるようにする場合は、Lambda レスポンスで属性 `finalUserStatus` を `CONFIRMED` に設定します。アプリケーションは、[ユーザー移行の Lambda トリガーのパラメータ](user-pool-lambda-migrate-user.md#cognito-user-pools-lambda-trigger-syntax-user-migration) に示されるすべての `"response"` パラメータを返す必要があります。
**重要**  
リクエストイベントオブジェクト全体をユーザー移行 Lambda コードに記録しないでください。このリクエストイベントオブジェクトには、ユーザーのパスワードが含まれます。ログをサニタイズしない場合、パスワードが CloudWatch Logs に表示されます。

1. Amazon Cognito はユーザープールにユーザープロファイルを作成し、トークンをアプリケーションクライアントに返します。

1. アプリケーションはトークンの取り込みを実行し、ユーザー認証を受け入れ、リクエストされたコンテンツに進みます。

ユーザーを移行したら、`USER_SRP_AUTH` を使用してサインインします。Secure Remote Password (SRP) プロトコルは、パスワードをネットワーク上に送信しないため、移行時に使用する `USER_PASSWORD_AUTH` フローよりもセキュリティ上の利点が大きくなります。

移行中にクライアントデバイスやネットワークの問題などのエラーが発生した場合、アプリケーションは Amazon Cognito ユーザープール API からエラーレスポンスを受け取ります。この場合 Amazon Cognito はユーザープールにユーザーアカウントを作成しない可能性があります。その後、ユーザーは再度サインインを試行する必要があります。サインインが繰り返し失敗した場合、アプリケーションでパスワードを忘れた場合のフローを使用してユーザーのパスワードをリセットする必要があります。

パスワードを忘れた場合のフローでは、`UserMigration_ForgotPassword` イベントソースを使用して [ユーザー移行の Lambda トリガー](user-pool-lambda-migrate-user.md) 関数も呼び出します。ユーザーはパスワードのリセットをリクエストしてもパスワードを送信しないため、Amazon Cognito は Lambda 関数に送信するイベントにパスワードを含めません。関数では、既存のユーザーディレクトリ内のユーザーのみを検索し、ユーザープールのユーザープロファイルに追加する属性を返すことができます。関数が呼び出しを完了して Amazon Cognito に応答を返すと、ユーザープールはパスワードリセットコードを E メールまたは SMS で送信します。アプリケーションで、ユーザーに確認コードと新しいパスワードの入力を促し、その情報を [ConfirmForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html) API リクエストで Amazon Cognito に送信します。。マネージドログインでは、[パスワードを忘れた場合] フロー用の組み込みページを使用することもできます。

**その他のリソース**
+ [Amazon Cognito ユーザープールへのユーザー移行方法](https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools/)

# CSV ファイルからユーザープールへのユーザーのインポート
<a name="cognito-user-pools-using-import-tool"></a>

外部 ID ストアがあり、かつ、新しいローカルユーザーのためにユーザープールを準備する時間がある場合、カンマ区切り値 (CSV) ファイルからの一括ユーザーインポートは、Amazon Cognito ユーザープールへの移行のための手間とコストが少ないオプションになります。CSV ファイルインポートは、テンプレートファイルをダウンロードして入力し、インポートジョブのユーザープールにファイルを渡すプロセスです。CSV インポートを使用して、テストユーザーをすばやく作成できます。また、外部 ID ストアへの読み取り API リクエストをプログラムでファイルに入力したうえで、その詳細と属性を解析してファイルへの書き込みオペレーションにすることもできます。

インポートプロセスは、[**パスワード**] 以外のすべてのユーザー属性の値を設定します。セキュリティのベストプラクティスでは、パスワードはプレーンテキスト形式として使用できない必要があり、ハッシュのインポートはサポートされていないため、パスワードのインポートはサポートされません。つまり、ユーザーは最初にサインインした際にパスワードを変更する必要があります。このメソッドを使用してインポートすると、ユーザーは `RESET_REQUIRED` 状態になります。

CSV からユーザーをインポートする最も簡単な方法は、ユーザープールで [[パスワードなしのサインイン]](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless) を有効にすることです。E メールアドレスと電話番号の属性、さらにユーザープールの適切な設定により、ユーザーはインポートジョブの完了直後に E メールまたは SMS ワンタイムパスワード (OTP) を使用してサインインできます。詳細については、「[インポートされたユーザーにパスワードをリセットするように要求](#cognito-user-pools-using-import-tool-password-reset)」を参照してください。

[https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html) API リクエストで `Permanent` パラメータを `true` に設定することで、ユーザーのパスワードを設定することもできます。CSV インポートは、ユーザープール内で請求対象の月間アクティブユーザー (MAU) にはカウントされません。ただし、パスワードリセットオペレーションは MAU を発生させます。パスワードを使用する多数のユーザーをインポートしてもすぐにはアクティブにならない場合、コストを管理するには、ユーザーがサインインして `RESET_REQUIRED` チャレンジを受け取ったときに、新しいパスワードの入力を求めるようにアプリケーションを設定します。

**注記**  
各ユーザーの作成日は、ユーザーがユーザープールにインポートされた時間です。作成日は、インポートされた属性の 1 つではありません。

**ユーザーインポートジョブを作成する手順**

1.  AWS Identity and Access Management (IAM) コンソールで Amazon CloudWatch Logs ロールを作成します。

1. ユーザーインポート .csv ファイルを作成します。

1. ユーザーインポートジョブを作成し、実行します。

1. ユーザーインポート .csv ファイルをアップロードします。

1. ユーザーインポートジョブを起動し、実行します。

1. CloudWatch を使用してイベントログを確認します。

1. インポートされたユーザーがパスワードをリセットするように要求します。

**その他のリソース**
+ ユーザープール間でのユーザーアカウントのエクスポートに関する「[Cognito User Profiles Export リファレンスアーキテクチャ](https://aws.amazon.com/solutions/implementations/cognito-user-profiles-export-reference-architecture/)」

**Topics**
+ [CloudWatch Logs IAM ロールの作成](#cognito-user-pools-using-import-tool-cli-cloudwatch-iam-role)
+ [ユーザーインポート CSV ファイルの作成](#cognito-user-pools-using-import-tool-csv-header)
+ [Amazon Cognito ユーザープールのインポートジョブの作成と実行](#cognito-user-pools-creating-import-job)
+ [ユーザープールのインポート結果を CloudWatch コンソールに表示](#cognito-user-pools-using-import-tool-cloudwatch)
+ [インポートされたユーザーにパスワードをリセットするように要求](#cognito-user-pools-using-import-tool-password-reset)

## CloudWatch Logs IAM ロールの作成
<a name="cognito-user-pools-using-import-tool-cli-cloudwatch-iam-role"></a>

Amazon Cognito の CLI または API を使用している場合は、CloudWatch IAM ロールを作成する必要があります。以下の手順では、Amazon Cognito がインポートジョブの結果を CloudWatch Logs に書き込むために使用できる IAM ロールを作成する方法について説明します。

**注記**  
Amazon Cognito コンソールでインポート ジョブを作成すると、同時に IAM ロールを作成できます。**新しい IAM ロールを作成する**ことを選択すると、Amazon Cognito は適切な信頼ポリシーと IAM ポリシーをロールに自動的に適用します。

**ユーザープールインポート用の CloudWatch Logs IAM ロールを作成するには (AWS CLI、API)**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。

1. の新しい IAM ロールを作成します AWS のサービス。詳しい手順については、「*AWS Identity and Access Management ユーザーガイド*」の「[AWS のサービス用ロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html#roles-creatingrole-service-console)」を参照してください。

   1. **信頼されたエンティティタイプ**の**ユースケース**を選択するときは、任意のサービスを選択してください。Amazon Cognito は現在、サービスのユースケースに記載されていません。

   1. **[Add permissions]** (アクセス許可の追加) 画面で、**[Create policy]** (ポリシーの作成) を選択し、次のポリシーステートメントを挿入します。*REGION* を、 などのユーザープール AWS リージョン の に置き換えます`us-east-1`。*ACCOUNT* を AWS アカウント ID に置き換えます (`111122223333` など)。

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "logs:CreateLogGroup",
                      "logs:CreateLogStream",
                      "logs:DescribeLogStreams",
                      "logs:PutLogEvents"
                  ],
                  "Resource": [
                      "arn:aws:logs:us-east-1:111122223333:log-group:/aws/cognito/*"
                  ]
              }
          ]
      }
      ```

------

1. ロールを作成したときに Amazon Cognito を信頼されたエンティティとして選択しなかったため、ロールの信頼関係を手動で編集する必要があります。IAM コンソールのナビゲーションペインから **[Roles]** (ロール) を選択し、作成した新しいロールを選択します。

1. **[信頼関係]** タブを選択します。

1. **[Edit trust policy]** (信頼ポリシーを編集) を選択します。

1. 次のポリシーステートメントを **[Edit trust policy]** (信頼ポリシーを編集) に貼り付け、既存のテキストを置き換えます。

------
#### [ JSON ]

****  

   ```
   {
           "Version":"2012-10-17",		 	 	 
           "Statement": [
               {
                   "Effect": "Allow",
                   "Principal": {
                       "Service": "cognito-idp.amazonaws.com"
                   },
                   "Action": "sts:AssumeRole"
               }
           ]
       }
   ```

------

1. [**ポリシーの更新**] を選択してください。

1. ロールの ARN を書き留めておきます。インポートジョブを作成するときに、ARN を指定します。

## ユーザーインポート CSV ファイルの作成
<a name="cognito-user-pools-using-import-tool-csv-header"></a>

既存のユーザーをユーザープールにインポートする前に、インポートするユーザーとその属性を含むカンマ区切り値 (CSV) ファイルを作成する必要があります。ユーザープールから、ユーザープールの属性スキーマを反映するヘッダーを含むユーザーインポートファイルを取得できます。その後、[CSV ファイルのフォーマット](#cognito-user-pools-using-import-tool-formatting-csv-file) のフォーマット要件に一致するユーザー情報を挿入できます。

### CSV ファイルヘッダーのダウンロード (コンソール)
<a name="cognito-user-pools-using-import-tool-downloading-csv-header-console"></a>

CSV ヘッダーファイルをダウンロードするには、次の手順に従います。

**CSV ファイルヘッダーをダウンロードするには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。 AWS 認証情報の入力を求められる場合があります。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[ユーザー]** メニューを選択します。

1. **[Import users]** (ユーザーのインポート) セクションで、**[Create an import job]** (インポートジョブの作成) を選択します。

1. **[Upload CSV]** (CSV のアップロード) で *[template.csv]* リンクを選択し、CSV ファイルをダウンロードします。

### CSV ファイルヘッダーのダウンロード (AWS CLI)
<a name="cognito-user-pools-using-import-tool-downloading-csv-header-using-cli"></a>

正しいヘッダーのリストを取得するには、**[ユーザー]** メニューの **[ユーザーをインポート]** で、**[インポートジョブを作成]** を選択します。表示されるダイアログで `template.csv` リンクを選択し、ユーザープール属性を含むテンプレートファイルをダウンロードします。

次の CLI コマンドを実行することもできます。*USER\$1POOL\$1ID* は、ユーザーをインポートする先のユーザープールのユーザープール識別子です。

```
aws cognito-idp get-csv-header --user-pool-id "USER_POOL_ID"
```

レスポンス例:

```
{
    "CSVHeader": [
        "name",
        "given_name",
        "family_name",
        "middle_name",
        "nickname",
        "preferred_username",
        "profile",
        "picture",
        "website",
        "email",
        "email_verified",
        "gender",
        "birthdate",
        "zoneinfo",
        "locale",
        "phone_number",
        "phone_number_verified",
        "address",
        "updated_at",
        "cognito:mfa_enabled",
        "cognito:username"
    ],
    "UserPoolId": "USER_POOL_ID"
}
```

### CSV ファイルのフォーマット
<a name="cognito-user-pools-using-import-tool-formatting-csv-file"></a>

 ダウンロードしたユーザーインポート CSV ヘッダーファイルは次の文字列のようになります。ユーザープールに追加したカスタム属性も含まれます。

```
cognito:username,name,given_name,family_name,middle_name,nickname,preferred_username,profile,picture,website,email,email_verified,gender,birthdate,zoneinfo,locale,phone_number,phone_number_verified,address,updated_at,cognito:mfa_enabled
```

ユーザーのためのこのヘッダーと属性値が含まれ、次のルールに従ってフォーマットされているように CSV ファイルを編集します。

**注記**  
電話番号の適切な形式など属性値の詳細については、「[ユーザー属性の操作](user-pool-settings-attributes.md)」を参照してください。
+ ファイルの最初の行はユーザー属性の名前を含む、ダウンロードされたヘッダーの行です。
+ CSV ファイルの行の順序は重要ではありません。
+ 最初の行の後の各行に、ユーザーの属性値が含まれます。
+ ヘッダーのすべての列が存在している必要がありますが、列の値を指定する必要はありません。
+ 以下の属性は必須です:
  + **cognito:username**
  + [**email\$1verified**] または [**phone\$1number\$1verified**]
    + 自動確認された属性の少なくとも一つは、各ユーザーに対して `true` である必要があります。自動検証属性は、新しいユーザーがユーザープールに参加したときに Amazon Cognito が自動的にコードを送信する E メールアドレスまたは電話番号です。
    + ユーザープールは [**email\$1verified**] または [**phone\$1number\$1verified**] の少なくとも一つの自動確認された属性が必要です。ユーザープールに自動確認された属性が存在しない場合は、インポートジョブは開始されません。
    + ユーザープールに一つの自動確認された属性がある場合のみ、その属性はユーザーごとに確認する必要があります。たとえば、ユーザープールに自動確認された属性として [**phone\$1number**] だけがある場合、[**phone\$1number\$1verified**] 値はそれぞれのユーザーに対して `true` である必要があります。
**注記**  
ユーザーがパスワードをリセットするには、検証済みの E メールまたは電話番号が必要です。Amazon Cognito は、CSV ファイルで指定された E メールアドレスまたは電話番号にパスワードのリセットコードが含まれるメッセージを送信します。メッセージが電話番号に送信される場合は、SMS メッセージで送信されます。詳細については、「[サインアップ時に連絡先情報を検証する](signing-up-users-in-your-app.md#allowing-users-to-sign-up-and-confirm-themselves)」を参照してください。
  + [**email**] ([**email\$1verified**] が`true` の場合)
  + [**phone\$1number**] ([**phone\$1number**] が `true` の場合)
  + ユーザープールを作成する際に必須と指定した任意の属性
+ 文字列である属性値には、引用符は使用*できません*。
+ 属性値にカンマが含まれる場合、カンマの前にバックスラッシュ (\$1) を置く必要があります。これは、CSV ファイルのフィールドがカンマで区切られているためです。
+ CSV ファイルのコンテンツは、バイトオーダーマークのない UTF-8 形式にする必要があります。
+ [**cognito:username**] フィールドは必須であり、ユーザープール内で一意である必要があります。任意の Unicode 文字列を使えます。ただし、スペースまたはタブを含めることはできません。
+ **[birthdate]** (生年月日) の値がある場合、「**mm/dd/yyyy**」の形式である必要があります。たとえば、生年月日が 1985 年 2 月 1 日だとすると、**02/01/1985** にエンコードされる必要があります。
+ **cognito:mfa\$1enabled** フィールドは、ユーザープールの MFA 要件に対応している必要があります。ユーザープールで多要素認証 (MFA) を必須に設定している場合、このフィールドはすべてのユーザーに対して `true` または空白にする必要があります。MFA をオフに設定している場合、このフィールドはすべてのユーザーに対して `false` にする必要があります。空白の値により、インポートしたユーザーの MFA 対応ステータスは、ユーザープールが要求する状態に設定されます。`cognito:mfa_enabled` 値を設定したかどうかにかかわらず、有効な MFA 要素なしで、MFA を必須とするユーザープールにユーザーをインポートできます。この状態のユーザーは MFA がアクティブですが、E メール属性、電話番号属性、または TOTP を、ユーザープールの有効な MFA 要素として設定するまでサインインできません。
+ 最大行数は 16,000 文字です。
+ CSV ファイルの最大サイズは 100 MB です。
+ ファイルの最大行数 (ユーザー) は 500,000 です。この最大値にはヘッダー行は含まれません。
+ **[updated\$1at]** フィールド値はエポック時間 (秒) であると想定します。たとえば **1471453471** などです。
+ 属性値の先頭または末尾の空白は切り捨てられます。

次のリストは、カスタム属性のないユーザープールの CSV インポートファイルの例です。ユーザープールスキーマは、この例とは異なる場合があります。その場合は、ユーザープールからダウンロードした CSV テンプレートにテスト値を入力する必要があります。

```
cognito:username,name,given_name,family_name,middle_name,nickname,preferred_username,profile,picture,website,email,email_verified,gender,birthdate,zoneinfo,locale,phone_number,phone_number_verified,address,updated_at,cognito:mfa_enabled
John,,John,Doe,,,,,,,johndoe@example.com,TRUE,,02/01/1985,,,+12345550100,TRUE,123 Any Street,,FALSE
Jane,,Jane,Roe,,,,,,,janeroe@example.com,TRUE,,01/01/1985,,,+12345550199,TRUE,100 Main Street,,FALSE
```

## Amazon Cognito ユーザープールのインポートジョブの作成と実行
<a name="cognito-user-pools-creating-import-job"></a>

このセクションでは、Amazon Cognito コンソールと AWS Command Line Interface () を使用してユーザープールのインポートジョブを作成して実行する方法について説明しますAWS CLI。

**Topics**
+ [CSV ファイルからのユーザーのインポート (コンソール)](#cognito-user-pools-using-import-tool-console)
+ [ユーザーのインポート (AWS CLI)](#cognito-user-pools-using-import-tool-cli)

### CSV ファイルからのユーザーのインポート (コンソール)
<a name="cognito-user-pools-using-import-tool-console"></a>

次の手順は、CSV ファイルからユーザーをインポートする方法について説明します。

**CSV ファイルからユーザーをインポートするには (コンソール)**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。 AWS 認証情報の入力を求められる場合があります。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[ユーザー]** メニューを選択します。

1. **[Import users]** (ユーザーのインポート) セクションで、**[Create an import job]** (インポートジョブの作成) を選択します。

1. **[Create import job]** (インポートジョブの作成) ページで、**ジョブ名**を入力します。

1. **[Create a new IAM role]** (新しい IAM ロールの作成)、または**[Use an existing IAM role]** (既存のロールを使用する) を選択します。

   1. **[Create a new IAM role]** (新しい IAM ロールの作成) を選択した場合は、新しいロールの名前を入力します。Amazon Cognito は、正しいアクセス許可と信頼関係を持つロールを自動的に作成します。インポートジョブを作成する IAM プリンシパルに、IAM ロールを作成するアクセス許可が必要です。

   1. **[Use an existing IAM role]** (既存の IAM ロールを使用する) を選択した場合は、**[IAM role selection]** (IAM ロール選択) のリストからロールを選択します。このロールには、[CloudWatch Logs IAM ロールの作成](#cognito-user-pools-using-import-tool-cli-cloudwatch-iam-role) で説明されているアクセス許可と信頼ポリシーが必要です。

1. **[CSV をアップロード]** で **[ファイルを選択]** を選択し、準備した CSV ファイルをアタッチします。

1. **[Create job]** (ジョブの作成) を選択してジョブを送信しますが、後で開始します。**[Create and start job]** (ジョブを作成して開始) を選択してジョブを送信し、すぐに開始します。

1. ジョブを作成したが開始しなかった場合は、後で開始できます。**[ユーザー]** メニューの **[ユーザーをインポート]** で、インポートジョブを選択し、**[開始]** を選択します。 AWS SDK から [StartUserImportJob](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_StartUserImportJob.html) API リクエストを送信することもできます。

1. ユーザーインポートジョブの進行状況は、**[ユーザー]** メニューの **[ユーザーをインポート]** でモニタリングします。ジョブが成功しない場合は、**[Status]** (ステータス) 値を選択できます。詳細については、**[View the CloudWatch logs for more details]** (詳細については CloudWatch ログを表示する) を選択して、CloudWatch ログコンソールで問題がないか確認してください。

### ユーザーのインポート (AWS CLI)
<a name="cognito-user-pools-using-import-tool-cli"></a>

ユーザープールにユーザーをインポートするには、次の CLI コマンドが使用できます:
+ `create-user-import-job`
+ `get-csv-header`
+ `describe-user-import-job`
+ `list-user-import-jobs`
+ `start-user-import-job`
+ `stop-user-import-job`

これらのコマンドに関するコマンドラインオプションのリストを取得するには、`help` コマンドラインオプションを使用します。次に例を示します。

```
aws cognito-idp get-csv-header help
```

#### ユーザーインポートジョブの作成
<a name="cognito-user-pools-using-import-tool-cli-creating-user-import-job"></a>

CSV ファイルを作成した後、次の CLI コマンドを使用してユーザーインポートジョブを作成します。*[JOB\$1NAME]* にはジョブに付ける名前を指定します。*[USER\$1POOL\$1ID]* には以前と同じユーザープール ID を指定します。*[ROLE\$1ARN]* には、[CloudWatch Logs IAM ロールの作成](#cognito-user-pools-using-import-tool-cli-cloudwatch-iam-role) で次のとおり受け取ったロール ARN を指定します。

```
aws cognito-idp create-user-import-job --job-name "JOB_NAME" --user-pool-id "USER_POOL_ID" --cloud-watch-logs-role-arn "ROLE_ARN"
```

レスポンスで返される *PRE\$1SIGNED\$1URL* は 15 分間有効です。この時間以後は無効になり、新規のユーザーインポートジョブを作成して新しい URL を取得し直す必要があります。

**Example レスポンス:**  

```
{
    "UserImportJob": {
        "Status": "Created",
        "SkippedUsers": 0,
        "UserPoolId": "USER_POOL_ID",
        "ImportedUsers": 0,
        "JobName": "JOB_NAME",
        "JobId": "JOB_ID",
        "PreSignedUrl": "PRE_SIGNED_URL",
        "CloudWatchLogsRoleArn": "ROLE_ARN",
        "FailedUsers": 0,
        "CreationDate": 1470957431.965
    }
}
```

#### ユーザーインポートジョブのステータス値
<a name="cognito-user-pools-using-import-tool-cli-status-values-for-user-import-job"></a>

ユーザーインポートのコマンドに対する応答には、`Status` を示す次のような値が見つかります。
+ `Created` - ジョブが作成されましたが、開始前の状態です。
+ `Pending` - 遷移状態です。ジョブを開始しましたが、まだユーザーのインポートは開始していません。
+ `InProgress` - ジョブが開始され、ユーザーインポートが進行中です。
+ `Stopping` - ジョブを停止する処理中です。ユーザーインポートは停止していません。
+ `Stopped` - ジョブは停止中で、ユーザーインポートも停止しています。
+ `Succeeded` - ジョブは正常に完了しました。
+ `Failed` - エラーのためジョブは停止しました。
+ `Expired` - ジョブを作成しましたが、24 ～ 48 時間以内にジョブを起動しませんでした。ジョブに関連付けられたすべてのデータは削除され、ジョブを開始することはできません。

#### CSV ファイルのアップロード
<a name="cognito-user-pools-using-import-tool-cli-uploading-csv-file"></a>

以下の `curl` コマンドを使用して、ユーザーデータが含まれる CSV ファイルを `create-user-import-job` コマンドのレスポンスから取得した事前署名済みの URL にアップロードします。

```
curl -v -T "PATH_TO_CSV_FILE" -H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL"
```

このコマンドの出力から、次のようなメッセージを見つけます: `"We are completely uploaded and fine"` このメッセージは、ファイルが正常にアップロードされたことを示します。ユーザープールは、インポートジョブの実行後にインポートファイルに情報を保持しません。完了または期限切れになると、Amazon Cognito は、アップロードした CSV ファイルを削除します。

#### ユーザーインポートジョブの説明
<a name="cognito-user-pools-using-import-tool-cli-describing-user-import-job"></a>

ユーザーインポートジョブの説明を取得するには、次のコマンドを使用します。*USER\$1POOL\$1ID* はユーザープール ID です。*JOB\$1ID* は、ユーザーインポートジョブの作成時に返されたジョブ ID です。

```
aws cognito-idp describe-user-import-job --user-pool-id "USER_POOL_ID" --job-id "JOB_ID"
```

**Example レスポンス例:**  

```
{
    "UserImportJob": {
        "Status": "Created",
        "SkippedUsers": 0,
        "UserPoolId": "USER_POOL_ID",
        "ImportedUsers": 0,
        "JobName": "JOB_NAME",
        "JobId": "JOB_ID",
        "PreSignedUrl": "PRE_SIGNED_URL",
        "CloudWatchLogsRoleArn":"ROLE_ARN",
        "FailedUsers": 0,
        "CreationDate": 1470957431.965
    }
}
```

前述の例の出力では、*PRE\$1SIGNED\$1URL* は CSV のアップロード先の URL です。*ROLE\$1ARN* は、ロールの作成時に受け取った CloudWatch Logs ロール ARN です。

#### ユーザーインポートジョブを表示する
<a name="cognito-user-pools-using-import-tool-cli-listing-user-import-jobs"></a>

ユーザーインポートジョブを一覧表示するには、次のコマンドを使用します:

```
aws cognito-idp list-user-import-jobs --user-pool-id "USER_POOL_ID" --max-results 2
```

**Example レスポンス例:**  

```
{
    "UserImportJobs": [
        {
            "Status": "Created",
            "SkippedUsers": 0,
            "UserPoolId": "USER_POOL_ID",
            "ImportedUsers": 0,
            "JobName": "JOB_NAME",
            "JobId": "JOB_ID",
            "PreSignedUrl":"PRE_SIGNED_URL",
            "CloudWatchLogsRoleArn":"ROLE_ARN",
            "FailedUsers": 0,
            "CreationDate": 1470957431.965
        },
        {
            "CompletionDate": 1470954227.701,
            "StartDate": 1470954226.086,
            "Status": "Failed",
            "UserPoolId": "USER_POOL_ID",
            "ImportedUsers": 0,
            "SkippedUsers": 0,
            "JobName": "JOB_NAME",
            "CompletionMessage": "Too many users have failed or been skipped during the import.",
            "JobId": "JOB_ID",
            "PreSignedUrl":"PRE_SIGNED_URL",
            "CloudWatchLogsRoleArn":"ROLE_ARN",
            "FailedUsers": 5,
            "CreationDate": 1470953929.313
        }
    ],
    "PaginationToken": "PAGINATION_TOKEN"
}
```

ジョブは時系列で、作成が最後から最初の順で表示されます。2 番目のジョブのあとの *PAGINATION\$1TOKEN* 文字列は、このリストコマンドについて、まだ結果が残っていることを示します。残りの結果を表示するには、次のように `--pagination-token` オプションを使用します:

```
aws cognito-idp list-user-import-jobs --user-pool-id "USER_POOL_ID" --max-results 10 --pagination-token "PAGINATION_TOKEN"
```

#### ユーザーインポートジョブの開始
<a name="cognito-user-pools-using-import-tool-cli-starting-user-import-job"></a>

ユーザーインポートジョブを開始するには、次のコマンドを使用します:

```
aws cognito-idp start-user-import-job --user-pool-id "USER_POOL_ID" --job-id "JOB_ID"
```

インポートジョブは、アカウントごとに 1 つしかアクティブにできません。

**Example レスポンス例:**  

```
{
    "UserImportJob": {
        "Status": "Pending",
        "StartDate": 1470957851.483,
        "UserPoolId": "USER_POOL_ID",
        "ImportedUsers": 0,
        "SkippedUsers": 0,
        "JobName": "JOB_NAME",
        "JobId": "JOB_ID",
        "PreSignedUrl":"PRE_SIGNED_URL",
        "CloudWatchLogsRoleArn": "ROLE_ARN",
        "FailedUsers": 0,
        "CreationDate": 1470957431.965
    }
}
```

#### ユーザーインポートジョブの停止
<a name="cognito-user-pools-using-import-tool-cli-stopping-user-import-job"></a>

ユーザーインポートジョブの進行中に停止するには、次のコマンドを使用します。ジョブを停止すると、再開することはできません。

```
aws cognito-idp stop-user-import-job --user-pool-id "USER_POOL_ID" --job-id "JOB_ID"
```

**Example レスポンス例:**  

```
{
    "UserImportJob": {
        "CompletionDate": 1470958050.571,
        "StartDate": 1470958047.797,
        "Status": "Stopped",
        "UserPoolId": "USER_POOL_ID",
        "ImportedUsers": 0,
        "SkippedUsers": 0,
        "JobName": "JOB_NAME",
        "CompletionMessage": "The Import Job was stopped by the developer.",
        "JobId": "JOB_ID",
        "PreSignedUrl":"PRE_SIGNED_URL",
        "CloudWatchLogsRoleArn": "ROLE_ARN",
        "FailedUsers": 0,
        "CreationDate": 1470957972.387
    }
}
```

## ユーザープールのインポート結果を CloudWatch コンソールに表示
<a name="cognito-user-pools-using-import-tool-cloudwatch"></a>

インポートジョブの結果は、Amazon CloudWatch コンソールで表示できます。

**Topics**
+ [結果の表示](#cognito-user-pools-using-import-tool-viewing-the-results)
+ [結果の解釈](#cognito-user-pools-using-import-tool-interpreting-the-results)

### 結果の表示
<a name="cognito-user-pools-using-import-tool-viewing-the-results"></a>

次のステップでは、ユーザープールのインポートの結果を表示する方法を説明します。

**ユーザープールのインポート結果を見るには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) で CloudWatch コンソールを開きます。

1. [**ログ**] を選択します。

1. ユーザープールのインポートジョブに使用するロググループを選択します。ロググループ名は `/aws/cognito/userpools/USER_POOL_ID/USER_POOL_NAME` の形式です。

1. 先ほど実行したユーザーインポートジョブのログを選択します。ログ名は *JOB\$1ID*/*JOB\$1NAME* の形式です。ログの結果は行番号でユーザーを示しています。ユーザーデータはログに書き込まれていません。各ユーザーに対して、次のような行が表示されます。
   + `[SUCCEEDED] Line Number 5956 - The import succeeded.`
   + `[SKIPPED] Line Number 5956 - The user already exists.`
   + `[FAILED] Line Number 5956 - The User Record does not set any of the auto verified attributes to true. (Example: email_verified to true).`

### 結果の解釈
<a name="cognito-user-pools-using-import-tool-interpreting-the-results"></a>

正常にインポートしたユーザーは、ステータスが「PasswordReset」に設定済みです。

次の場合、ユーザーはインポートされませんが、インポートジョブは継続します。
+ `true` に設定された自動検証された属性はありません。
+ ユーザーデータはスキーマに一致しません。
+ 内部エラーによりユーザーをインポートできませんでした。

以下の場合、インポートジョブは失敗します。
+ Amazon CloudWatch Logs ロールを想定することができず、正しいアクセスポリシーがない、または削除されている。
+ ユーザープールが削除されている。
+ Amazon Cognito が .csv ファイルを解析できない。

## インポートされたユーザーにパスワードをリセットするように要求
<a name="cognito-user-pools-using-import-tool-password-reset"></a>

ユーザープールがパスワードベースのサインインのみを提供している場合、ユーザーはインポート後にパスワードをリセットする必要があります。初めてサインインするときは、*任意の*パスワードを入力できます。Amazon Cognito は、アプリケーションからのサインインリクエストに対する API レスポンスで、新しいパスワードを入力するようユーザーに求めます。

ユーザープールにパスワードなしの認証要素がある場合、Amazon Cognito はインポートしたユーザーに対してデフォルトでその認証要素を使用します。ユーザーは、新しいパスワードの入力を求められず、パスワードなしの E メールまたは SMS OTP ですぐにサインインできます。また、ユーザー名パスワードやパスキーなど、他のサインイン方法を完了できるように、ユーザーにパスワードの設定を求めることもできます。ユーザーインポート後のパスワードなしのサインインには、以下の条件が適用されます。

1. 使用可能なパスワードなしのサインイン要素に対応する属性を持つユーザーをインポートする必要があります。ユーザーが E メールアドレスでサインインできる場合は、`email` 属性をインポートする必要があります。電話番号の場合は、`phone_number` 属性をインポートする必要があります。両方の場合は、いずれかの属性の値をインポートします。

1. 通常、ユーザーはパスワードをリセットする必要がある `RESET_REQUIRED` 状態でインポートされます。パスワードなしの要素でサインインできる状態でインポートされた場合、Amazon Cognito はユーザーの状態を `CONFIRMED` に設定します。

パスワードなしの認証の設定方法や、その認証フローをアプリケーションで構築する方法などの詳細については、「[Amazon Cognito ユーザープールによる認証](authentication.md)」を参照してください。

次の手順では、CSV ファイルのインポート後、カスタム構築されたログインメカニズムにおける、`RESET_REQUIRED` のローカルユーザーのユーザーエクスペリエンスについて説明します。ユーザーがマネージドログインでサインインする場合は、**[パスワードを忘れた場合]** オプションを選択し、E メールまたはテキストメッセージに記載されているコードを入力してパスワードを設定するよう指示します。

**インポートされたユーザーにパスワードをリセットするように要求**

1. アプリケーションで、ランダムなパスワードを使用した `InitiateAuth` により、現在のユーザーのサインインをサイレントに試行します。

1. `PreventUserExistenceErrors` が有効な場合、Amazon Cognito は `NotAuthorizedException` を返します。そうでない場合は `PasswordResetRequiredException` を返します。

1. アプリケーションが `ForgotPassword` API リクエストを行い、ユーザーのパスワードをリセットします。

   1. アプリケーションは `ForgotPassword` API リクエストでユーザー名を送信します。

   1. Amazon Cognito は、確認済みの E メールまたは電話番号にコードを送信します。宛先は、CSV ファイルで `email_verified` と `phone_number_verified` に指定した値によって異なります。`ForgotPassword` リクエストへのレスポンスは、コードの宛先を示します。
**注記**  
ユーザープールは、E メールまたは電話番号を確認するように設定する必要があります。詳細については、「[ユーザーアカウントのサインアップと確認](signing-up-users-in-your-app.md)」を参照してください。

   1. アプリケーションは、コードがコードの送信先を確認するメッセージをユーザーに表示し、ユーザーにコードと新しいパスワードを入力するように求めます。

   1. ユーザーがアプリでコードと新しいパスワードを入力します。

   1. アプリケーションは `ConfirmForgotPassword` API リクエストでコードと新しいパスワードを送信します。

   1. アプリケーションはユーザーをサインインにリダイレクトします。

# ユーザー属性の操作
<a name="user-pool-settings-attributes"></a>

属性は、名前、E メールアドレス、電話番号など、個々のユーザーを識別できる各種情報です。新しいユーザープールにはデフォルトの*標準属性*のセットがあります。のユーザープール定義にカスタム属性を追加することもできます AWS マネジメントコンソール。このトピックでは、それらの属性について詳しく説明し、ユーザープールの設定のヒントを示します。

ユーザーに関するすべての情報を属性に保存しないでください。例えば、使用統計やゲームスコアなどの頻繁に変化するユーザーデータは、Amazon Cognito Sync または Amazon DynamoDB などの個別のデータストアに保存してください。

ユーザー属性文字列値の入力は、サニタイズしてから、ユーザープールに送信します。提案されたユーザー属性値を分析する 1 つの方法は、[サインアップ前](user-pool-lambda-pre-sign-up.md)などの Lambda トリガーを使用することです。

**注記**  
ドキュメントや標準によっては、属性を*メンバー*と呼んでいます。

**Topics**
+ [標準属性](#cognito-user-pools-standard-attributes)
+ [ユーザー名および優先ユーザー名](#user-pool-settings-usernames)
+ [ログイン属性のカスタマイズ](#user-pool-settings-aliases)
+ [カスタム属性](#user-pool-settings-custom-attributes)
+ [属性の権限と範囲](#user-pool-settings-attribute-permissions-and-scopes)

## 標準属性
<a name="cognito-user-pools-standard-attributes"></a>

Amazon Cognito は、[[OpenID Connect の仕様]](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) に基づいて、以下の標準属性セットをすべてのユーザーに割り当てます。標準属性値およびカスタム属性値は、デフォルトでは最大 2048 文字の任意の文字列ですが、一部の属性値には形式の制限があります。

標準属性は以下のとおりです。
+ `name`
+ `family_name`
+ `given_name`
+ `middle_name`
+ `nickname`
+ `preferred_username`
+ `profile`
+ `picture`
+ `website`
+ `gender`
+ `birthdate`
+ `zoneinfo`
+ `locale`
+ `updated_at`
+ `address`
+ `email`
+ `phone_number`
+ `sub`

`sub` を除き、標準属性はすべてのユーザーに対してデフォルトでオプションとなります。属性を必須にする場合は、ユーザープールの作成プロセスで、属性の横にある **[必須]** チェックボックスをオンにします。Amazon Cognito は、各ユーザーの `sub` 属性に一意のユーザー識別子の値を割り当てます。検証できるのは **E メールと** **phone\$1number** 属性だけです。

標準属性には、[DescribeUserPool API レスポンス](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPool.html#API_DescribeUserPool_ResponseSyntax)の `SchemaAttributes` パラメータで表示できる事前定義されたプロパティがあります。データ型、ミュータビリティ、長さの制約など、これらの属性プロパティのカスタム値を設定できます。標準属性プロパティを変更するには、[CreateUserPool スキーマパラメータ](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-Schema)でカスタム値を設定します。スキーマでは、必須の属性も設定できます。Amazon Cognito コンソールでユーザープールを作成するときに、標準属性のプロパティは変更できません。

**注記**  
 標準属性を**必須**とマークすると、ユーザーは、属性の値が指定されない限り登録することはできません。ユーザーを作成し、必須属性の値を指定しないようにするには、管理者は[AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html) API を使用できます。ユーザープールを作成した後で、属性を必須と必須ではないの間で切り替えることができません。標準属性の詳細と形式の制限

**birthdate**  
値は、YYYY-MM-DD 形式で有効な 10 文字の日付にする必要があります。

**E メール**  
ユーザーおよび管理者は、E メールアドレスの値を確認できます。  
適切な AWS アカウント アクセス許可を持つ管理者は、ユーザーの E メールアドレスを変更し、検証済みとしてマークすることもできます。[AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) API または [admin-update-user-attributes](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/admin-update-user-attributes.html) AWS Command Line Interface (AWS CLI) コマンドを使用して、E メールアドレスを検証済みとしてマークします。このコマンドを使用すると、管理者は`email_verified` 属性を `true` に変更できます。Amazon Cognito コンソールの **[ユーザー]** メニューでユーザーを編集して、E メールアドレスを検証済みとしてマークすることもできます。  
値は、[有効な E メールアドレス文字列](https://datatracker.ietf.org/doc/html/rfc3696#section-3)とし、@ 記号とドメインを含む標準の E メール形式に従い、長さは 2,048 文字までで指定します。

**phone\$1number**  
SMS 多要素認証 (MFA) がアクティブである場合、ユーザーは電話番号を入力する必要があります。詳細については、「[ユーザープールに MFA を追加します](user-pool-settings-mfa.md)」を参照してください。  
ユーザーおよび管理者は、電話番号の値を確認できます。  
適切な AWS アカウント アクセス許可を持つ管理者は、ユーザーの電話番号を変更し、検証済みとしてマークすることもできます。[AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) API または [admin-update-user-attributes](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/admin-update-user-attributes.html) AWS CLI コマンドを使用して、電話番号を検証済みとしてマークします。このコマンドを使用すると、管理者は`phone_number_verified` 属性を `true` に変更できます。Amazon Cognito コンソールの **[ユーザー]** メニューでユーザーを編集して、電話番号を検証済みとしてマークすることもできます。  
電話番号は次の形式に従う必要があります: 電話番号は、プラス記号 (**\$1**) から始めて国番号がその後に続く必要があります。電話番号には、プラス記号 (**\$1**) および数値のみを含めることができます。値をサービスに送信する前に、電話番号から括弧、スペース、ハイフン (**-**) などの他の文字を削除してください。例えば、米国の電話番号は **\$114325551212** の形式に従っています。

**preferred\$1username**  
`preferred_username` は、必要に応じて、またはエイリアスとして選択できますが、両方を選択することはできません。`preferred_username` がエイリアスである場合、ユーザーの確認後に [UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html) API オペレーションをリクエストして属性値を追加できます。

**sub**  
`sub` 属性に基づいてユーザーをインデックス化して検索します。`sub` 属性は、各ユーザープール内で一意のユーザー識別子です。ユーザーは `phone_number` や `email` などの属性を変更できます。`sub` 属性には固定値が含まれています。ユーザーの検索の詳細については、「[ユーザーアカウントの管理と検索](how-to-manage-user-accounts.md)」を参照してください。

### 必須属性を表示する
<a name="how-to-edit-standard-attributes"></a>

以下の手順に従って、特定のユーザープールに必要な属性を表示します。

**注記**  
ユーザープールを作成した後は、必須の属性を変更することはできません。

**必須属性を表示する**

1. の[Amazon Cognito](https://console.aws.amazon.com/cognito/home)」に移動します AWS マネジメントコンソール。コンソールでプロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[サインアップ]** メニューを選択します。

1. **[Required attributes]** (必須の属性) セクションで、ユーザープールの必須属性が表示されます。

## ユーザー名および優先ユーザー名
<a name="user-pool-settings-usernames"></a>

`username` 値は個別の属性であり、`name` 属性とは異なります。各ユーザーには、`username` 属性があります。Amazon Cognito は、フェデレーティッドユーザーのユーザー名を自動的に生成します。Amazon Cognito ディレクトリにローカルユーザーを作成するには、`username` 属性を指定する必要があります。ユーザーを作成した後で、`username` 属性の値を変更することはできません。

デベロッパーは、`preferred_username` 属性を使用して、変更可能なユーザー名をユーザーに付与できます。詳細については、「[ログイン属性のカスタマイズ](#user-pool-settings-aliases)」を参照してください。

お客様のアプリケーションでユーザー名が不要の場合は、ユーザーにユーザー名を指定するように求める必要はありません。アプリでユーザー用の一意のユーザー名をバックグラウンドで作成できます。例えば、E メールアドレスとパスワードを登録しそれを使用してサインインするようにユーザーに求める場合は便利です。詳細については、「[ログイン属性のカスタマイズ](#user-pool-settings-aliases)」を参照してください。

`username` はユーザープール内で一意である必要があります。`username` は再利用できますが、削除されて使用されなくなった場合のみです。`username` 属性に対する文字列制約については、[SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html#CognitoUserPools-SignUp-request-Username) API リクエストの *username* プロパティを参照してください。

## ログイン属性のカスタマイズ
<a name="user-pool-settings-aliases"></a>

ユーザープールを作成するときに、ユーザーが e メールアドレスまたは電話番号をユーザー名として使用してサインアップおよびサインインできるようにする場合は、*ユーザー名属性*を設定できます。また、*エイリアス属性*を設定してユーザーに選択肢を与えることもできます。サインアップするときに複数の属性を含めて、ユーザー名、優先ユーザー名、E メールアドレス、または電話番号でサインインできます。

**重要**  
ユーザープールを作成した後は、この設定を変更することはできません。

### エイリアス属性とユーザー名属性の選択方法
<a name="user-pool-settings-aliases-settings"></a>


| 要件 | エイリアス属性 | ユーザー名属性 | 
| --- |--- |--- |
| Users have multiple sign-in attributes | Yes¹ | No² | 
| Users must verify email address or phone number before they can sign in with it | Yes | No | 
| Sign up users with duplicate email addresses or phone numbers and prevent UsernameExistsException errors³ | Yes | No | 
| Can assign the same email address or phone number attribute value to more than one user | Yes⁴ | No | 

¹ 使用可能なサインイン属性は、ユーザー名、E メールアドレス、電話番号、および優先ユーザー名です。

² E メールアドレスまたは電話番号を使用してサインインできます。

³ ユーザーが登録したメールアドレスや電話番号が重複している可能性があるが、ユーザー名がない場合、ユーザープールで `UsernameExistsException` エラーが生成されません。この動作は**ユーザー名存在エラーを防ぐ**とは無関係です。これはサインイン操作には適用されますが、サインアップ操作には適用されません。

⁴ 属性を確認した最後のユーザーのみが、その属性を使用してサインインできます。

#### オプション 1: 複数のログイン属性 (エイリアス属性)
<a name="user-pool-settings-aliases-settings-option-1"></a>

ユーザーがユーザー名だけでなく別の属性でもサインインできる場合、その属性は*エイリアス*になります。ユーザーがサインインフォームのユーザー名フィールドでユーザー名と他の属性値から選択できるようにする場合は、エイリアスを設定します。`username` 属性は、ユーザーが変更できない固定値です。属性をエイリアスとしてマーキングすると、ユーザーはユーザー名の代わりにその属性を使用してサインインできます。E メールアドレス、電話番号、および任意ユーザー名属性は、エイリアスレコードとしてマーキングできます。例えば、E メールと電話をユーザープールのエイリアスとして選択すると、そのユーザープールのユーザーは、自分のユーザー名、E メールアドレス、または電話番号とパスワードを使ってサインインできます。

エイリアス属性を選択するには、ユーザープールを作成するときに **[User name]** (ユーザー名) と 1 つ以上の追加のサインインオプションを選択します。

**注記**  
大文字と小文字を区別しないようにユーザープールを設定すると、ユーザーは小文字または大文字を使用してサインアップ、またはエイリアスを使用してサインインできるようになります。詳細については、*Amazon Cognito API リファレンス*の「[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html)」を参照してください。

エイリアスとして E メールアドレスを選択した場合、Amazon Cognito は有効な E メールアドレス形式と一致するユーザー名を受け入れません。同様に、電話番号をエイリアスとして選択した場合、Amazon Cognito は、有効な電話番号形式に一致するユーザープールのユーザー名を受け入れません。

**注記**  
エイリアス値は、ユーザープール内で一意にする必要があります。エイリアスがメールアドレスまたは電話番号に設定される場合、指定される値は 1 つのアカウントのみで検証状態になります。サインアップ時に E メールアドレスまたは電話番号をエイリアス値として指定し、別のユーザーがそのエイリアス値を既に使用している場合、登録は成功します。ただし、ユーザーがこの E メール (または電話番号) を持つアカウントを確認して有効なコードを入力しようとする場合、Amazon Cognito は、`AliasExistsException` エラーを返します。エラーは、この E メールアドレス (または電話番号) を持つアカウントが既に存在していることを示します。この時点で、ユーザーは新しいアカウントの作成を中止して、古いアカウントのパスワードのリセットを試すことができます。ユーザーが新しいアカウントの作成を続行する場合は、アプリは `forceAliasCreation` オプションを使用して `ConfirmSignUp` API を呼び出す必要があります。`forceAliasCreation` を使用する `ConfirmSignUp` は、エイリアスを前のアカウントから新しく作成されたアカウントに移動し、前のアカウントで未確認の属性をマークします。

ユーザーが電話番号および E メールアドレスを確認した後、電話番号および E メールアドレスのみがユーザーのアクティブエイリアスになります。エイリアスとしてこれらを使用する場合は、E メールアドレスと電話番号の自動確認を選択することをお勧めします。

ユーザーがサインアップするときに、E メールアドレスおよび電話番号の属性の `UsernameExistsException` エラーを防ぐために、エイリアス属性を選択します。

`preferred_username` 属性をアクティブにして、`username` 属性値が変更されていないときに、ユーザーがサインインに使用するユーザー名を変更できるようにします。このユーザーエクスペリエンスをセットアップする場合は、新しい `username` 値を `preferred_username` として送信し、エイリアスとして `preferred_username` を選択します。こうすることで、ユーザーは入力した新しい値でサインインできます。`preferred_username` がエイリアスとして選択された場合、ユーザーはアカウントが確認されている場合にのみ、値を指定できます。登録時にはこの値は指定できません。

ユーザーがユーザー名を使用してサインアップする場合、ユーザーが次の 1 つ以上のエイリアスを使用してサインインできるかどうかを選択できます。
+ 検証済みの E メールアドレス
+ 検証済みの電話番号
+ 優先ユーザー名

これらのエイリアスはユーザーがサインアップした後に変更できます。

**重要**  
ユーザープールがエイリアスによるサインインをサポートしている場合、ユーザーを認可または検索するときに、サインイン属性のいずれかを使用してユーザーを特定することは避けてください。固定値のユーザー識別子 `sub` は、ユーザーのアイデンティティを示す唯一の一貫した指標です。

エイリアスを使用してサインインできるように、ユーザープールを作成する場合は、次の手順を含めます。

------
#### [ Phone number or email address (console) ]

ユーザープールの作成時に、E メールアドレスと電話番号をエイリアス属性として設定する必要があります。

**Amazon Cognito コンソールでユーザー名エイリアスを使用してユーザープールを作成するには**

1.  AWS マネジメントコンソールの [Amazon Cognito](https://console.aws.amazon.com/cognito/home) に移動します。コンソールでプロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[開始方法]** ボタンまたは **[ユーザープールを作成]** ボタンを使用して、新しいユーザープールを作成します。

1. **[アプリケーションを定義]** でアプリケーション設定を選択します。

1. **[サインイン識別子のオプション]** の **[オプションを設定]** で、**[ユーザー名]**の横のチェックボックスをオンにします。さらに他のオプション (**[E メール]** と **[電話番号]**) を 1 つ以上選択します。

1. エイリアス属性を **[サインアップのための必須属性]** として選択します。Amazon Cognito は、マネージドログインのサインアップフォームで必須属性の値を指定するよう新規ユーザーに求めます。

1. マネージドログインのサインイン後に、**[リターン URL を追加]** で、アプリケーションからリダイレクトするためのコールバック URL を設定します。

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

------
#### [ Phone number or email address (API/SDK) ]

[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API オペレーションを使用して新しいユーザープールを作成します。次のように `AliasAttributes` パラメータを設定します。電話番号エイリアスのみが必要な場合は、`email` エントリを削除できます。E メールアドレスエイリアスのみが必要な場合は、`phone_number` エントリを削除できます。

```
"AliasAttributes": [
   "email",
   "phone_number"
],
```

------
#### [ Preferred username (API/SDK) ]

Amazon Cognito コンソールは、エイリアスとして `preferred_username` を使用せずに、ユーザープールを作成します。エイリアスを使用してユーザープールを作成するには、 AWS SDK `preferred_username` で [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API リクエストを使用してユーザープールを設定します。サインアップ時に任意のユーザー名属性を作成できるようにするには、`preferred_username` を必須属性として設定します。Amazon Cognito は、マネージドログインのサインアップフォームで必須属性の値を指定するよう新規ユーザーに求めます。Amazon Cognito コンソールでは `preferred_username` を必須属性として設定することは*可能*ですが、エイリアスとして使用することはできません。

**エイリアスとして設定する**  
次に示すように、`CreateUserPool` リクエストの `AliasAttributes` パラメータで、`preferred_username` をエイリアスとして設定します。エイリアス属性として使用しない値は、リストから削除します。

```
"AliasAttributes": [
   "email",
   "phone_number",
   "preferred_username"
],
```

**必須として設定する**  
Amazon Cognito は、マネージドログインのサインアップフォームで必須属性の値を指定するよう新規ユーザーに求めます。[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) リクエストの `SchemaAttributes` パラメータで、`preferred_username` を必須として設定します。

任意のユーザー名を必須属性として設定するには、次に示すように設定します。次の例では、`preferred_username` のデフォルトスキーマを変更して、必須として設定しています。`AttributeDataType` (デフォルトは `string`) や `StringAttributeConstraints` (デフォルトは 1～99 文字) など、他のスキーマパラメータは、デフォルト値を使用します。

```
"Schema": [
   {
      "Name": "preferred_username",
      "Required": true
   }
]
```

------

#### オプション 2: サインイン属性 (ユーザー名属性) としての E メールアドレスまたは電話番号
<a name="user-pool-settings-aliases-settings-option-2"></a>

ユーザー名として E メールアドレスまたは電話番号でユーザーがサインアップする場合、E メールアドレスのみ、電話番号のみ、またはいずれか一方でもサインアップできるようにするかを選択することができます。

ユーザー名属性を選択するには、ユーザープールの作成時に、**[ユーザー名]** をサインインオプションとして選択しないでください。

E メールまたは電話番号は一意である必要があり、別のユーザーによって既に使用されていてはなりません。これを検証する必要はありません。ユーザーが E メールアドレスまたは電話番号を使用してサインアップした後、ユーザーは同じ E メールアドレスまたは電話番号を使用して新しいアカウントを作成することはできません。ユーザーは既存のアカウントを (必要に応じてパスワードをリセットして) 再利用できるだけです。ただし、ユーザーは E メールアドレスまたは電話番号を新しい E メールアドレスまたは電話番号に変更できます。E メールアドレスまたは電話番号が既に使用中ではない場合は、それが新しいユーザー名となります。

E メールアドレスと電話番号の両方をユーザー名属性として選択した場合、ユーザーは両方の属性値を指定できますが、サインインに使用できるのはいずれか一方のみです。サインインユーザー名は、[SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html#CognitoUserPools-SignUp-request-Username) の `Username` パラメータで渡した値に基づいて決まります。

**注記**  
ユーザーが E メールアドレスをユーザー名として使用してサインアップした場合、ユーザー名を別の E メールアドレスに変更できますが、電話番号に変更することはできません。電話番号でサインアップする場合は、ユーザー名を別の電話番号を変更できますが、E メールアドレスに変更することはできません。

次のステップを使用して、ユーザープール作成のプロセス中に、E メールアドレスまたは電話番号を使用したサインアップおよびサインインをセットアップします。

------
#### [ Username attributes (console) ]

次の手順では、E メールアドレスまたは電話番号をユーザー名属性とするユーザープールを作成します。Amazon Cognito コンソールでのユーザー名属性のプロセスの違いは、**ユーザー名**をサインイン属性として設定しないことです。

**Amazon Cognito コンソールでユーザー名属性を持つユーザープールを作成するには**

1.  AWS マネジメントコンソールの [Amazon Cognito](https://console.aws.amazon.com/cognito/home) に移動します。コンソールでプロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[開始方法]** ボタンまたは **[ユーザープールを作成]** ボタンを使用して、新しいユーザープールを作成します。

1. **[アプリケーションを定義]** でアプリケーション設定を選択します。

1. **[サインイン識別子のオプション]** の **[オプションを設定]** で、ユーザー名属性として **[E メール]**、**[電話番号]**、または両方を選択します。**[ユーザー名]** は、オフのままにします。

1. ベストプラクティスとして、ユーザー名属性を **[サインアップのための必須属性]** として選択します。Amazon Cognito は、マネージドログインのサインアップフォームで必須属性の値を指定するよう新規ユーザーに求めます。ユーザー名属性を必須として設定しない場合、Amazon Cognito は新規ユーザーに属性値の入力を求めません。この場合は、ユーザーがサインインする前に、各ユーザーの E メールアドレスまたは電話番号を収集して送信するようにアプリケーションを設定する必要があります。

1. マネージドログインのサインイン後に、**[リターン URL を追加]** で、アプリケーションからリダイレクトするためのコールバック URL を設定します。

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

------
#### [ Username attributes (API/SDK) ]

[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) リクエストで、次に示すように `UsernameAttributes` パラメータを設定します。E メールアドレスのみをユーザー名としてサインインすることを許可するには、このリストで `email` のみを指定します。電話番号のみをユーザー名としてサインインすることを許可するには、`phone_number` のみを指定します。このパラメータは、サインインオプションとしてのユーザー名をオーバーライドします。

```
"UsernameAttributes": [ 
   "email",
   "phone_number"
],
```

------

ユーザー名属性を設定すると、[SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) API リクエストにより、`username` パラメータで E メールアドレスまたは電話番号を渡すことができます。ユーザー名属性を使用したコード `SignUp` API オペレーションの動作は、以下のとおりです。
+ `username` 文字列が有効な E メールアドレス形式 (例: `user@example.com`) の場合、ユーザープールはユーザーの `email` 属性の値として、自動的に `username` を入力します。
+ `username` 文字列が有効な電話番号形式 (例: `+12065551212`) の場合、ユーザープールはユーザーの `phone_number` 属性の値として、自動的に `username` を入力します。
+ `username` 文字列形式が E メールアドレスまたは電話番号の形式ではない場合は、`SignUp` API から例外が返されます。
+ `username` 文字列に含まれている E メールアドレスまたは電話番号が既に使用されている場合、`SignUp` API によって例外が返されます。
+ `SignUp` API は、`username` 属性にユーザーの [UUID](cognito-terms.md#terms-uuid) を入力します。この UUID は、ユーザー ID トークン内の `sub` クレームと同じ値です。

[ListUsers](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html) オペレーションを除くすべての API で、E メールアドレスまたは電話番号をユーザー名の代わりに使用できます。`ListUsers` API リクエストでは、`email` または `phone_number` の `Filter` を指定できます。`username` でフィルタリングする場合は、E メールアドレスや電話番号ではなく、UUID ユーザー名を指定する必要があります。

## カスタム属性
<a name="user-pool-settings-custom-attributes"></a>

ユーザープールには、カスタム属性を最大 50 まで追加できます。カスタム属性の最小長または最大長を指定できます。ただし、すべてのカスタム属性の最大長は 2048 文字以下にする必要があります。カスタム属性の名前は、[SchemaAttributeType](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SchemaAttributeType.html) の `Name` パラメータで使用した正規表現パターンと一致する必要があります。

**各カスタム属性には以下の特徴があります。**
+ 文字列、数値、ブール値、または `DateTime` オブジェクトとして定義できます。Amazon Cognito は ID トークンにカスタム属性値を文字列としてのみ書き込みます。
**注記**  
Amazon Cognito コンソールでは、文字列と数値をデータ型とするカスタム属性のみを追加できます。ブール値や `DateTime` 属性など、他のデータ型のオプションは、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) および [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストの `SchemaAttributes` プロパティでのみ使用できます。
+ ユーザーが属性の値を提供することを要求することはできません。
+ ユーザープールに追加した後で、削除または変更することはできません。
+ 属性名の文字長は、Amazon Cognito が受け入れる制限内です。詳細については、「[Amazon Cognito のクォータ](quotas.md)」を参照してください。
+ *変更可能*または*イミュータブル*とすることができます。ユーザーを作成するときに、イミュータブル属性に値を書き込むことができます。アプリクライアントがその属性に対する書き込み権限を持っている場合、変更可能な属性の値を変更できます。詳細については「[属性の権限と範囲](#user-pool-settings-attribute-permissions-and-scopes)」を参照してください。

**注記**  
コードおよび [ロールベースアクセスコントロールの使用](role-based-access-control.md) のルールの設定で、カスタム属性は標準属性と区別するために、`custom:` プレフィックスを必要とします。

また、[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) の `SchemaAttributes` プロパティで、ユーザープールを作成する際に、*開発者属性*を追加することもできます。開発者属性には `dev:` プレフィックスがあります。ユーザーのデベロッパー属性は、 AWS 認証情報でのみ変更できます。開発者属性はレガシー機能であり、Amazon Cognito がアプリケーションクライアントの読み取り/書き込み権限と置き換えました。

以下の手順を使用して、新しくカスタム属性を作成します。

**コンソールを使用してカスタム属性を追加する**

1. の[Amazon Cognito](https://console.aws.amazon.com/cognito/home)」に移動します AWS マネジメントコンソール。コンソールでプロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[サインアップ]** メニューを選択し、**[カスタム属性]** セクションで **[カスタム属性を追加]** を選択します。

1. **[Add custom attributes]** (カスタム属性を追加する) のページで、新しい属性に関する以下の詳細情報を入力します。
   + **名前**を入力します。
   + [**Type**] (タイプ) (**文字列**または**数値**) を選択します。
   + **最小**文字列の長さまたは数値を入力します。
   + **最大**文字列の長さまたは数値を入力します。
   + ユーザーが初期値を設定した後で、カスタム属性の値を変更する権限をユーザーに付与する場合は、**[Mutable]** (変更可能) を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

## 属性の権限と範囲
<a name="user-pool-settings-attribute-permissions-and-scopes"></a>

各アプリクライアントで、各ユーザー属性に読み取りと書き込み権限を設定できます。これにより、ユーザー用に保存する各属性の読み取りおよび変更に必要なアプリによるアクセスを制御できます。例えば、ユーザーが有料サービスを利用しているお客様であるかどうかを示すカスタム属性があるとします。アプリでこの属性は表示できますが、直接変更することはできません。代わりに、管理ツールまたはバックグラウンドプロセスを使用してこの属性を更新します。ユーザー属性の権限は、Amazon Cognito コンソール、Amazon Cognito API、または AWS CLIから設定できます。デフォルトでは、新しいカスタム属性を利用する前に、読み取り/書き込みの許可を設定する必要があります。デフォルトでは、アプリケーションクライアントを作成すると、すべての標準属性とカスタム属性に対する読み取り/書き込み許可がアプリケーションに付与されます。アプリケーションが必要とする情報量のみに制限するには、アプリケーションクライアント設定の属性に特定のアクセス権限を割り当てます。

ベストプラクティスとして、アプリケーションクライアントを作成するときに属性の読み取り/書き込みアクセス許可を指定します。アプリケーションのオペレーションに必要な最小限のユーザー属性セットへのアクセスをアプリケーションクライアントに付与します。

**注記**  
デフォルト以外のアプリケーションクライアント権限を設定した場合、[UserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPoolClient.html) は、`ReadAttributes` と`WriteAttributes` のみを返します。

**属性権限を更新するには (AWS マネジメントコンソール)**

1. の[Amazon Cognito](https://console.aws.amazon.com/cognito/home)」に移動します AWS マネジメントコンソール。コンソールでプロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[アプリケーションクライアント]** メニューを選択し、リストからアプリケーションクライアントを選択します。

1. **[属性権限]** タブで、**[編集]** を選択します。

1. **[Edit attribute read and write permissions]** (属性の読み込みおよび書き込みアクセス権限を編集) ページで、読み取りおよび書き込み権限を設定し、**[Save changes]** (変更の保存) を選択します。

カスタム属性を使用して、アプリクライアントごとに以上の手順を繰り返します。

アプリケーションごとに、属性を読み取り可能または書き込み可能とマークできます。これは、標準属性とカスタム属性の両方に当てはまります。アプリは、読み取り可能としてマークした属性の値を取得したり、書き込み可能としてマークした属性の値を設定または変更したりできます。書き込み権限のない属性の値をアプリが設定しようとすると、Amazon Cognito が `NotAuthorizedException` を返します。[GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) リクエストにはアプリケーションクライアントクレーム付きのアクセストークンが含まれます。Amazon Cognito は、アプリケーションクライアントが読み取ることができる属性の値のみを返します。アプリからのユーザーの ID トークンには、読み取り可能な属性に対応するクレームのみが含まれます。すべてのアプリケーションクライアントは、ユーザープールの必須属性を書き込むことができます。Amazon Cognito ユーザープール API リクエストで属性の値を設定できるのは、まだ値が設定されていない必須属性の値も指定する場合のみに限られます。

カスタム属性の読み取り書き込みアクセス許可にはそれぞれ異なる機能があります。ユーザープールの変更可能な属性または変更不可能な属性として作成でき、どのアプリクライアントでも読み取りまたは書き込み属性として設定できます。

変更不可能なカスタム属性は、ユーザー作成時に 1 回だけ更新できます。変更不可能な属性には以下のメソッドを入力できます。
+ `SignUp`: ユーザーは、変更不可能なカスタム属性への書き込みアクセス許可を持つアプリクライアントにサインアップします。その属性の値を提供します。
+ サードパーティ IdP でのサインイン: ユーザーは、変更不可能なカスタム属性への書き込みアクセス許可を持つアプリクライアントにサインインします。IdP のユーザープール設定には、提供されたクレームを変更不可能な属性にマップするルールがあります。これは可能ですが、ユーザーがサインインできるのは一度だけであるため、実用的ではありません。最初のサインイン試行の後に 2 度目以降のサインイン試行がなされると、現在書き込み不可の属性へのマッピングルールにより、Amazon Cognito は、その試行を拒否します。
+ `AdminCreateUser`: 変更不可能な属性の値を指定します。

### スコープを使用した属性アクセス許可
<a name="user-pool-settings-attribute-scope-based-permissions"></a>

 AWS SDK または CDK、REST API、または で設定したユーザープールでは AWS CLI、OIDC スコープ を使用してアプリケーションクライアントの読み取りまたは書き込みアクセスを設定できます`oidc:profile`。`oidc:profile` は、次の標準属性への読み取り/書き込みアクセスを許可します。
+ `name`
+ `family_name`
+ `given_name`
+ `middle_name`
+ `nickname`
+ `preferred_username`
+ `profile`
+ `picture`
+ `website`
+ `gender`
+ `birthdate`
+ `zoneinfo`
+ `locale`

このリストは、[OIDC 仕様のセクション 2.4](https://openid.net/specs/openid-connect-basic-1_0.html#Scopes) で定義されているように、OIDC 標準属性から `email`、`phone_number`、`sub`、`address` を除外したものです。アプリケーションクライアントに割り当てることができるスコープについては、「[スコープ、M2M、リソースサーバー](cognito-user-pools-define-resource-servers.md)」を参照してください。

`oidc:profile` スコープ内の属性に書き込むようにアプリケーションクライアントを設定するには、[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) API リクエストまたは [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) API リクエストで、[WriteAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html#CognitoUserPools-CreateUserPoolClient-request-WriteAttributes) の値を `oidc:profile` に設定します。他の属性も変更することをアプリケーションに許可する場合は、その属性も設定します。同様に、これらの属性への読み取りアクセスを許可するには、`oidc:profile` を [ReadAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html#CognitoUserPools-CreateUserPoolClient-request-ReadAttributes) の値に追加します。

ユーザープールを作成した後、属性の権限と範囲を変更できます。

# ユーザープール JSON ウェブトークン (JWT) の理解
<a name="amazon-cognito-user-pools-using-tokens-with-identity-providers"></a>

トークンは、アプリケーションが OIDC 認証の証明として使用し、リソースへのアクセスをリクエストできる認証のアーティファクトです。トークンの*クレーム*はユーザーに関する情報です。ID トークンには、ユーザー名、苗字、E メールアドレスなど、身元に関するクレームが含まれています。アクセストークンには、認証されたユーザーがサードパーティー API、Amazon Cognito ユーザーのセルフサービス API オペレーション、および [userInfo エンドポイント](userinfo-endpoint.md) にアクセスできる `scope` のようなクレームが含まれています。アクセストークンと ID トークンの両方に、ユーザープール内でのユーザーのグループメンバーシップを示す `cognito:groups` クレームが含まれています。ユーザープールグループの詳細については、「[ユーザープールにグループを追加する](cognito-user-pools-user-groups.md)」を参照してください。

Amazon Cognito には、新しいトークンの取得や既存のトークンの取り消しに使用できる更新トークンもあります。[トークンを更新](amazon-cognito-user-pools-using-the-refresh-token.md)して、新しい ID とアクセストークンを取得します。[トークンを取り消し](amazon-cognito-user-pools-using-the-refresh-token.md#amazon-cognito-identity-user-pools-revoking-all-tokens-for-user)て、更新トークンによって許可されているユーザーアクセスを取り消します。

Amazon Cognito は、[base64url](https://datatracker.ietf.org/doc/html/rfc4648#section-5) でエンコードされた文字列としてトークンを発行します 任意の Amazon Cognito ID またはアクセストークンを `base64url` からプレーンテキスト JSON にデコードできます。Amazon Cognito の更新トークンは暗号化されており、ユーザープールのユーザーと管理者に対して透過的ではなく、ユーザープールのみが読み取ることができます。

**トークンを使用した認証**  
ユーザーがアプリケーションにサインインすると、Amazon Cognito がログイン情報を検証します。ログインが正常に行われると、Amazon Cognito がセッションを作成し、認証されたユーザーの ID トークン、アクセストークン、および更新トークンを返します。これらのトークンを使用して、ダウンストリームのリソースや Amazon API Gateway などの API へのアクセス権をユーザーに付与できます。または、これらのトークンを他の AWS のサービスにアクセスするための一時的な AWS 認証情報と交換することができます。

![\[認証の概要\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/scenario-authentication-cup2.png)


**トークンの保存**  
アプリケーションでは、さまざまなサイズのトークンを保存する必要があります。トークンのサイズは、クレームの追加、エンコーディングアルゴリズムの変更、暗号化アルゴリズムの変更による理由（ただし、これらに限定されない）で変更される場合があります。ユーザープールでトークンの取り消しを有効にした場合も、Amazon Cognito が JSON ウェブトークンにクレームを追加するので、そのトークンのサイズは増加します。アクセストークンと ID トークンに対し、新たなクレーム `origin_jti` および `jti` が追加されます。トークンの取り消しの詳細については、「[トークンの取り消し](https://docs.aws.amazon.com/cognito/latest/developerguide/token-revocation.html)」を参照してください。

**重要**  
ベストプラクティスとして、アプリケーションのコンテキストにおけるすべての転送中と保管中のトークンを保護します。トークンには、アプリケーションのユーザーに関する個人識別情報、およびユーザープールで使用するセキュリティモデルに関する情報を含めることができます。

**トークンをカスタマイズする**  
Amazon Cognito からアプリに渡すアクセストークンと ID トークンをカスタマイズできます。[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)では、トークンクレームを追加、変更、および抑制できます。トークン生成前トリガーは、Amazon Cognito からデフォルトのクレームセットを送信する先の Lambda 関数です。クレームには、OAuth 2.0 スコープ、ユーザープールグループのメンバーシップ、ユーザー属性などが含まれます。この関数は、必要に応じてランタイムに変更を加え、更新したトークンクレームを Amazon Cognito に返すことができます。

バージョン 2 のイベントによるアクセストークンのカスタマイズには追加料金がかかります。詳細については、「[Amazon Cognito の料金](https://aws.amazon.com/cognito/pricing/)」を参照してください。

**Topics**
+ [ID トークンの理解](amazon-cognito-user-pools-using-the-id-token.md)
+ [アクセストークンの理解](amazon-cognito-user-pools-using-the-access-token.md)
+ [更新トークン](amazon-cognito-user-pools-using-the-refresh-token.md)
+ [トークン取り消しによるユーザーセッションの終了](token-revocation.md)
+ [JSON ウェブトークンの検証](amazon-cognito-user-pools-using-tokens-verifying-a-jwt.md)
+ [ユーザープールトークンの有効期限とキャッシュの管理](amazon-cognito-user-pools-using-tokens-caching-tokens.md)

# ID トークンの理解
<a name="amazon-cognito-user-pools-using-the-id-token"></a>

ID トークンとは、`name`、`email`、および `phone_number` など、認証されたユーザーのアイデンティティに関するクレームが含まれる、[ JSON ウェブトークン (JWT)](https://tools.ietf.org/html/rfc7519) です。この ID 情報はアプリケーション内で使用できます。ID トークンは、リソースサーバーまたはサーバーアプリケーションに対するユーザーの認証にも使用できます。Web API オペレーションを使用して、アプリケーション外で ID トークンを使用することも可能です。このような場合は、ID トークン内のクレームを信頼する前に、ID トークンの署名を検証する必要があります。「[JSON ウェブトークンの検証](amazon-cognito-user-pools-using-tokens-verifying-a-jwt.md)」を参照してください。

ID トークンの有効期限は、5 分から 1 日までの任意の値に設定できます。この値は、アプリケーションのクライアントごとに設定できます。

**重要**  
ユーザーがマネージドログインでサインインすると、Amazon Cognito は 1 時間有効なセッション Cookie を設定します。アプリケーションでマネージドログインを使用して認証し、アクセストークンと ID トークンに 1 時間未満の最小期間を指定すると、ユーザーは Cookie の有効期限が切れるまで有効なセッションを維持できます。1 時間のセッション中に有効期限が切れるトークンがある場合、ユーザーは再認証しなくてもトークンを更新できます。

## ID トークンのヘッダー
<a name="user-pool-id-token-header"></a>

ヘッダーには 2 つの情報 (キー ID: `kid`、アルゴリズム: `alg`) が含まれています。

```
{
"kid" : "1234example=",
"alg" : "RS256"
}
```

**`kid`**  
キー ID。その値は、トークンの JSON Web 署名 (JWS) をセキュア化するために使用されたキーを示します。ユーザープール署名キー ID は `jwks_uri` エンドポイントで確認できます。  
`kid` パラメータの詳細については、「[Key identifier (kid) header parameter](https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41#section-4.5)」を参照してください。

**`alg`**  
Amazon Cognito が、アクセストークンをセキュア化するために使用した暗号化アルゴリズム。ユーザープールは、SHA-256 による RSA 署名である RS256 暗号化アルゴリズムを使用します。  
`alg` パラメータの詳細については、「[Algorithm (alg) header parameter](https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41#section-4.4)」を参照してください。

## ID トークンのデフォルトペイロード
<a name="user-pool-id-token-payload"></a>

これは ID トークンのサンプルペイロードです。認証されたユーザーに関するクレームが含まれています。OpenID Connect (OIDC) 標準クレームに関する詳細については、「[OIDC standard claims](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)」を参照してください。[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md) を使用して独自の設計のクレームを追加できます。

```
<header>.{
    "sub": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "cognito:groups": [
        "test-group-a",
        "test-group-b",
        "test-group-c"
    ],
    "email_verified": true,
    "cognito:preferred_role": "arn:aws:iam::111122223333:role/my-test-role",
    "iss": "https://cognito-idp.us-west-2.amazonaws.com/us-west-2_example",
    "cognito:username": "my-test-user",
    "middle_name": "Jane",
    "nonce": "abcdefg",
    "origin_jti": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "cognito:roles": [
        "arn:aws:iam::111122223333:role/my-test-role"
    ],
    "aud": "xxxxxxxxxxxxexample",
    "identities": [
        {
            "userId": "amzn1.account.EXAMPLE",
            "providerName": "LoginWithAmazon",
            "providerType": "LoginWithAmazon",
            "issuer": null,
            "primary": "true",
            "dateCreated": "1642699117273"
        }
    ],
    "event_id": "64f513be-32db-42b0-b78e-b02127b4f463",
    "token_use": "id",
    "auth_time": 1676312777,
    "exp": 1676316377,
    "iat": 1676312777,
    "jti": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "email": "my-test-user@example.com"
}
.<token signature>
```

**`sub`**  
認証されたユーザーの固有識別子 ([UUID](cognito-terms.md#terms-uuid)) またはサブジェクト。ユーザー名はユーザープール内で一意ではない可能性があります。`sub` クレームは、特定のユーザーを識別する最良の方法です。

**`cognito:groups`**  
ユーザーをメンバーとするユーザープールグループの名前の配列。グループは、アプリに提示する識別子として使用したり、アイデンティティプールへの優先 IAM ロールのリクエストの生成に使用したりできます。

**`cognito:preferred_role`**  
ユーザーの最も優先度の高いユーザープールグループに関連付けた IAM ロールの ARN。ユーザープールがこのロールクレームを選択する方法の詳細については、「[グループへの優先順位の値の割り当て](cognito-user-pools-user-groups.md#assigning-precedence-values-to-groups)」を参照してください。

**`iss`**  
トークンを発行した ID プロバイダー。クレームは以下のような形式になります。  
`https://cognito-idp.<Region>.amazonaws.com/<your user pool ID>`

**`cognito:username`**  
ユーザープール内のユーザーのユーザー名。

**`nonce`**  
`nonce` クレームは、OAuth 2.0 の `authorize` エンドポイントへのリクエストに追加するものと、名前が同じパラメータから取得されます。パラメータを追加すると、Amazon Cognito が発行する ID トークンに `nonce` クレームが含められます。これは、リプレイ攻撃からの保護のために使用できます。リクエストで `nonce` 値を指定せずにサードパーティー ID プロバイダーを介した認証を行う場合、Amazon Cognito はノンスを自動的に生成および検証した上で、その値を `nonce` クレームとして ID トークンに追加します。Amazon Cognito での `nonce` クレームの実装は、[OIDC 標準](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation)に基づいています。

**`origin_jti`**  
ユーザーの更新トークンに関連付けられたトークン失効識別子。Amazon Cognito は、[エンドポイントの取り消し](revocation-endpoint.md) または [RevokeToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RevokeToken.html) API オペレーションを使用してユーザーのトークンが取り消されたかどうかを確認するときに、`origin_jti` クレームを参照します。トークンを取り消すと、Amazon Cognito は同じ `origin_jti` 値を持つすべてのアクセストークンと ID トークンを無効にします。

**`cognito:roles`**  
ユーザーのグループに関連付けられた IAM ロールの名前の配列。各ユーザープールグループには、1 つの IAM ロールを関連付けることができます。この配列は、優先順位に関係なく、ユーザーグループのすべての IAM ロールを表します。詳細については、「[ユーザープールにグループを追加する](cognito-user-pools-user-groups.md)」を参照してください。

**`aud`**  
ユーザーを認証したユーザープールアプリクライアント。Amazon Cognito は、アクセストークン `client_id` クレームで同じ値をレンダリングします。

**`identities`**  
ユーザーの `identities` 属性の内容。この属性には、フェデレーションサインインによって、または[フェデレーションユーザーをローカルプロファイルにリンクする](cognito-user-pools-identity-federation-consolidate-users.md)ことによってユーザーにリンクした各サードパーティ ID プロバイダープロファイルに関する情報が含まれます。この情報には、プロバイダー名、プロバイダーの固有 ID、およびその他のメタデータが含まれます。

**`token_use`**  
トークンの本来の目的。ID トークンでは、その値は `id` です。

**`auth_time`**  
ユーザーが認証を完了した認証時刻 (Unix の時間形式)。

**`exp`**  
ユーザーのトークンの有効期限が切れる有効期限 (Unix の時間形式)。

**`iat`**  
Amazon Cognito がユーザーのトークンを発行した発行時刻 (Unix の時間形式)。

**`jti`**  
JWT の一意の識別子。

この ID トークンには、「[OIDC standard claims](https://openid.net/specs/openid-connect-core-1_0.html#Claims)」に定義されている、OIDC の標準クレームを含めることができます。また、ユーザープールで定義されたカスタム属性が、この ID トークンに含まれる場合もあります。Amazon Cognito は、属性タイプに関係なく、カスタム属性値を文字列として ID トークンに書き込みます。

**注記**  
ユーザープールのカスタム属性には、常にプレフィックスとして `custom:` が付けられています。

## ID トークンの署名
<a name="user-pool-id-token-signature"></a>

ID トークンの署名は、JWT トークンのヘッダーとペイロードに基づいて計算されます。アプリが受け取る ID トークンのクレームを受け入れる前に、トークンの署名を検証してください。詳細については、「JSON Web トークンの検証」を参照してください。[JSON ウェブトークンの検証](amazon-cognito-user-pools-using-tokens-verifying-a-jwt.md)。

# アクセストークンの理解
<a name="amazon-cognito-user-pools-using-the-access-token"></a>

ユーザープールアクセストークンには、認証されたユーザーに関するクレーム、ユーザーのグループのリスト、およびスコープのリストが含まれます。アクセストークンの目的は、API オペレーションを承認することです。ユーザープールは、ユーザーのセルフサービスオペレーションを許可するアクセストークンを受け入れます。例えば、アクセストークンを使用して、ユーザーにユーザー属性を追加、変更、または削除するアクセス権を付与することができます。

ユーザープールに追加したカスタムスコープから派生した [OAuth 2.0 スコープ](https://www.rfc-editor.org/rfc/rfc6749#section-3.3)をアクセストークンに含めると、ユーザーが API から情報を取得することを承認できます。例えば、Amazon API Gateway は、Amazon Cognito のアクセストークンによる認可をサポートします。REST API オーソライザーにユーザープールからの情報を入力することも、Amazon Cognito を HTTP API の JSON ウェブトークン (JWT) オーソライザーとして使用することもできます。カスタムスコープでアクセストークンを生成するには、ユーザープールの[パブリックエンドポイント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-userpools-server-contract-reference.html)を通じてアクセストークンをリクエストする必要があります。

エッセンシャル[機能プラン](cognito-sign-in-feature-plans.md)またはプラス機能プランでは、トークン生成前の Lambda トリガーを実装することで、ランタイムにアクセストークンにスコープを追加することもできます。詳細については、「[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)」を参照してください。

`openid` スコープを持つユーザーのアクセストークンは、ユーザーの属性に関する詳細情報を [userInfo エンドポイント](userinfo-endpoint.md)にリクエストするためのアクセス許可です。`userInfo` エンドポイントから得られる情報の量は、アクセストークン内のその他のスコープ (すべてのユーザーデータを求める `profile` や E メールアドレスを求める `email` など) によって異なります。

`aws.cognito.signin.user.admin` スコープを持つユーザーのアクセストークンは、ユーザー属性の読み取りと書き込み、認証要素の一覧表示、多要素認証 (MFA) の設定、記憶されたデバイスの管理を行うためのアクセス許可です。アクセストークンによってこのスコープに付与される、属性へのアクセス権のレベルは、アプリケーションクライアントに割り当てた、属性の読み取り/書き込みアクセス許可と一致します。

アクセストークンは、[JSON ウェブトークン (JWT)](https://www.rfc-editor.org/rfc/rfc7519) です。アクセストークンのヘッダーは ID トークンと同じ構造になっていますが、Amazon Cognito は、ID トークンに署名するキーとは異なるキーでアクセストークンに署名します。アクセスキー ID (`kid`) クレームの値は、同じユーザーセッションの ID トークンの `kid` クレームの値と一致しません。アプリコードで、ID トークンとアクセストークンを個別に検証します。署名を検証するまでは、アクセストークンのクレームを信用しないでください。詳細については、「[JSON ウェブトークンの検証](amazon-cognito-user-pools-using-tokens-verifying-a-jwt.md)」を参照してください。アクセストークンの有効期限は、5 分から 1 日までの間で任意の値に設定できます。この値は、アプリケーションのクライアントごとに設定できます。

**重要**  
マネージドログインを使用する場合、アクセストークンと ID トークンの最小の有効期間を 1 時間未満に設定しないでください。マネージドログインは、1 時間有効なブラウザ Cookie を設定します。アクセストークンの有効期間を 1 時間未満に設定しても、マネージドログイン Cookie の有効性には影響がなく、ユーザーは初回サインインから 1 時間にわたって追加の認証情報なしで再認証できます。

## アクセストークンのヘッダー
<a name="user-pool-access-token-header"></a>

ヘッダーには 2 つの情報 (キー ID: `kid`、アルゴリズム: `alg`) が含まれています。

```
{
"kid" : "1234example="
"alg" : "RS256",
}
```

**`kid`**  
キー ID。その値は、トークンの JSON Web 署名 (JWS) をセキュア化するために使用されたキーを示します。ユーザープール署名キー ID は `jwks_uri` エンドポイントで確認できます。  
`kid` パラメータの詳細については、「[Key identifier (kid) header parameter](https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41#section-4.5)」を参照してください。

**`alg`**  
Amazon Cognito が、アクセストークンをセキュア化するために使用した暗号化アルゴリズム。ユーザープールは、SHA-256 による RSA 署名である RS256 暗号化アルゴリズムを使用します。  
`alg` パラメータの詳細については、「[Algorithm (alg) header parameter](https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41#section-4.4)」を参照してください。

## アクセストークンのデフォルトペイロード
<a name="user-pool-access-token-payload"></a>

以下は、アクセストークンのサンプルペイロードです。詳細については、「[JWT claims](https://tools.ietf.org/html/rfc7519#section-4)」を参照してください。[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md) を使用して独自の設計のクレームを追加できます。

```
<header>.
{
   "sub":"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
   "device_key": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
   "cognito:groups":[
      "testgroup"
   ],
   "iss":"https://cognito-idp.us-west-2.amazonaws.com/us-west-2_example",
   "version":2,
   "client_id":"xxxxxxxxxxxxexample",
   "aud": "https://api.example.com",
   "origin_jti":"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
   "event_id":"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
   "token_use":"access",
   "scope":"phone openid profile resourceserver.1/appclient2 email",
   "auth_time":1676313851,
   "exp":1676317451,
   "iat":1676313851,
   "jti":"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
   "username":"my-test-user"
}
.<token signature>
```

**`sub`**  
認証されたユーザーの固有識別子 ([UUID](cognito-terms.md#terms-uuid)) またはサブジェクト。ユーザー名はユーザープール内で一意ではない可能性があります。`sub` クレームは、特定のユーザーを識別する最良の方法です。

**`cognito:groups`**  
ユーザーをメンバーとするユーザープールグループの名前の配列。

**`iss`**  
トークンを発行した ID プロバイダー。クレームは以下のような形式になります。  
`https://cognito-idp.us-east-1.amazonaws.com/us-east-1_EXAMPLE`

**`client_id`**  
ユーザーを認証したユーザープールアプリクライアント。Amazon Cognito は、ID トークン `aud` クレームで同じ値をレンダリングします。

**aud**  
アクセストークンが認可する API の URL。アプリケーションが[リソースバインディング](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding)を認可サーバーにリクエストした場合にのみ使用されます。

**`origin_jti`**  
ユーザーの更新トークンに関連付けられたトークン失効識別子。Amazon Cognito は、[エンドポイントの取り消し](revocation-endpoint.md) または [RevokeToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RevokeToken.html) API オペレーションを使用してユーザーのトークンが取り消されたかどうかを確認するときに、`origin_jti` クレームを参照します。トークンを取り消すと、Amazon Cognito は同じ `origin_jti` 値を持つすべてのアクセストークンと ID トークンを検証しなくなります。

**`token_use`**  
トークンの本来の目的。アクセストークンでは、その値は `access` です。

**`scope`**  
サインインしたユーザーに発行された OAuth 2.0 スコープのリスト。スコープは、`userInfo` エンドポイントにある外部 API、ユーザーによるセルフサービスのオペレーション、ユーザーデータに対する、トークンが提供するアクセス権を定義します。[トークンエンドポイント](token-endpoint.md) のトークンには、アプリクライアントがサポートする任意のスコープを含めることができます。Amazon Cognito API サインインからのトークンにはスコープ `aws.cognito.signin.user.admin` のみが含まれます。

**`auth_time`**  
ユーザーが認証を完了した認証時刻 (Unix の時間形式)。

**`exp`**  
ユーザーのトークンの有効期限が切れる有効期限 (Unix の時間形式)。

**`iat`**  
Amazon Cognito がユーザーのトークンを発行した発行時刻 (Unix の時間形式)。

**`jti`**  
JWT の一意の識別子。

**`username`**  
ユーザープール内のユーザーのユーザー名。

**その他のリソース**
+ [Amazon Cognito ユーザープールでアクセストークンをカスタマイズする方法](https://aws.amazon.com/blogs/security/how-to-customize-access-tokens-in-amazon-cognito-user-pools/)

## アクセストークンの署名
<a name="user-pool-access-token-signature"></a>

`.well-known/jwks.json` エンドポイントでアドバタイズされたキーで署名されたアクセストークンの署名は、トークンヘッダーとペイロードの整合性を検証します。アクセストークンを使用して外部 API へのアクセスを許可する場合は、この署名を署名元のキーと照合して検証するように API オーソライザーを必ず設定します。詳細については、「[JSON ウェブトークンの検証](amazon-cognito-user-pools-using-tokens-verifying-a-jwt.md)」を参照してください。

# 更新トークン
<a name="amazon-cognito-user-pools-using-the-refresh-token"></a>

更新トークンを使用して、新しい ID およびアクセストークンを取得できます。更新トークンはデフォルトで、アプリケーションユーザーがユーザープールにサインインしてから 30 日後に有効期限が切れます。ユーザープールのアプリケーションを作成するときは、アプリケーションの更新トークンの有効期限を 60 分から 10 年までの任意の値に設定できます。

## 更新トークンによる新しいアクセストークンと ID トークンの取得
<a name="amazon-cognito-user-pools-using-the-refresh-token_initiate-token"></a>

マネージドログインの認証コードフローを使用した認証や、API オペレーションまたは SDK メソッドを使用した認証が成功すると、Amazon Cognito は更新トークンを発行します。更新トークンは、新しい ID トークンとアクセストークン、さらに必要に応じて新しい更新トークンを返します。更新トークンは、以下の方法で使用できます。

**GetTokensFromRefreshToken**  
[GetTokensFromRefreshToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetTokensFromRefreshToken.html) API オペレーションは、有効な更新トークンから新しい ID トークンとアクセストークンを発行します。更新トークンのローテーションを有効にしている場合は、新しい更新トークンも取得できます。

**InitiateAuth と AdminitiateAuth**  
[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) または [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションには、`REFRESH_TOKEN_AUTH` 認証フローが含まれています。このフローでは、更新トークンを渡して新しい ID トークンとアクセストークンを取得します。[更新トークンのローテーション](#using-the-refresh-token-rotation)が有効になっているアプリケーションクライアントでは、`REFRESH_TOKEN_AUTH` で認証することはできません。

**OAuth トークンエンドポイント**  
[ドメイン](cognito-user-pools-assign-domain.md)を持つユーザープールの[トークンエンドポイント](token-endpoint.md)には、`refresh_token` 付与タイプがあります。これを通じて、有効な更新トークンから新しい ID トークン、アクセストークン、さらに必要に応じて ([更新トークンのローテーション](#using-the-refresh-token-rotation)により) 更新トークンを発行します。

## 更新トークンのローテーション
<a name="using-the-refresh-token-rotation"></a>

必要に応じて、アプリケーションクライアントで更新トークンのローテーションを設定できます。更新トークンのローテーションを使用すると、クライアントは元の更新トークンを無効にし、トークンが更新されるたびに新しい更新トークンを発行できます。この設定を有効にすると、すべての形式のトークン更新で成功したリクエストごとに、新しい ID トークン、アクセストークン、*および*更新トークンが返されます。この設定を無効にすると、トークン更新リクエストは新しいアクセストークンと ID トークンのみを返し、元の更新トークンは有効なままになります。新しい更新トークンは、元の更新トークンの残りの期間有効になります。更新トークンをローテーションするか、元の更新トークンを引き継ぐように、[アプリケーションクライアント](user-pool-settings-client-apps.md)を設定できます。短時間の再試行を許可するには、元の更新トークンの猶予期間を最大 60 秒に設定することもできます。

**更新トークンのローテーションについて知っておくべきこと**
+ 更新トークンのローテーションを有効にすると、ユーザープールの JSON ウェブトークンに新しいクレームが追加されます。アクセストークンと ID トークンに `origin_jti` と `jti` クレームが追加されます。これらのクレームに伴って JWT のサイズが増加します。
+ 更新トークンのローテーションは、認証フロー `REFRESH_TOKEN_AUTH` と互換性がありません。更新トークンのローテーションを実装するには、アプリケーションクライアントでこの認証フローを無効にし、[GetTokensFromRefreshToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetTokensFromRefreshToken.html) API オペレーションまたは同等の SDK メソッドを使用してトークン更新リクエストを送信するようにアプリケーションを設計する必要があります。
+ 更新トークンのローテーションを非アクティブにすると、`GetTokensFromRefreshToken` または `REFRESH_TOKEN_AUTH` を使用してトークン更新リクエストを完了できます。
+ ユーザープールで[デバイスの記憶](amazon-cognito-user-pools-device-tracking.md)がアクティブな場合は、`GetTokensFromRefreshToken` リクエストでデバイスキーを指定する必要があります。アプリケーションが最初の認証リクエストで送信した確認済みデバイスキーがユーザーにない場合、Amazon Cognito は新しいデバイスキーを発行します。この設定でトークンを更新するには、デバイスキーを指定する必要があります (このデバイスキーは、`AuthParameters` で指定したものか、認証レスポンスで受け取ったものかは問いません)。
+ `GetTokensFromRefreshToken` リクエストで、トークン生成前の Lambda トリガーを `ClientMetadata` に渡すことができます。このデータは、トリガーの入力イベントに渡され、Lambda 関数のカスタムロジックで使用できる追加のコンテキストを提供します。

セキュリティのベストプラクティスとして、アプリケーションクライアントで更新トークンのローテーションを有効にします。

------
#### [ Enable refresh token rotation (console) ]

次の手順では、アプリケーションクライアントで更新トークンのローテーションをオンまたはオフにします。この手順では、作成済みのアプリケーションクライアントが必要です。アプリケーションクライアントの作成方法の詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。

**更新トークンのローテーションを有効にするには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[アプリケーションクライアント]** メニューに移動し、既存のアプリケーションクライアントを選択します。

1. ページの **[アプリケーションクライアントに関する情報]** セクションで **[編集]** を選択します。

1. **[高度なセキュリティ設定]** で、**[更新トークンのローテーションを有効にする]** オプションを見つけます。

1. ローテーションを有効にするには、チェックボックスをオンにします。ローテーションを無効にするには、チェックボックスをオフにします。

1. **[更新トークンのローテーションの猶予期間]** に、ローテーション後に元の更新トークンを取り消すまでの遅延時間として最大 60 秒を入力します。

------
#### [ Enable refresh token rotation (API) ]

更新トークンのローテーションを [CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) または [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) API リクエストで設定します。次のリクエスト本文の部分では、更新トークンのローテーションを有効にし、猶予期間を 10 秒に設定します。

```
"RefreshTokenRotation" : {
   "Feature" : "ENABLED,
   "RetryGracePeriodSeconds" : 10
}
```

------

## API および SDK トークンの更新
<a name="using-the-refresh-token-api"></a>

更新トークンを使用してユーザープール API で新しい ID トークンとアクセストークンを取得するには 2 つの方法があり、更新トークンのローテーションが有効になっているかどうかに応じて使い分けます。アプリケーションクライアントで更新トークンのローテーションが有効になっている場合は、[GetTokensFromRefreshToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetTokensFromRefreshToken.html) API オペレーションを使用します。アプリケーションクライアントで更新トークンのローテーションが有効になっていない場合は、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) API オペレーションまたは [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションの `REFRESH_TOKEN_AUTH` フローを使用します。

**注記**  
ユーザーは、[マネージドログイン](cognito-user-pools-managed-login.md)または AWS SDKsおよび Amazon Cognito API オペレーションで構築したカスタムアプリケーションで、ユーザープールで認証できます。`REFRESH_TOKEN_AUTH` フローと `GetTokensFromRefreshToken` は、どちらもマネージドログインユーザーのトークン更新を完了できます。カスタムアプリケーションでのトークン更新は、マネージドログインセッションには影響しません。これらのセッションはブラウザ Cookie で設定され、1 時間有効です。`GetTokensFromRefreshToken` レスポンスは、新しい ID トークン、アクセストークン、必要に応じて更新トークンを発行しますが、マネージドログインのセッション Cookie は更新しません。  
`REFRESH_TOKEN_AUTH` は、更新トークンのローテーションが有効になっているアプリケーションクライアントでは使用できません。

------
#### [ GetTokensFromRefreshToken ]

[GetTokensFromRefreshToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetTokensFromRefreshToken.html) は、更新トークンで認可したリクエストから新しい ID トークン、アクセストークン、更新トークンを返します。次に示すのは、`GetTokensFromRefreshToken` のリクエスト本文の例です。このオペレーションへのリクエストにより、クライアントメタデータを Lambda トリガーに送信できます。

```
{
    "RefreshToken": "eyJjd123abcEXAMPLE",
    "ClientId": "1example23456789",
    "ClientSecret": "myappclientsecret123abc",
    "ClientMetadata": { 
      "MyMetadataKey" : "MyMetadataValue" 
   },
}
```

------
#### [ AdminInitiateAuth/InitiateAuth ]

更新トークンのローテーションが無効になっているときに更新トークンを使用するには、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) API オペレーションまたは [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API オペレーションを使用します。`AuthFlow` パラメータの `REFRESH_TOKEN_AUTH` を渡します。`AuthFlow` の `AuthParameters` プロパティで、ユーザーの更新トークンを `"REFRESH_TOKEN"` の値として渡します。Amazon Cognito は、API リクエストがすべてのチャレンジを通過した後、新しい ID とアクセストークンを返します。

次に示すのは、`InitiateAuth` API または `AdminInitiateAuth` API を使用したトークン更新のリクエスト本文の例です。

```
{
    "AuthFlow": "REFRESH_TOKEN_AUTH",
    "ClientId": "1example23456789",
    "UserPoolId": "us-west-2_EXAMPLE",
    "AuthParameters": {
        "REFRESH_TOKEN": "eyJjd123abcEXAMPLE",
        "SECRET_HASH": "kT5acwCVrbD6JexhW3EQwnRSe6fLuPTRkEQ50athqv8="
    }
}
```

------

## OAuth トークンの更新
<a name="using-the-refresh-token-oauth"></a>

更新トークンは、ドメインを設定したユーザープール内の [トークンエンドポイント](token-endpoint.md) に送信することもできます。リクエスト本文には、`refresh_token` の `grant_type` 値とユーザーの更新トークンの `refresh_token` 値を含めます。

トークンエンドポイントへのリクエストは、更新トークンのローテーションが有効になっているアプリケーションクライアントと無効になっているアプリケーションクライアントの両方で使用できます。更新トークンのローテーションが有効になっている場合、トークンエンドポイントは新しい更新トークンを返します。

次に示すのは、更新トークンを使用したリクエストの例です。

```
POST /oauth2/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
Content-Length: **

client_id=1example23456789&grant_type=refresh_token&refresh_token=eyJjd123abcEXAMPLE
```

## 更新トークンの取り消し
<a name="amazon-cognito-identity-user-pools-revoking-all-tokens-for-user"></a>

ユーザーに属する更新トークンを取り消すことができます。トークンの取り消しの詳細については、「[トークン取り消しによるユーザーセッションの終了](token-revocation.md)」を参照してください。

**注記**  
更新トークンを取り消すと、Amazon Cognito がそのトークンを使用して更新リクエストから発行したすべての ID トークンとアクセストークンが取り消されます。

現在サインインしているすべてのセッションからユーザーをサインアウトさせるには、[GlobalSignOut](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GlobalSignOut.html) API リクエストまたは [AdminUserGlobalSignOut](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUserGlobalSignOut.html) API リクエストを使用してすべてのトークンを取り消します。ユーザーがサインアウトすると、以下の結果になります。
+ ユーザーの新しいトークンの取得にユーザーの更新トークンを使用できない。
+ ユーザーのアクセストークンは、トークン認証された API リクエストを行うことができない。
+ 新しいトークンを取得するためにユーザーが再認証される必要がある。マネージドログインのセッション Cookie は自動的に期限切れにならないため、ユーザーは認証情報の入力を求められることなく、セッション Cookie を使用して再認証できます。マネージドログインのユーザーをサインアウトさせたら、ユーザーを[ログアウトエンドポイント](logout-endpoint.md)にリダイレクトします。ここで Amazon Cognito はユーザーのセッション Cookie を消去します。

更新トークンを使用すると、ユーザーのセッションをアプリケーション内で長期間維持できます。時間が経つと、ユーザーは更新トークンでサインインしたままになっているアプリケーションの承認を解除したくなるかもしれません。1 つのセッションからユーザーをサインアウトさせるには、ユーザーの更新トークンを取り消します。ユーザーがすべての認証済みセッションからログアウトしたい場合は、[GlobalSignOut](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GlobalSignOut.html) API リクエストを生成します。アプリケーションは、**[すべてのデバイスからサインアウト]** などのオプションをユーザーに提供できます。`GlobalSignOut` は、ユーザーの有効な (変更されていない、有効期限が切れていない、取り消されていない) アクセストークンを受け入れます。この API はトークン認証されているため、あるユーザーがそれを使用して別のユーザーのサインアウトを開始することはできません。

ただし、認証情報を使用して承認する [AdminUserGlobalSignOut](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUserGlobalSignOut.html) API リクエストを生成 AWS して、すべてのデバイスから任意のユーザーをサインアウトできます。管理者アプリケーションは AWS 、開発者認証情報を使用してこの API オペレーションを呼び出し、ユーザープール ID とユーザーのユーザー名をパラメータとして渡す必要があります。`AdminUserGlobalSignOut` API は、ユーザープール内の任意のユーザーをサインアウトできます。

 AWS  認証情報またはユーザーのアクセストークンのいずれかを使用して認可できるリクエストの詳細については、「[認可モデル別にグループ化された API オペレーションのリスト](authentication-flows-public-server-side.md#user-pool-apis-auth-unauth)」を参照してください。

# トークン取り消しによるユーザーセッションの終了
<a name="token-revocation"></a>

更新トークンとエンドユーザーセッションは、以下の方法で取り消すことができます。更新トークンを取り消すと、その更新トークンによってそれまでに発行されたすべてのアクセストークンが無効になります。ユーザーに発行されたその他の更新トークンは影響を受けません。

**RevokeToken オペレーション**  
[RevokeToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RevokeToken.html) は、特定の更新トークンのすべてのアクセストークン (インタラクティブサインインの初期アクセストークンを含む) を取り消します。このオペレーションは、ユーザーの他の更新トークン、または他の更新トークンの子である ID トークンやアクセストークンには影響しません。

**取り消しエンドポイント**  
[取り消しエンドポイント](revocation-endpoint.md)は、指定した更新トークンと、この更新トークンで生成したすべての ID トークンとアクセストークンを取り消します。このエンドポイントは、インタラクティブサインインの初期アクセストークンも取り消します。このエンドポイントへのリクエストは、ユーザーの他の更新トークン、または他の更新トークンの子である ID トークンおよびアクセストークンには影響しません。

**GlobalSignOut オペレーション**  
[GlobalSignOut](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GlobalSignOut.html) は、ユーザーがアクセストークンを使用して承認するセルフサービスオペレーションです。このオペレーションは、リクエスト元のユーザーの更新トークン、ID トークン、アクセストークンをすべて取り消します。

**AdminUserGlobalSignOut オペレーション**  
[AdminUserGlobalSignOut](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUserGlobalSignOut.html) は、管理者が IAM 認証情報を使用して承認するサーバー側のオペレーションです。このオペレーションは、ターゲットユーザーの更新トークン、ID トークン、アクセストークンをすべて取り消します。

**トークンの取り消しについて知っておくべきこと**
+ 更新トークンを取り消すリクエストには、そのトークンを取得するために使用したクライアント ID を含める必要があります。
+ ユーザープールの JWT は、自己完結型であり、トークンの作成時に割り当てた署名と有効期限があります。取り消されたトークンは、トークンを必要とする Amazon Cognito API コールでは使用できません。ただし、JWT ライブラリを使用してトークンの署名と有効期限が検証された場合は、引き続き使用が可能です。
+ トークンの取り消しは、新しいユーザープールクライアントの作成時にデフォルトで有効になります。
+ 更新トークンは、トークンの取り消しが有効になっているアプリケーションクライアントでのみ取り消すことができます。
+ トークンの取り消しを有効にした後は、Amazon Cognito JSON ウェブトークンに新しいクレームが追加され、アクセストークンと ID トークンに `origin_jti` と `jti` クレームが追加されます。これらのクレームにより、アプリケーションクライアントのアクセストークンと ID トークンのサイズが大きくなります。
+ 以前にトークンの取り消しが有効になっていたアプリケーションクライアントでトークンの取り消しを無効にすると、取り消したトークンは再び有効になりません。
+ [ユーザーアカウントを無効にする](how-to-manage-user-accounts.md#manage-user-accounts-enable-disable)と (更新トークンとアクセストークンが取り消され)、ユーザーアカウントを再度有効にしても、取り消したトークンは有効になりません。
+  AWS マネジメントコンソール、、 AWS CLIまたは API を使用して新しいユーザープールクライアントを作成すると AWS 、トークンの失効がデフォルトで有効になります。

## トークンの取り消しを有効にする
<a name="enable-token-revocation"></a>

既存のユーザープールクライアントのトークンを取り消す前に、トークンの取り消しを有効にする必要があります。または AWS API を使用して AWS CLI 、既存のユーザープールクライアントのトークン失効を有効にできます。これを行うには、`aws cognito-idp describe-user-pool-client` CLI コマンドまたは `DescribeUserPoolClient` API 操作を呼び出して、アプリクライアントから現在の設定を取得します。次に、または `UpdateUserPoolClient` CLI コマンド`aws cognito-idp update-user-pool-client` API オペレーションを呼び出します。アプリクライアントの現在の設定を含め、`EnableTokenRevocation` パラメータを `true` に設定します。

Amazon Cognito API または AWS SDK でトークン失効を有効にしたアプリケーションクライアントを作成または変更するには、[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) または [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) API リクエストに次のパラメータを含めます。

```
"EnableTokenRevocation": true
```

Amazon Cognito コンソールでトークンの取り消しを設定するには、ユーザープールの **[アプリケーションクライアント]** メニューでアプリケーションクライアントを選択します。**[アプリケーションクライアントに関する情報]** で **[編集]** ボタンを選択し、**[高度な認証設定]** でトークンの取り消しを有効または無効にします。

## トークンを取り消す
<a name="revoke-tokens-api"></a>

更新トークンは、[RevokeToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RevokeToken.html) API リクエストを `[aws cognito-idp revoke-token](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/revoke-token.html)` CLI コマンドなどで使用して取り消すことができます。[エンドポイントの取り消し](revocation-endpoint.md) を使用してトークンを取り消すこともできます。このエンドポイントは、ユーザープールにドメインを追加した後で利用可能になります。取り消しエンドポイントは、Amazon Cognito がホストするドメイン、あるいは独自のカスタムドメインの両方で使用できます。

次は、`RevokeToken` API リクエストの例の本文です。

```
{
   "ClientId": "1example23456789",
   "ClientSecret": "abcdef123456789ghijklexample",
   "Token": "eyJjdHkiOiJKV1QiEXAMPLE"
}
```

次は、カスタムドメインのユーザープールの `/oauth2/revoke` エンドポイントに対する cURL リクエストの例です。

```
curl --location 'auth.mydomain.com/oauth2/revoke' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic Base64Encode(client_id:client_secret)' \
--data-urlencode 'token=abcdef123456789ghijklexample' \
--data-urlencode 'client_id=1example23456789'
```

`RevokeToken` オペレーションと `/oauth2/revoke` エンドポイントには、アプリケーションクライアントにクライアントシークレットがある場合を除き、追加の認可は必要ありません。

# JSON ウェブトークンの検証
<a name="amazon-cognito-user-pools-using-tokens-verifying-a-jwt"></a>

JSON ウェブトークン (JWT)は、簡単にデコード、読み取り、変更ができます。アクセストークンが変更されると、権限エスカレーションのリスクが発生します。ID トークンを変更すると、偽装リスクが発生します。アプリケーションはユーザープールをトークン発行者として信頼していますが、ユーザーが転送中のトークンを妨害した場合はどうなりますか？ アプリケーションが Amazon Cognito が発行したトークンと同じトークンを受信していることを確認する必要があります。

Amazon Cognito は、OpenID Connect (OIDC) 仕様の整合性と機密性の一部を使用するトークンを発行します。ユーザープールトークンは、有効期限、発行者、デジタル署名などのオブジェクトの有効性を示します。`.` 区切りの JWT の 3 番目で最後のセグメントである署名は、トークン検証の主要なコンポーネントです。悪意のあるユーザーがトークンを変更することがありますが、アプリケーションがパブリックキーを取得して署名を比較すれば、トークンは一致しなくなります。OIDC 認証から JWT を処理するアプリケーションは、サインインごとにこの検証オペレーションを実行する必要があります。

このページでは、一般的かつ特定的な JWT の認証を推奨します。アプリケーション開発は、さまざまなプログラミング言語とプラットフォームに及びます。Amazon Cognito は OIDC をパブリック仕様に十分近い方法で実装するため、任意のデベロッパー環境の信頼できる JWT ライブラリで検証要件を処理できます。

これらのステップでは、ユーザープール JSON Web トークン (JWT) の検証を説明します。

**Topics**
+ [前提条件](#amazon-cognito-user-pools-using-tokens-prerequisites)
+ [aws-jwt-verify によるトークンの検証](#amazon-cognito-user-pools-using-tokens-aws-jwt-verify)
+ [トークンの理解と検査](#amazon-cognito-user-pools-using-tokens-manually-inspect)

## 前提条件
<a name="amazon-cognito-user-pools-using-tokens-prerequisites"></a>

このセクションのタスクは、ライブラリ、SDK、またはソフトウェアフレームワークで既に処理されている可能性があります。 AWS SDKsは、アプリで Amazon Cognito ユーザープールトークンの処理と管理のためのツールを提供します。 AWS Amplify には、Amazon Cognito トークンを取得および更新する関数が含まれています。

詳細については、次のページを参照してください。
+ [Amazon Cognito の認証と認可を、ウェブアプリケーションとモバイルアプリケーションに統合する](cognito-integrate-apps.md)
+ [SDK を使用した Amazon Cognito ID プロバイダーのコード例 AWS SDKs](https://docs.aws.amazon.com/cognito/latest/developerguide/service_code_examples.html)
+ *Amplify Dev Center* の[高度なワークフロー](https://docs.amplify.aws/lib/auth/advanced/q/platform/js/#retrieve-jwt-tokens)

JSON ウェブトークン (JWT) のデコードと検証用として、多数のライブラリが用意されています。サーバー側の API 処理用にトークンを手動で処理する場合、または他のプログラミング言語を使用している場合は、これらのライブラリが役に立ちます。「[OpenID foundation の JWT トークンでの作業のためのライブラリのリスト](http://openid.net/developers/jwt/)」を参照してください。

## aws-jwt-verify によるトークンの検証
<a name="amazon-cognito-user-pools-using-tokens-aws-jwt-verify"></a>

Node.js アプリでは、 は、ユーザーがアプリに渡すトークンのパラメータを検証するために[aws-jwt-verifyライブラリ](https://github.com/awslabs/aws-jwt-verify) AWS を推奨します。`aws-jwt-verify` を使用すると、1 つ以上のユーザープールについて検証したいクレーム値を `CognitoJwtVerifier` に入力できます。確認できる値には次のものがあります。
+ アクセストークンや ID トークンの形式が不正ではなく、期限切れでもなく、有効な署名が付いているもの。
+ アクセストークンが、[正しいユーザープールとアプリクライアント](https://github.com/awslabs/aws-jwt-verify#verifying-jwts-from-amazon-cognito)から取得されたもの。
+ アクセストークンクレームに、[正しい OAuth 2.0 スコープ](https://github.com/awslabs/aws-jwt-verify#checking-scope)が含まれているもの。
+ アクセストークンと ID トークンに署名したキーが、[ユーザープールの *JWKS URI* の `kid` 署名キーと一致していること](https://github.com/awslabs/aws-jwt-verify#the-jwks-cache)。

  JWKS URI には、ユーザーのトークンに署名した秘密鍵に関する公開情報が含まれています。ユーザープールの JWKS URI は、`https://cognito-idp.<Region>.amazonaws.com/<userPoolId>/.well-known/jwks.json` で確認できます。

Node.js アプリや AWS Lambda オーソライザーで使用できる詳細とサンプルコードについては、GitHub の [https://github.com/awslabs/aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify) を参照してください。

## トークンの理解と検査
<a name="amazon-cognito-user-pools-using-tokens-manually-inspect"></a>

トークン検査をアプリに統合する前に、Amazon Cognito が JWT を組み立てる方法を検討してください。ユーザープールからサンプルトークンを取得します。それらをデコードして詳細に調べて特性を理解し、何をいつ検証するかを決定します。例えば、あるシナリオではグループメンバーシップを検証し、別のシナリオではスコープを調べたい可能性があります。

以下のセクションでは、アプリを準備するときに Amazon Cognito JWT を手動で検査するプロセスについて説明します。

### JWT の構造を確認します
<a name="amazon-cognito-user-pools-using-tokens-step-1"></a>

JSON ウェブトークン (JWT) は、間に `.` (ドット) 区切り文字がある 3 つのセクションで構成されます。

**ヘッダー**  
Amazon Cognito がトークンの署名に使用したキー ID、`kid`、および RSA アルゴリズム、`alg`。Amazon Cognito は `RS256` の `alg` でトークン署名します。`kid` は、ユーザープールが保持する 2048 ビット RSA プライベート署名キーへの切り捨てられたリファレンスです。

**ペイロード**  
トークンクレーム。ID トークンでは、クレームには、ユーザー属性とユーザープール、`iss`、およびアプリクライアント、`aud` に関する情報が含まれます。アクセストークンのペイロードには、スコープ、グループメンバーシップ、ユーザープールが `iss` として含まれ、アプリクライアントは `client_id` として含まれます。

**Signature**  
署名は、ヘッダーやペイロードのように base64url でデコードできません。JWKS URI で確認できる署名キーとパラメータから派生した RSA256 識別子です。

ヘッダーとペイロードは base64url でエンコードされた JSON です。開始文字 `{` にデコードされる最初の文字 `eyJ` で識別できます。ユーザーが base64url でエンコードした JWT をアプリケーションに提示した形式が `[JSON Header].[JSON Payload].[Signature]` になっていない場合、これは有効な Amazon Cognito トークンではないため、破棄できます。

次のサンプルアプリケーションでは、`aws-jwt-verify` を使用してユーザープールのトークンを検証します。

```
// cognito-verify.js
// Usage example: node cognito-verify.js eyJra789ghiEXAMPLE

const { CognitoJwtVerifier } = require('aws-jwt-verify');

// Replace with your Amazon Cognito user pool ID
const userPoolId = 'us-west-2_EXAMPLE';

async function verifyJWT(token) {
  try {
    const verifier = CognitoJwtVerifier.create({
      userPoolId,
      tokenUse: 'access', // or 'id' for ID tokens
      clientId: '1example23456789', // Optional, only if you need to verify the token audience
    });

    const payload = await verifier.verify(token);
    console.log('Decoded JWT:', payload);
  } catch (err) {
    console.error('Error verifying JWT:', err);
  }
}

// Example usage
if (process.argv.length < 3) {
  console.error('Please provide a JWT token as an argument.');
  process.exit(1);
}

const MyToken = process.argv[2];
verifyJWT(MyToken);
```

### JWT を検証
<a name="amazon-cognito-user-pools-using-tokens-step-2"></a>

JWT 署名は、ヘッダーとペイロードのハッシュされた組み合わせです。Amazon Cognito は、ユーザープールごとに 2 組の RSA 暗号化キーを生成します。1 つの秘密鍵がアクセストークンに署名し、もう 1 つが ID トークンに署名します。

**JWT トークンの署名を検証する**

1. ID トークンを復号化します。

   OpenID Foundation では、[JWT トークンでの作業のためのライブラリのリストも維持されています](http://openid.net/developers/jwt/)。

    AWS Lambda を使用してユーザープール JWTsデコードすることもできます。詳細については、[「 を使用した Amazon Cognito JWT トークンのデコードと検証 AWS Lambda](https://github.com/awslabs/aws-support-tools/tree/master/Cognito/decode-verify-jwt)」を参照してください。

1. ローカルキー ID (`kid`) とパブリック `kid` を比較します。

   1. ユーザープール用に、対応するパブリック JSON Web キー (JWK) をダウンロードして保存します。これは、JSON Web キーセット (JWKS) の一部として提供されており、環境に合わせて次のように `jwks_uri` URL を構築することで、その場所を特定できます。

      ```
      https://cognito-idp.<Region>.amazonaws.com/<userPoolId>/.well-known/jwks.json
      ```

      JWK と JWK セットの詳細については、「[JSON Web Key (JWK)](https://tools.ietf.org/html/rfc7517)」を参照してください。
**注記**  
Amazon Cognito は、ユーザープール内で署名キーをローテーションする可能性があります。ベストプラクティスとして、`kid` をキャッシュキーとして使用して、アプリに公開鍵をキャッシュし、定期的にキャッシュを更新してください。アプリが受け取るトークンの `kid` をキャッシュと比較します。  
正しい発行者で `kid` が異なるトークンを受け取った場合、Amazon Cognito が署名キーをローテーションした可能性があります。ユーザープール `jwks_uri` エンドポイントのキャッシュを更新します。

      以下は、サンプル `jwks.json` ファイルです。

      ```
      {
      	"keys": [{
      		"kid": "1234example=",
      		"alg": "RS256",
      		"kty": "RSA",
      		"e": "AQAB",
      		"n": "1234567890",
      		"use": "sig"
      	}, {
      		"kid": "5678example=",
      		"alg": "RS256",
      		"kty": "RSA",
      		"e": "AQAB",
      		"n": "987654321",
      		"use": "sig"
      	}]
      }
      ```  
**Key ID (`kid`)**  
`kid` は、トークンの JSON ウェブ署名 (JWS) をセキュア化するために使用されたキーを示すヒントです。  
**Algorithm (`alg`)**  
`alg` ヘッダーパラメータは、ID トークンをセキュア化するために使用される暗号化アルゴリズムを表します。ユーザープールは、SHA-256 による RSA 署名である RS256 暗号化アルゴリズムを使用します。RSA の詳細については、「[RSA cryptography](https://tools.ietf.org/html/rfc3447)」を参照してください。  
**Key type (`kty`)**  
`kty` パラメータは、この例の「RSA」など、キーで使用される暗号化アルゴリズムファミリーを特定します。  
**RSA exponent (`e`)**  
`e` パラメータには、RSA パブリックキーの指数値が含まれます。これは、Base64urlUInt でエンコードされた値として表されます。  
**RSA modulus (`n`)**  
`n` パラメータには、RSA パブリックキーのモジュラス値が含まれます。これは、Base64urlUInt でエンコードされた値として表されます。  
**Use (`use`)**  
`use` パラメータは、パブリックキーの用途を表します。この例では、`use` 値の `sig` が署名を表しています。

   1. JWT の `kid` に一致する `kid` のパブリック JSON ウェブキーを検索します。

### クレームを検証する
<a name="amazon-cognito-user-pools-using-tokens-step-3"></a>

**JWT クレームを検証する**

1. 次のいずれかの方法で、トークンの有効期限が切れていないことを確認します。

   1. トークンをデコードし、`exp` クレームを現在の時刻と比較します。

   1. アクセストークンに `aws.cognito.signin.user.admin` クレームが含まれている場合は、[GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) などの API にリクエストを送信します。[アクセストークンで承認](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pools-API-operations.html#user-pool-apis-auth-unauth)する API リクエストは、トークンの有効期限が切れているとエラーを返します。

   1. [userInfo エンドポイント](userinfo-endpoint.md) へのリクエストでアクセストークンを提示します。トークンの有効期限が切れている場合、リクエストはエラーを返します。

1. ID トークンの `aud` クレームとアクセストークンの `client_id` クレームは、Amazon Cognito ユーザープールで作成されたアプリクライアント ID と一致する必要があります。

1. 発行者 (`iss`) のクレームは、ユーザープールと一致する必要があります。例えば、`us-east-1` リージョンで作成されたユーザープールには、以下の `iss` 値があります。

   `https://cognito-idp.us-east-1.amazonaws.com/<userpoolID>`.

1. `token_use` クレームをチェックします。
   + Web API オペレーションでアクセストークンのみを受け入れている場合は、その値を `access` にする必要があります。
   + ID トークンのみを使用している場合、その値は `id` にする必要があります。
   + ID とアクセストークンのいずれも使用している場合、`token_use` クレームは、`id` または `access` になります。

これで、トークン内のクレームを信頼できるようになりました。

# ユーザープールトークンの有効期限とキャッシュの管理
<a name="amazon-cognito-user-pools-using-tokens-caching-tokens"></a>

新しい JSON ウェブトークン (JWT) を取得するたびに、アプリは次のいずれかのリクエストを正常に完了する必要があります。
+ [トークンエンドポイント](token-endpoint.md) からクライアント認証情報または認可コードの[付与](https://www.rfc-editor.org/rfc/rfc6749#section-1.3)をリクエストする。
+ マネージドログインページに対して暗黙的な付与をリクエストします。
+ [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) のような Amazon Cognito API リクエストでローカルユーザーを認証する。

トークンの有効期限が分単位、時間単位、または日単位になるようにユーザープールを設定できます。アプリケーションのパフォーマンスと可用性を確保するには、トークンの有効期間の約 75% まで Amazon Cognito トークンを使用してから、新しいトークンを取得してください。アプリ用に構築したキャッシュソリューションはトークンを利用可能な状態に保ち、リクエストレートが高すぎる場合に Amazon Cognito がリクエストを拒否するのを防ぎます。クライアント側のアプリは、トークンをメモリキャッシュに保存する必要があります。サーバー側アプリでは、暗号化されたキャッシュメカニズムを追加してトークンを保存できます。

ユーザープールがユーザーまたはマシンツーマシンのアクティビティを大量に生成する場合、Amazon Cognito が設定したトークンをリクエストできる数の制限に遭遇する可能性があります。Amazon Cognito エンドポイントへのリクエスト数を減らすには、認証データを安全に保存して再利用するか、エクスポネンシャルバックオフと再試行を実装することができます。

認証データは 2 つのクラスのエンドポイントから取得されます。Amazon Cognito の [OAuth 2.0 エンドポイント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-userpools-server-contract-reference.html)に含まれているトークンエンドポイントでは、クライアントの認証情報とマネージドログインの認証コードのリクエストを処理します。[サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/cognito_identity.html#cognito_identity_your_user_pools_region)は、`InitiateAuth` や `RespondToAuthChallenge` のようなユーザープール API リクエストに応答します。各タイプのリクエストには独自の制限があります。制限事項の詳細については、「[Amazon Cognito のクォータ](quotas.md)」を参照してください。

## Amazon API Gateway によるマシンツーマシンアクセストークンのキャッシュ
<a name="amazon-cognito-user-pools-using-tokens-caching-tokens-API-gateway"></a>

API Gateway トークンキャッシュを使用すると、Amazon Cognito OAuth エンドポイントのデフォルトのリクエストレートクォータを超えるイベントに応じてアプリをスケールさせることができます。

![\[M2M のアクセストークンのキャッシュを維持する API Gateway の図。API プロキシはトークンリクエストを処理し、キャッシュされたトークンが既に有効である場合はキャッシュされたトークンを返します。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/user-pools-m2m-caching.png)


アクセストークンをキャッシュして、キャッシュされたトークンの有効期限が切れた場合にのみ、アプリが新しいアクセストークンをリクエストするようにできます。それ以外の場合、キャッシュエンドポイントはキャッシュからトークンを返します。これにより、Amazon Cognito API エンドポイントへの追加呼び出しを防ぐことができます。Amazon API Gateway を [トークンエンドポイント](token-endpoint.md) へのプロキシとして使用する場合、API はリクエストクォータに影響するリクエストの大半に応答し、レート制限によるリクエストの失敗を防ぎます。

次の API Gateway ベースのソリューションでは、トークンキャッシュの低レイテンシー、ローコード、ノーコード実装が提供されます。API Gateway API は転送中に暗号化され、オプションで保存時にも暗号化されます。API Gateway キャッシュは、OAuth 2.0 [クライアント認証情報の付与](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4)に最適で、マシンツーマシンセッションとマイクロサービスセッションを認可するためのアクセストークンを生成し、頻繁かつ大量に付与します。マイクロサービスが水平方向にスケールするトラフィックの急増などのイベントでは、ユーザープールまたはアプリケーションクライアントの AWS リクエストレート制限を超えるボリュームで同じクライアント認証情報を使用する多くのシステムが発生する可能性があります。このようなシナリオでは、アプリの可用性と低レイテンシーを維持するために、キャッシュソリューションがベストプラクティスです。

このソリューションでは、API にキャッシュを定義して、アプリでリクエストする OAuth スコープとアプリクライアントの組み合わせごとに個別のアクセストークンを保存します。アプリがキャッシュキーと一致するリクエストを行うと、API はキャッシュキーと一致する最初のリクエストに対して Amazon Cognito が発行したアクセストークンを返します。キャッシュキーの有効期限が切れると、API はリクエストをトークンエンドポイントに転送し、新しいアクセストークンをキャッシュします。

**注記**  
キャッシュキーの有効期間は、アプリクライアントのアクセストークン有効期間よりも短くする必要があります。

キャッシュキーは、リクエスト本文の `scope` URL パラメータでリクエストした OAuth スコープと、リクエストの `Authorization` ヘッダーの組み合わせです。`Authorization` ヘッダーには、アプリのクライアント ID とクライアントシークレットが含まれます。このソリューションを実装するために、アプリに追加のロジックを実装する必要はありません。ユーザープールトークンエンドポイントへのパスを変更するには、設定を更新するだけで済みます。

トークンキャッシュは、[ElastiCache (Redis OSS)](https://docs.aws.amazon.com/elasticache/index.html) で実装することもできます。 AWS Identity and Access Management (IAM) ポリシーによるきめ細かなコントロールが必要な場合は、[Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/authentication-and-access-control.html#authentication) キャッシュをご検討ください。

**注記**  
API Gateway でのキャッシュには追加料金がかかります。[詳細については、料金表を参照してください。](https://aws.amazon.com/api-gateway/pricing)<a name="amazon-cognito-user-pools-using-tokens-caching-tokens-API-gateway-how-to"></a>

**API Gateway でキャッシュプロキシをセットアップする方法**

1. [API Gateway コンソール](https://console.aws.amazon.com/apigateway/main/apis)を開き、REST API を作成します。

1. **[Resources]** (リソース) で、POST メソッドを作成します。

   1. HTTP **[Integration type]** (統合タイプ) を選択してください。

   1. **[Use HTTP proxy integration]** (HTTP プロキシ統合の使用) を選択します。

   1. `https://<your user pool domain>/oauth2/token` の **[Endpoint URL]** (エンドポイント URL) を入力します。

1. **[Resources]** (リソース) で、キャッシュキーを設定します。

   1. POST メソッドの **[Method request]** (メソッドリクエスト) を編集します。
**注記**  
このメソッドリクエストの検証は、トークンリクエストの `client_secret_basic` 認可で使用します。これに伴って、クライアントシークレットが `Authorization` リクエストのヘッダーにエンコードされます。`client_secret_post` 認可における JSON リクエスト本文の検証では、代わりに [client\$1secret](token-endpoint.md#post-token-request-parameters-in-body) が存在することを必須とする [データモデル](https://docs.aws.amazon.com/apigateway/latest/developerguide/models-mappings-models.html)を作成します。このモデルでは、**[リクエストの検証]** で **[本文、クエリ文字列パラメータ、およびヘッダーの検証]** を行う必要があります。

   1. **[リクエストの検証]** メソッドを **[クエリ文字列パラメータおよびヘッダーの検証]** に設定します。リクエストの検証の詳細については、「*Amazon API Gateway デベロッパーガイド*」の「[リクエストの検証](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)」を参照してください。

   1. `scope` パラメータと `Authorization` ヘッダーをキャッシュキーとして設定します。

      1. **[URL クエリ文字列パラメータ]** にクエリ文字列を追加します。`scope` の **[名前]** にクエリ文字列名を入力し、**[必須]** と **[キャッシュ]** を選択します。

      1. **[HTTP リクエストヘッダー]** にヘッダーを追加します。`Authorization` の **[名前]** にリクエストヘッダー名を入力し、**[必須]** と **[キャッシュ]** を選択します。

1. **[Stages]** (ステージ) で、キャッシュを設定します。

   1. 変更するステージを選択し、**[ステージの詳細]** で **[編集]** を選択します。

   1. **[その他の設定]** の **[キャッシュ設定]** で、**[API キャッシュをプロビジョニング]** オプションをオンにします。

   1. **[Cache capacity]** (キャッシュ容量) を選択します。キャッシュキャパシティが大きいほどパフォーマンスは向上しますが、追加コストが発生します。

   1. **[承認を必須にする]** チェックボックスをオフにします。**[Continue]** (続行) をクリックします。

   1. API Gateway は、ステージレベルの GET メソッドにのみキャッシュポリシーを適用します。POST メソッドには、キャッシュポリシーのオーバーライドを適用する必要があります。

      設定したステージを展開し、`POST` メソッドを選択します。メソッドのキャッシュ設定を作成するには、**[オーバーライドを作成]** を選択します。

   1. **[メソッドキャッシュを有効にする]** オプションを有効にします。

   1. ****[キャッシュの有効期限 (TTL)]**** として 3,600 秒を入力します。**[保存]** を選択します。

1. **[Stages]** (ステージ) で、**[Invoke URL]** (URL を呼び出す) に注目します。

1. ユーザープールの `/oauth2/token` エンドポイントの代わりに、API の **Invoke URL** (URL を呼び出す) にトークンリクエストを POST するようにアプリを更新します。

# サインイン完了後にリソースにアクセスする
<a name="accessing-resources"></a>

アプリケーションユーザーは、ユーザープール経由で直接サインインするか、またはサードパーティーの ID プロバイダー (IdP) 経由でフェデレーション方式で認証を行うことができます。ユーザープールは、Facebook、Google、Amazon、Apple 経由のソーシャルサインイン、および OpenID Connect (OIDC) と SAML IdP から返されるトークンの処理のオーバーヘッドを管理します。詳細については、「[ユーザープール JSON ウェブトークン (JWT) の理解](amazon-cognito-user-pools-using-tokens-with-identity-providers.md)」を参照してください。

認証が正常に行われると、アプリケーションが Amazon Cognito からユーザープールトークンを受け取ります。ユーザープールトークンを使用すると、次のことができます。
+ Amazon DynamoDB や Amazon S3 AWS のサービス などの のアプリケーションリソースのリクエストを承認する AWS 認証情報を取得します。
+ 一時的で取り消し可能な認証の証拠を提供します。
+ アプリケーションのユーザープロファイルに ID データを入力します。
+ ユーザープールディレクトリでサインインしたユーザーのプロファイルの変更を認可します。
+ アクセストークンを使用して、ユーザー情報のリクエストを認可します。
+ アクセストークンを使用して、アクセス保護された外部 API の背後にあるデータへのリクエストを認可します。
+ Amazon Verified Permissions を使用して、クライアントまたはサーバーに保存されているアプリケーションアセットへのアクセスを認可します。

詳細については、「[認証セッションの例](authentication.md#amazon-cognito-user-pools-authentication-flow)」および「[ユーザープール JSON ウェブトークン (JWT) の理解](amazon-cognito-user-pools-using-tokens-with-identity-providers.md)」を参照してください。

![\[認証の概要。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/scenario-authentication-cup.png)


**Topics**
+ [Amazon Verified Permissions を使用したクライアントまたはサーバーリソースへのアクセスの認可](scenario-backend.md)
+ [サインイン後の API Gateway を使用したリソースへのアクセス](user-pool-accessing-resources-api-gateway-and-lambda.md)
+ [サインイン後の ID プール AWS のサービス を使用した へのアクセス](amazon-cognito-integrating-user-pools-with-identity-pools.md)

# Amazon Verified Permissions を使用したクライアントまたはサーバーリソースへのアクセスの認可
<a name="scenario-backend"></a>

アプリケーションは、サインインしたユーザーから [Amazon Verified Permissions](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/what-is-avp.html) にトークンを渡すことができます。Verified Permissions は、構築したアプリケーション向けの、スケーラブルできめ細かなアクセス許可管理および認可サービスです。Amazon Cognito ユーザープールは、Verified Permissions ポリシーストアの ID ソースにすることができます。Verified Permissions は、ユーザープールトークンのプリンシパルとその属性から、`premium_badge.png`、`GetPhoto` などのリクエストされたアクションとリソースの認可に関する決定を行います。

次の図は、アプリケーションが認可リクエストでユーザーのトークンを Verified Permissions に渡す方法を示しています。

![\[Amazon Cognito ユーザープールで認証し、Amazon Verified Permissions を使用してローカルリソースへのアクセスを認可するアプリケーションのフロー図。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/access-services-local-resources.png)


**Amazon Verified Permissions の使用開始**  
ユーザープールを Verified Permissions と統合すると、すべての Amazon Cognito アプリケーションに対する詳細な認のを一元的ソースを取得できます。これにより、すべてのアプリケーション間でコーディングとレプリケートを行う必要があるきめ細かなセキュリティロジックが不要になります。Verified Permissions による認可の詳細については、「[Amazon Verified Permissions による承認](amazon-cognito-authorization-with-avp.md)」を参照してください。

Verified Permissions 認可リクエストには AWS 認証情報が必要です。認可リクエストに認証情報を安全に適用するには、以下の手法の一部を実装できます。
+ サーバーのバックエンドにシークレットを保存できるウェブアプリケーションを運用します。
+ 認証されたアイデンティティプールの認証情報を取得します。
+ アクセストークン認証 API を使用してユーザーリクエストをプロキシし、リクエストに AWS 認証情報を追加します。

# サインイン後の API Gateway を使用したリソースへのアクセス
<a name="user-pool-accessing-resources-api-gateway-and-lambda"></a>

Amazon Cognito ユーザープールトークンの一般的な用途は、[API Gateway REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html) へのリクエストを認可することです。アクセストークンの OAuth 2.0 スコープは、`/app_assets` 用の `HTTP GET` のようなメソッドとパスを認可できます。ID トークンは API への汎用認証として機能し、ユーザー属性をバックエンドサービスに渡すことができます。API Gateway には、[HTTP API 用の JWT オーソライザー](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html)や [Lambda オーソライザー](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)などの追加のカスタム認証オプションがあり、よりきめ細かなロジックを適用できます。

次の図は、アクセストークンの OAuth 2.0 スコープを使用して REST API へのアクセスを取得しているアプリケーションを示しています。

![\[Amazon Cognito ユーザープールを使用して認証し、Amazon API Gateway を使用して API リソースへのアクセスを認可するアプリケーションのフロー図。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/access-services-api-gateway.png)


アプリケーションは、認証されたセッションからトークンを収集し、それらをベアラトークンとしてリクエストの `Authorization` ヘッダーに追加する必要があります。API、パス、およびメソッド用に設定したオーソライザーを設定して、トークンの内容を評価します。API Gateway は、オーソライザー用に設定した条件にリクエストが一致する場合にのみデータを返します。

API Gateway API がアプリケーションからのアクセスを承認できる可能性のある方法は次のとおりです。
+ アクセストークンは有効であり、有効期限が切れておらず、正しい OAuth 2.0 スコープが含まれています。[REST API 用の Amazon Cognito ユーザープールオーソライザー](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)は、エントリに対する障壁が低い一般的な実装です。また、このタイプのオーソライザーへのリクエストの本文、クエリ文字列パラメータ、およびヘッダーを評価することもできます。
+ ID トークンは有効であり、有効期限が切れていません。ID トークンを Amazon Cognito オーソライザーに渡すと、アプリケーションサーバーで ID トークンの内容をさらに検証できます。
+ アクセストークンまたは ID トークンのグループ、クレーム、属性、ロールは、Lambda 関数で定義した要件を満たします。[Lambda オーソライザー](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)は、リクエストヘッダー内のトークンを解析し、認可に関する決定のために評価します。関数にカスタムロジックを構築するか、[Amazon Verified Permissions](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/what-is-avp.html) に API リクエストを行うことができます。

また、ユーザープールからのトークンを使用して [AWS AppSync GraphQL API](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html#amazon-cognito-user-pools-authorization) へのリクエストを認可することもできます。

# サインイン後の ID プール AWS のサービス を使用した へのアクセス
<a name="amazon-cognito-integrating-user-pools-with-identity-pools"></a>

ユーザーがユーザープールでサインインすると、ID プールから発行された一時的な API 認証情報 AWS のサービス を使用して にアクセスできます。

ウェブアプリケーションまたはモバイルアプリケーションは、ユーザープールからトークンを受け取ります。ユーザープールを ID プールの ID プロバイダーとして設定すると、ID プールはトークンを一時的な AWS 認証情報と交換します。これらの認証情報は、限られた AWS リソースセットへのアクセスをユーザーに付与する IAM ロールとそのポリシーに限定できます。詳細については、「[ID プールの認証フロー](authentication-flow.md)」を参照してください。

次の図は、アプリケーションがユーザープールでサインインし、アイデンティティプールの認証情報を取得し、 AWS のサービスにアセットをリクエストする方法を示しています。

![\[Amazon Cognito ユーザープールで認証し、ID プールを持つ AWS リソースへのアクセスを許可するアプリケーションのフロー図。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/access-services-identity-pool.png)


アイデンティティプールの認証情報を使用すると、次のことができます。
+ ユーザー自身の認証情報を使用して、Amazon Verified Permissions にきめ細かな認証リクエストを行います。
+ IAM との接続を許可する Amazon API Gateway REST API または AWS AppSync GraphQL API に接続します。
+ IAM への接続を認可する Amazon DynamoDB や Amazon RDS などのデータベースバックエンドに接続します。
+ Amazon S3 バケットからアプリケーションアセットを取得します。
+ Amazon WorkSpaces 仮想デスクトップでセッションを開始します。

アイデンティティプールは、ユーザープールを用いて認証されたセッション内でのみ動作するわけではありません。また、サードパーティー ID プロバイダーから直接認証を受け入れ、認証されていないゲストユーザーの認証情報を生成することもできます。

ID プールをユーザープールグループと一緒に使用して AWS リソースへのアクセスを制御する方法の詳細については、[ユーザープールにグループを追加する](cognito-user-pools-user-groups.md)「」および「」を参照してください[ロールベースアクセスコントロールの使用](role-based-access-control.md)。また、ID プールの詳細については AWS Identity and Access Management、「」を参照してください[ID プールの認証フロー](authentication-flow.md)。

## を使用したユーザープールの設定 AWS マネジメントコンソール
<a name="amazon-cognito-integrating-user-pools-with-identity-pools-setting-up"></a>

Amazon Cognito ユーザープールを作成し、クライアントアプリごとに [**User Pool ID**] (ユーザープール ID) と [**App Client ID**] (アプリクライアント ID) をメモしておきます。ユーザープール作成の詳細については、「[ユーザープールの開始方法](getting-started-user-pools.md)」を参照してください。

## を使用した ID プールの設定 AWS マネジメントコンソール
<a name="amazon-cognito-integrating-user-pools-with-identity-pools-configuring"></a>

次の手順では、 を使用して ID プール AWS マネジメントコンソール を 1 つ以上のユーザープールおよびクライアントアプリケーションと統合する方法について説明します。

**Amazon Cognito のユーザープール ID プロバイダー (IdP) を追加するには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)で **[ID プールの管理]** をクリックします。アイデンティティプールを選択します。

1. **[ユーザーアクセス]** タブを選択します。

1. **[ID プロバイダーを追加]** を選択します。

1. **[Amazon Cognito ユーザープール]** を選択します。

1. **ユーザープール ID** と**アプリクライアント ID** を入力します。

1. Amazon Cognito がこのプロバイダーで認証されたユーザーに認証情報を発行するときにリクエストするロールを設定するには、[**ロール設定**] を設定します。

   1. その IdP のユーザーに、**認証済みロール**を設定したときに設定した**デフォルトロール**を与えることも、**ルール付きのロールを選択**することもできます。Amazon Cognito ユーザープール IdP では、**トークンの優先ロールクレームを持つロールを選択**することもできます。`cognito:preferred_role` クレームの詳細については、「[グループへの優先順位の値の割り当て](cognito-user-pools-user-groups.md#assigning-precedence-values-to-groups)」を参照してください。

      1. **[ルールを使用してロールを選択する]** を選択した場合、ユーザー認証からのソース**クレーム**、ルールへのクレームを比較するために使用する**オペレータ**、このロール選択と一致する**値**、および**ロール割り当て**が一致したときに割り当てる**ロール**を入力します。別の条件に基づいて追加のルールを作成するには、**[別のものを追加]** を選択します。

      1. **[トークンの優先ロールクレームを持つロールを選択]** を選択した場合、Amazon Cognito はユーザーの `cognito:preferred_role` クレームでロールの認証情報を発行します。優先ロールクレームが存在しない場合、Amazon Cognito は**ロール解決**に基づいて認証情報を発行します。

   1. **[ロールの解決]** を選択します。ユーザーのクレームがルールに合わない場合は、認証情報を拒否するか、**認証済みロール**の認証情報を発行できます。

1. Amazon Cognito がこのプロバイダーで認証されたユーザーに認証情報を発行するときに割り当てるプリンシパルタグを変更するには、**[アクセスコントロールの属性]** を設定します。
   + プリンシパルタグを適用しない場合は、**[非アクティブ]** を選択します。
   + `sub` および `aud` クレームに基づいてプリンシパルタグを適用するには、**[デフォルトマッピングを使用]** を選択します。
   + プリンシパルタグへの属性の独自のカスタムスキーマを作成するには、**[カスタムマッピングを使用]** を選択します。次に、タグに表示したい各**クレーム**から取得する**タグキー**を入力します。

1. **[変更を保存]** を選択します。

## ユーザープールを ID プールと統合する
<a name="amazon-cognito-integrating-user-pools-with-identity-pools-using"></a>

アプリユーザーが認証されると、認証情報プロバイダーのログインマップにユーザーのアイデンティティトークンを追加します。プロバイダー名は、Amazon Cognito ユーザープール ID に応じて異なります。次の構造になります。

```
cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>
```

*<region>* の値は、**ユーザープール ID** から取得できます。例えば、ユーザープール ID が `us-east-1_EXAMPLE1` の場合、*<region>* は `us-east-1` になります。ユーザープール ID が `us-west-2_EXAMPLE2` の場合、*<region>* は `us-west-2` になります。

------
#### [ JavaScript ]

```
var cognitoUser = userPool.getCurrentUser();

if (cognitoUser != null) {
	cognitoUser.getSession(function(err, result) {
		if (result) {
			console.log('You are now logged in.');

			// Add the User's Id Token to the Cognito credentials login map.
			AWS.config.credentials = new AWS.CognitoIdentityCredentials({
				IdentityPoolId: 'YOUR_IDENTITY_POOL_ID',
				Logins: {
					'cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>': result.getIdToken().getJwtToken()
				}
			});
		}
	});
}
```

------
#### [ Android ]

```
cognitoUser.getSessionInBackground(new AuthenticationHandler() {
	@Override
	public void onSuccess(CognitoUserSession session) {
		String idToken = session.getIdToken().getJWTToken();

		Map<String, String> logins = new HashMap<String, String>();
		logins.put("cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>", session.getIdToken().getJWTToken());
		credentialsProvider.setLogins(logins);
	}

});
```

------
#### [ iOS - objective-C ]

```
AWSServiceConfiguration *serviceConfiguration = [[AWSServiceConfiguration alloc] initWithRegion:AWSRegionUSEast1 credentialsProvider:nil];
AWSCognitoIdentityUserPoolConfiguration *userPoolConfiguration = [[AWSCognitoIdentityUserPoolConfiguration alloc] initWithClientId:@"YOUR_CLIENT_ID"  clientSecret:@"YOUR_CLIENT_SECRET" poolId:@"YOUR_USER_POOL_ID"];
[AWSCognitoIdentityUserPool registerCognitoIdentityUserPoolWithConfiguration:serviceConfiguration userPoolConfiguration:userPoolConfiguration forKey:@"UserPool"];
AWSCognitoIdentityUserPool *pool = [AWSCognitoIdentityUserPool CognitoIdentityUserPoolForKey:@"UserPool"];
AWSCognitoCredentialsProvider *credentialsProvider = [[AWSCognitoCredentialsProvider alloc] initWithRegionType:AWSRegionUSEast1 identityPoolId:@"YOUR_IDENTITY_POOL_ID" identityProviderManager:pool];
```

------
#### [ iOS - swift ]

```
let serviceConfiguration = AWSServiceConfiguration(region: .USEast1, credentialsProvider: nil)
let userPoolConfiguration = AWSCognitoIdentityUserPoolConfiguration(clientId: "YOUR_CLIENT_ID", clientSecret: "YOUR_CLIENT_SECRET", poolId: "YOUR_USER_POOL_ID")
AWSCognitoIdentityUserPool.registerCognitoIdentityUserPoolWithConfiguration(serviceConfiguration, userPoolConfiguration: userPoolConfiguration, forKey: "UserPool")
let pool = AWSCognitoIdentityUserPool(forKey: "UserPool")
let credentialsProvider = AWSCognitoCredentialsProvider(regionType: .USEast1, identityPoolId: "YOUR_IDENTITY_POOL_ID", identityProviderManager:pool)
```

------

# スコープ、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` クレームをチェックします。

# ユーザープールの機能を設定する
<a name="user-pools-configure-features"></a>

これまでの章では、Amazon Cognito コンソールからのガイダンスに従っていくつかの機能を設定してみました。このセクションのページでは、ユーザープールの主要機能の一部について、設定要件をより掘り下げます。アプリケーションクライアント、E メールと SMS の設定、ユーザーデバイスの記憶などのオプションについて、重要なリファレンス情報があります。

**Topics**
+ [ユーザープールとアプリケーションクライアントの設定更新](cognito-user-pool-updating.md)
+ [アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)
+ [ユーザープール内のユーザーデバイスの使用](amazon-cognito-user-pools-device-tracking.md)
+ [ユーザープール分析に Amazon Pinpoint を使用する](cognito-user-pools-pinpoint-integration.md)
+ [Amazon Cognito ユーザープールの E メール設定](user-pool-email.md)
+ [Amazon Cognito ユーザープール用の SMS メッセージ設定](user-pool-sms-settings.md)

# ユーザープールとアプリケーションクライアントの設定更新
<a name="cognito-user-pool-updating"></a>

ユーザープールまたはアプリケーションクライアントの設定を変更する場合は、Amazon Cognito コンソールで数回クリックすれば更新を適用できます。ユーザープール設定の機能ベースのタブを移動して、このガイドの他のエリアの説明に従ってフィールドを更新します。

多くの組織は、 のリソース AWS CloudFormation、 AWS SDKsまたは CDK 上に構築されたアプリケーション、およびその他のオートメーションソフトウェアをプログラムで管理しています。これがリソース管理モデルである場合は、リソースの変更を段階的に行うときに特に注意する必要があります。

API オペレーションの [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) および [ UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) は、既存のユーザープールまたはアプリケーションクライアントを更新します。それぞれに、次の API リファレンスの警告が表示されます: *属性の値を指定しない場合、Amazon Cognito はそれをデフォルト値に設定します。*1 つのパラメータのみを使用して更新リクエストを送信すると、Amazon Cognito はそのパラメータを選択した値に設定し、他のすべてのパラメータをデフォルト値に設定します。これにより、属性スキーマ、Lambda トリガー、E メールおよび SMS メッセージ設定などの設定をリセットできます。

さらに、ユーザープールまたはアプリケーションクライアントの作成後に一部の設定がロックされ、新しいリソースを作成しない限り変更することはできません。

**Topics**
+ [変更できない設定](#cognito-user-pool-updating-fixed-settings)
+ [SMS 設定](#cognito-user-pool-updating-sms)
+ [AWS SDK、 AWS CDK、または REST API を使用したユーザープールの更新](#cognito-user-pool-updating-api-cli)

## 変更できない設定
<a name="cognito-user-pool-updating-fixed-settings"></a>

ユーザープールを作成した後に、この設定を変更することはできません。以下の設定を変更する場合は、新しいユーザープールまたはアプリクライアントを作成する必要があります。

**注記**  
以前は、ユーザープールの名前を変更できませんでした。これは変更されました。ユーザープールに新しいわかりやすい名前を割り当てることができるようになりました。

**ユーザープール ID**  
API パラメータ名: [Id/UserPoolId](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserPoolType.html#CognitoUserPools-Type-UserPoolType-ID)  
ユーザープール ID (`us-east-1_EXAMPLE` など) は、Amazon Cognito によって自動生成され、変更できません。

**Amazon Cognito ユーザープールサインインオプション**  
API パラメータ名: [AliasAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-AliasAttributes) と [UsernameAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-UsernameAttributes)  
ユーザーがサインインするときにユーザー名として渡すことができる属性。ユーザープールを作成するときに、ユーザー名、E メールアドレス、電話番号、または優先ユーザー名を使用してサインインを許可するかどうかを選択できます。ユーザープールサインインオプションを変更するには、新しいユーザープールを作成します。

**ユーザー名の大文字と小文字を区別する**  
API パラメータ名: [UsernameConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-UsernameConfiguration)  
大文字と小文字以外の別のユーザー名と一致するユーザー名を作成した場合、Amazon Cognito では同じユーザーまたは一意のユーザーとして扱うことができます。詳細については、「[ユーザープールの大文字と小文字の区別](user-pool-case-sensitivity.md)」を参照してください。大文字と小文字の区別を変更するには、新しいユーザープールを作成します。

**クライアントシークレット**  
API パラメータ名: [GenerateSecret](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html#CognitoUserPools-CreateUserPoolClient-request-GenerateSecret)  
アプリクライアントを作成するときに、信頼されたソースだけがユーザープールにリクエストを送信できるように、クライアントシークレットを生成できます。詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。クライアントシークレットを変更するには、同じユーザープール内に新しいアプリクライアントを作成します。

**必須の属性**  
API パラメータ名: [Schema](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-Schema)  
ユーザーのサインアップ時または作成時に値を提供する必要がある属性。詳細については、「[ユーザー属性の操作](user-pool-settings-attributes.md)」を参照してください。必要な属性を変更するには、新しいユーザープールを作成します。

**カスタム属性 (削除)**  
API パラメータ名: [Schema](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-Schema)  
カスタム名を持つ属性です。ユーザーのカスタム属性の値を変更することはできますが、ユーザープールからカスタム属性を削除することはできません。詳細については、「[ユーザー属性の操作](user-pool-settings-attributes.md)」を参照してください。カスタム属性の最大数に達してリストを変更する場合は、新しいユーザープールを作成します。

## SMS 設定
<a name="cognito-user-pool-updating-sms"></a>

ユーザープールで SMS メッセージをアクティブ化した後は、それらを非アクティブ化できません。
+ ユーザープールの作成時に SMS メッセージを設定することを選択した場合、セットアップ完了後に SMS を非アクティブ化できません。
+ 作成したユーザープールで SMS メッセージをアクティブ化できますが、その後は SMS を非アクティブ化できません。
+ Amazon Cognito では、ユーザーアカウントの招待と復旧、属性の検証、多要素認証 (MFA) に SMS メッセージを使用できます。SMS メッセージをアクティブ化した後は、いつでも SMS メッセージでこれらの機能をオンまたはオフにできます。
+ SMS メッセージ設定には、Amazon SNS によるメッセージ送信を Amazon Cognito に委任する IAM ロールが含まれています。割り当てられたロールはいつでも変更できます。

## AWS SDK、 AWS CDK、または REST API を使用したユーザープールの更新
<a name="cognito-user-pool-updating-api-cli"></a>

Amazon Cognito コンソールでは、ユーザープールの設定を 1 つのパラメータずつ変更できます。例えば、Lambda トリガーを追加するには、**[Lambda トリガーを追加]** を選択し、関数とトリガーのタイプを選択します。Amazon Cognito ユーザープール API は、ユーザープールとアプリケーションクライアントの更新オペレーションに、ユーザープールのパラメータ一式が必要となるように構成されています。ただし、コンソールは他のユーザープール設定を使用して、この更新オペレーションを透過的に自動化します。

の他の場所での変更によって、変更する設定に関連しない AWS アカウント 更新でエラーが発生することがあります。例えば、削除された Amazon SES ID AWS WAFや IAM アクセス許可の変更。現在のパラメータの 1 つが無効になった場合、それを修正するまで設定を更新できません。このようなエラーが発生した場合は、エラー応答を調べ、言及されている設定を検証します。

[AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk)、[Amazon Cognito ユーザープール REST API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html) および [AWS SDK](https://aws.amazon.com/developer/tools/) は、Amazon Cognito リソースの自動化とプログラムによる設定を行うためのツールです。これらのツールを使用したリクエストは、Amazon Cognito コンソールと同様に、リクエスト本文の完全なリソース設定で設定の更新を行う必要もあります。概要としては、以下のプロセスを実行する必要があります。

1. 既存のリソースの設定を記述するオペレーションから出力をキャプチャします。

1. 設定を変更して出力を変更します。

1. リソースを更新するオペレーションで、変更された設定を送信します。

次の手順で、[UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API オペレーションを使用して設定を更新します。入力フィールドが異なる同じアプローチが、[UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) に適用されます。

**重要**  
既存のパラメータの値を提供しない場合、Amazon Cognito はそれらをデフォルト値に設定します。例えば、既存の `LambdaConfig` がある場合に、空の `LambdaConfig` で `UpdateUserPool` を送信すると、すべての Lambda 関数のユーザープールトリガーへの割り当てが削除されます。ユーザープール設定の変更を自動化する場合は、適宜計画を立ててください。

1. [DescribeUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPool.html) を使用して、ユーザープールの既存の状態をキャプチャします。

1. `DescribeUserPool` の出力を `UpdateUserPool` の[リクエストパラメータ](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html#API_UpdateUserPool_RequestSyntax)と一致するようにフォーマットします。出力される JSON から次のトップレベルフィールドとその子オブジェクトを削除します。
   + `Arn`
   + `CreationDate`
   + `CustomDomain`
     + このフィールドを [UpdateUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolDomain.html) API オペレーションを使用して更新します。
   + `Domain`
     + このフィールドを [UpdateUserPoolDomain](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolDomain.html) API オペレーションを使用して更新します。
   + `EmailConfigurationFailure`
   + `EstimatedNumberOfUsers`
   + `Id`
   + `LastModifiedDate`
   + `Name`
   + `SchemaAttributes`
   + `SmsConfigurationFailure`
   + `Status`

1. 生成された JSON が `UpdateUserPool` の[リクエストパラメータ](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html#API_UpdateUserPool_RequestSyntax)と一致することを確認します。

1. 生成された JSON で変更するパラメータを変更します。

1. 変更した JSON をリクエスト入力として使用する `UpdateUserPool` API リクエストを送信します。

また、 AWS CLIの `update-user-pool` の `--cli-input-json` パラメータで、この修正した `DescribeUserPool` の出力を使用することもできます。

または、次の AWS CLI コマンドを実行して、 で受け入れられる入力フィールドの値が空白の JSON を生成します`update-user-pool`。その後、これらのフィールドにユーザープールの既存の値を入力できます。

```
aws cognito-idp update-user-pool --generate-cli-skeleton --output json
```

次のコマンドを実行して、アプリクライアント用に同じ JSON オブジェクトを生成します。

```
aws cognito-idp update-user-pool-client --generate-cli-skeleton --output json
```

# アプリケーションクライアントによるアプリケーション固有の設定
<a name="user-pool-settings-client-apps"></a>

ユーザープールアプリケーションクライアントは、Amazon Cognito で認証される 1 つのモバイルアプリケーションまたはウェブアプリケーションを操作するユーザープール内の設定です。アプリケーションクライアントは、認証済みおよび未認証の API オペレーションを呼び出したり、ユーザーの属性の一部またはすべてを読み取ったり変更したりできます。アプリでは、登録、サインイン、パスワードを忘れた場合の処理を行う際に、アプリクライアントに対して自分自身を識別する必要があります。これらの API リクエストには、アプリクライアント ID による自己識別と、オプションのクライアントシークレットによる認可が含まれていなければなりません。認証されたクライアントアプリのみがこれらの認証されていない API を呼び出すことができるように、アプリクライアント ID またはシークレットをセキュア化する必要があります。さらに、認証された API リクエストに AWS 認証情報で署名するようにアプリを設定する場合は、認証情報をユーザー検査から保護する必要があります。

ユーザープールには複数のアプリを作成できます。アプリクライアントは、アプリのコードプラットフォームにリンクされている場合もあれば、ユーザープール内の別のテナントにリンクされている場合もあります。例えば、サーバー側アプリケーション用のアプリと、別の Android アプリを作成することができます。各アプリには独自のアプリのクライアント ID があります。

アプリケーションクライアントレベルで、次のユーザープール機能の設定を適用できます。

1. [分析](cognito-user-pools-pinpoint-integration.md)

1. [マネージドログイン](cognito-user-pools-managed-login.md)の IdP、付与タイプ、コールバック URL、およびカスタマイズ

1. [リソースサーバーとカスタムスコープ](cognito-user-pools-define-resource-servers.md)

1. [脅威保護](cognito-user-pool-settings-threat-protection.md)

1. [属性の読み取り/書き込み許可](user-pool-settings-attributes.md#user-pool-settings-attribute-permissions-and-scopes)

1. [トークンの有効期限と取り消し](amazon-cognito-user-pools-using-tokens-with-identity-providers.md)

1. [認証フロー](authentication.md#amazon-cognito-user-pools-authentication-flow)

## アプリクライアントの種類
<a name="user-pool-settings-client-app-client-types"></a>

Amazon Cognito でアプリクライアントを作成する際、標準の OAuth クライアントタイプである**パブリッククライアント**と**機密クライアント**に基づいたオプションを事前に入力できます。**クライアントシークレット**を持つ**機密クライアント**を設定します。クライアントの種類の詳細については、[IETF RFC 6749 \$12.1](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1) を参照してください。

**パブリッククライアント**  
パブリッククライアントは、ブラウザまたはモバイルデバイスで実行されます。信頼できるサーバー側リソースがないため、クライアントシークレットはありません。

**機密クライアント**  
機密クライアントには、認証されていない API オペレーションの**クライアントシークレット**で信頼できるサーバー側のリソースがあります。アプリケーションは、バックエンドサーバー上でデーモンまたはシェルスクリプトとして実行されることがあります。

**クライアントシークレット**  
クライアントシークレットまたはクライアントパスワードは、アプリクライアントへのすべての API リクエストでアプリが使用する必要がある固定文字列です。アプリクライアントには、アプリクライアントには、`client_credentials` 付与を実行するためのクライアントシークレットが必要です。詳細については、[IETF RFC 6749 \$12.3.1](https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1) を参照してください。  
各アプリケーションクライアントは一度に最大 2 つのシークレットを持つことができ、ダウンタイムなしでシークレットをローテーションできます。アプリケーションクライアントを作成するときに、Amazon Cognito にシークレット値を生成させるか、独自のカスタムシークレット値を提供させることができます。アプリを作成した後は、シークレットを変更できません。[AddUserPoolClientSecret](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AddUserPoolClientSecret.html) API オペレーションを使用して 2 番目のシークレットを追加して、シークレットをローテーションできます。シークレットを追加するときは、Amazon Cognito にシークレット値を生成させるか、独自のカスタムシークレット値を提供させることができます。シークレットを削除するには、[DeleteUserPoolClientSecret](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserPoolClientSecret.html) API オペレーションを使用します。アプリケーションクライアントに関連付けられた唯一のシークレットを削除することはできません。また、そのアプリのクライアント ID を使用するアプリケーションからのアクセスを遮断するためにアプリケーションを削除できます。  
アプリケーションタイプとして **[従来のウェブアプリケーション]** オプションと **[Machine to Machine アプリケーション]** オプションを選択すると、Amazon Cognito コンソールはクライアントシークレットを持つアプリケーションクライアントを作成します。これらのオプションのいずれかを選択してクライアントシークレットを生成するか、[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) を使用してプログラムでクライアントを作成して `GenerateSecret` を `true` に設定します。

パブリックアプリでは、機密クライアントとクライアントシークレットを使用できます。Amazon CloudFront プロキシを使用して、転送中の `SECRET_HASH` を追加します。詳細については、 AWS ブログの「[Amazon CloudFront プロキシを使用して Amazon Cognito のパブリッククライアントを保護する](https://aws.amazon.com/blogs/security/protect-public-clients-for-amazon-cognito-by-using-an-amazon-cloudfront-proxy/)」を参照してください。

## JSON ウェブトークン
<a name="user-pool-settings-client-app-token-types"></a>

Amazon Cognito アプリクライアントは、以下のタイプの JSON ウェブトークン (JWT) を発行できます。

**アイデンティティ (ID) トークン**  
ユーザーがユーザープールから認証されていることを示す検証可能なステートメント。OpenID Connect (OIDC) は、OAuth 2.0 で定義されているアクセストークンとリフレッシュトークンの標準に [ID トークンの仕様](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)を追加しました。ID トークンには、アプリがユーザープロファイルの作成やリソースのプロビジョニングに使用できるユーザー属性などの ID 情報が含まれています。詳細については「[ID トークンの理解](amazon-cognito-user-pools-using-the-id-token.md)」を参照してください。

**アクセストークン**  
ユーザーのアクセス権を示す検証可能なステートメント。アクセストークンには、OIDC と OAuth 2.0 の機能である[スコープ](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3)が含まれています。アプリは、バックエンドリソースにスコープを提示することで、ユーザープールが API のデータや独自のユーザーデータへのアクセスをユーザーまたはマシンに許可していることを証明できます。*カスタムスコープ*を持つアクセストークンは、多くの場合、M2M クライアント認証情報の付与により、リソースサーバーへのアクセスを許可します。詳細については「[アクセストークンの理解](amazon-cognito-user-pools-using-the-access-token.md)」を参照してください。

**更新トークン**  
ユーザーのトークンが有効期限切れになったときにアプリがユーザープールに提示できる、暗号化された初期認証ステートメント。更新トークンをリクエストすると、有効期限が切れていない新しいアクセストークンと ID トークンが返されます。詳細については「[更新トークン](amazon-cognito-user-pools-using-the-refresh-token.md)」を参照してください。

各アプリケーションクライアントのこれらのトークンの有効期限は、[Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/v2/idp/user-pools)でユーザープールの **[アプリケーションクライアント]** メニューから設定できます。

## アプリクライアントの用語
<a name="cognito-user-pools-app-idp-settings-about"></a>

Amazon Cognito コンソールで、アプリクライアントに使用できる用語は次のとおりです。

**許可されているコールバック URL**  
コールバック URL は、ユーザーがサインインに成功したときにリダイレクトされる先を指定します。少なくとも 1 つのコールバック URL を選択してください。コールバック URL は、以下が必要です。  
+ 絶対 URI である。
+ クライアントに事前登録されている。
+ フラグメントコンポーネントを含まない。
「[OAuth 2.0 - リダイレクトエンドポイント](https://tools.ietf.org/html/rfc6749#section-3.1.2)」を参照してください。  
Amazon Cognito は、テスト目的限定の `HTTPS` を除き、`HTTP` ではなく `http://localhost` を使用します。  
また、アプリのコールバック URL (例: `myapp://example`) もサポートされています。

**許可されているサインアウト URL**  
サインアウト URL は、ユーザーがサインアウトしたときにリダイレクトされる先を指定します。

**属性の読み取りおよび書き込み許可**  
ユーザープールには多数の顧客がいて、それぞれが独自のアプリクライアントと IdP を使用している場合があります。アプリに関連したユーザー属性のみの読み取りおよび書き込みアクセスを許可するようにアプリクライアントに設定できます。マシンツーマシン (M2M) 認可のように、すべてのユーザー属性へのアクセスを禁止することもできます。  

**属性の読み取りおよび書き込みアクセス権限の設定に関する考慮事項**
+ アプリケーションクライアントを作成する場合で、属性の読み取り/書き込みアクセス許可をカスタマイズしない場合、Amazon Cognito はすべてのユーザープール属性に読み取り/書き込みアクセス許可を付与します。
+ イミュータブルな[カスタム属性](user-pool-settings-attributes.md#user-pool-settings-custom-attributes.title)への書き込みアクセス権を付与できます。ユーザーの作成時またはサインアップ時に、アプリケーションクライアントはイミュータブルな属性に値を書き込むことができます。その後は、ユーザーのイミュータブルなカスタム属性に値を書き込むことはできません。
+ アプリクライアントは、ユーザープール内の必須属性への書き込み権限を持っている必要があります。Amazon Cognito コンソールは、必須の属性を自動的に書き込み可能に設定します。
+ アプリケーションクライアントに対して、`email_verified` または `phone_number_verified` への書き込みアクセス権限を付与することはできません。ユーザープール管理者は、これらの値を変更できます。ユーザーは、これらの属性の値を[属性の検証](signing-up-users-in-your-app.md#allowing-users-to-sign-up-and-confirm-themselves.title)でのみ変更できます。

**認証フロー**  
アプリクライアントが許可するサインイン方法。アプリケーションは、ユーザー名とパスワードによる認証、E メールおよび SMS メッセージの OTP、パスキー認証、Lambda トリガーによるカスタム認証、トークン更新をサポートできます。セキュリティのベストプラクティスとして、カスタム構築されたアプリケーションでのユーザー名とパスワード認証には SRP 認証を使用します。

**カスタムスコープ**  
カスタムスコープは、[**リソースサーバー**] で各自のリソースサーバー用に定義したものです。形式は *resource-server-identifier*/*scope* です。「[スコープ、M2M、リソースサーバー](cognito-user-pools-define-resource-servers.md)」を参照してください。

**デフォルトのリダイレクト URI**  
サードパーティー IdP を持つユーザーの認証リクエストの `redirect_uri` パラメータを置き換えます。[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) API リクエストまたは [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) API リクエストの `DefaultRedirectURI` パラメータを使用して、このアプリケーションクライアント設定をセットアップします。また、この URL は、アプリケーションクライアント用の `CallbackURLs` のメンバーである必要もあります。Amazon Cognito は、次の場合に、認証されたセッションをこの URL にリダイレクトします。  

1. アプリケーションクライアントには、1 つの [ID プロバイダー](#app-client-terms-identity-provider)が割り当てられ、複数の[コールバック URL](#app-client-terms-callback-urls) が定義されています。ユーザープールは、認証リクエストに `redirect_uri` パラメータが含まれていない場合、[認可サーバー](authorization-endpoint.md)への認証リクエストをデフォルトのリダイレクト URI にリダイレクトします。

1. アプリケーションクライアントには、1 つの [ID プロバイダー](#app-client-terms-identity-provider)が割り当てられ、1 つの[コールバック URL](#app-client-terms-callback-urls) が定義されています。このシナリオでは、デフォルトのコールバック URL を定義する必要はありません。`redirect_uri` パラメータを含まないリクエストは、使用可能なコールバック URL の 1 つにリダイレクトされます。

**ID プロバイダ**  
ユーザープールの外部 ID プロバイダー (IdP) の一部またはすべてを選択して、ユーザーを認証できます。アプリクライアントは、ユーザープール内のローカルユーザーのみを認証することもできます。IdP をアプリケーションクライアントに追加すると、IdP への認可リンクを生成して、マネージドログインのサインインページで表示できます。複数の IdP を割り当てることができ、少なくとも 1 つを割り当てる必要があります。外部 IdP の使用の詳細については、「[サードパーティーの ID プロバイダーを使用したユーザープールへのサインイン](cognito-user-pools-identity-federation.md)」を参照してください。

**OpenID Connect スコープ**  
次の `OAuth` スコープを 1 つ以上選択し、アクセストークン用にリクエストできるアクセス権限を指定します。  
+ `openid` スコープでは、ID トークンとユーザーの固有 ID を取得することを宣言します。また、リクエストに含まれる追加のスコープに応じて、すべてまたは一部のユーザー属性もリクエストします。`openid` スコープをリクエストしない限り、Amazon Cognito は ID トークンを返しません。`openid` スコープは、有効期限やキー ID などの構造的な ID トークンのクレームを承認し、[userInfo エンドポイント](userinfo-endpoint.md) からのレスポンスで受け取るユーザー属性を決定します。
  + リクエストするスコープが `openid` のみである場合、Amazon Cognito は現在のアプリケーションクライアントが読み取ることができるすべてのユーザー属性を ID トークンに入力します。このスコープだけを使用したアクセストークンへの `userInfo` レスポンスにより、すべてのユーザー属性が返されます。
  + `phone`、`email`、`profile` などの他のスコープで `openid` をリクエストすると、ID トークンと `userInfo` はユーザー固有の ID と追加のスコープで定義された属性を返します。
+ `phone` スコープは `phone_number` クレームおよび `phone_number_verified` クレームへのアクセスを付与します。このスコープは `openid` スコープを使用する場合にのみリクエストできます。
+ `email` スコープは `email` クレームおよび `email_verified` クレームへのアクセスを付与します。このスコープは `openid` スコープを使用する場合にのみリクエストできます。
+ `aws.cognito.signin.user.admin` スコープは、[UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html) や [VerifyUserAttribute](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifyUserAttribute.html) など、アクセストークンを必要とする [Amazon Cognito ユーザープール API オペレーション](authentication-flows-public-server-side.md#user-pools-API-operations)へのアクセスを許可します。
+ `profile` スコープはクライアントが読み取り可能なすべてのユーザー属性へのアクセスを付与します。このスコープは `openid` スコープを使用する場合にのみリクエストできます。
スコープの詳細については、[標準 OIDC スコープ](http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims)のリストを参照してください。

**OAuth グラントタイプ**  
OAuth 付与は、ユーザープールのトークンを取得する認証方法です。Amazon Cognito は、以下の付与タイプをサポートしています。これらの OAuth 付与をアプリに統合するには、ユーザープールにドメインを追加する必要があります。  
**認可コード付与**  
認可コード付与は、アプリが[トークンエンドポイント](token-endpoint.md)を使用してユーザープールのトークンと交換できるコードを生成します。認可コードを交換すると、アプリは ID、アクセス、更新の各トークンを受け取ります。この OAuth フローは、暗黙的な付与と同様に、ユーザーのブラウザで発生します。認可コード付与は、トークンがユーザーのセッションで表示されないため、Amazon Cognito が提供する最も安全な付与です。代わりに、アプリはトークンを返すリクエストを生成し、保護されたストレージにトークンをキャッシュできます。詳細については、「[IETF RFC 6749 \$11.3.1](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1)」の「*Authorization Code*」を参照してください。
パブリッククライアントアプリにおけるセキュリティのベストプラクティスとして、認可コード付与の OAuth フローのみを有効にし、Proof Key for Code Exchange (PKCE) を実装してトークン交換を制限します。PKCE では、クライアントは、元の認証リクエストで提示したのと同じシークレットをトークンエンドポイントに提供した場合にのみ、認可コードを交換できます。PKCE の詳細については、[IETF RFC 7636](https://datatracker.ietf.org/doc/html/rfc7636) を参照してください。
**暗黙的な付与**  
暗黙的な付与は、[認可エンドポイント](authorization-endpoint.md) からアクセストークンと ID トークンをユーザのブラウザセッションに直接配信します (更新トークンは配信しません)。暗黙的な付与では、トークンエンドポイントへの個別のリクエストは不要になりますが、PKCE とは互換性がなく、更新トークンは返されません。この付与は、認可コード付与を完了できないテストシナリオやアプリアーキテクチャに対応できます。詳細については、[IETF RFC 6749 \$11.3.2](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.2) の「*暗黙的な付与*」を参照してください。認可コード付与と暗黙的な付与の両方をアプリクライアントで有効にして、必要に応じて使い分けることができます。
**クライアント認証情報の付与**  
クライアント認証情報の付与は、マシンツーマシン (M2M) の通信に使用します。認可コード付与と暗黙的な付与は、認証された人間のユーザーにトークンを発行します。クライアント認証情報の付与は、非対話型システムから API にスコープベースの認可を付与します。アプリは、トークンエンドポイントに対してクライアント認証情報を直接リクエストし、アクセストークンを受け取ることができます。詳細については、[IETF RFC 6749 \$11.3.4](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.4) の「*クライアント認証情報*」を参照してください。クライアント認証情報の付与は、クライアントシークレットを持ち、認可コード付与や暗黙的な付与をサポートしていないアプリクライアントでのみ有効化できます。
ユーザーとしてクライアント認証情報フローを呼び出すことはないため、このフローでアクセストークンに追加できるのはカスタムスコープのみです。**カスタムスコープは、各自のリソースサーバー用に定義したものです。`openid` や `profile` などのデフォルトのスコープは、人間以外のユーザーには適用されません。  
ID トークンはユーザー属性の検証であるため、M2M 通信には関係なく、クライアント認証情報の付与では ID トークンを発行しません。「[スコープ、M2M、リソースサーバー](cognito-user-pools-define-resource-servers.md)」を参照してください。
クライアント認証情報付与は、 AWS 請求書にコストを追加します。詳細については、「[Amazon Cognito の料金](https://aws.amazon.com/cognito/pricing)」を参照してください。

## アプリクライアントの作成
<a name="cognito-user-pools-app-idp-settings-console-create"></a>

------
#### [ AWS マネジメントコンソール ]

**アプリクライアントを作成する (コンソール)**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択、または[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。どちらのオプションでも、アプリケーション固有の設定でアプリケーションクライアントを設定するよう求められます。

1. アプリケーションのアーキテクチャを反映する**アプリケーションタイプ**を選択します。

1. わかりやすい識別子を使用して**アプリケーションに名前を付けます**。

1. **[リターン URL]** に入力します。

1. **[アプリケーションクライアントを作成]** を選択します。詳細オプションは、アプリケーションクライアントの作成後に変更できます。

1. Amazon Cognito は、アプリケーションクライアントの詳細に戻ります。アプリケーションのサンプルコードにアクセスするには、**[Quick Setup ガイド]** タブからプラットフォームを選択します。

------
#### [ AWS CLI ]

```
aws cognito-idp create-user-pool-client --user-pool-id MyUserPoolID --client-name myApp
```

**注記**  
コールバック URL とログアウト URL は、JSON 形式を使用することで、CLI でリモートパラメータファイルとして処理されないようにします。  

```
--callback-urls "["https://example.com"]"
--logout-urls "["https://example.com"]"
```

詳細については、 AWS CLI コマンドリファレンスを参照してください: [create-user-pool-client](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html)

------
#### [ Amazon Cognito user pools API ]

[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) API リクエストを生成します。デフォルト値に設定しないすべてのパラメータには、値を指定する必要があります。

------

## ユーザープールアプリケーションクライアント (AWS CLI および AWS API) の更新
<a name="cognito-user-pools-app-idp-settings-cli-api-update-user-pool-client"></a>

で AWS CLI、次のコマンドを入力します。

```
aws cognito-idp update-user-pool-client --user-pool-id  "MyUserPoolID" --client-id "MyAppClientID" --allowed-o-auth-flows-user-pool-client --allowed-o-auth-flows "code" "implicit" --allowed-o-auth-scopes "openid" --callback-urls "["https://example.com"]" --supported-identity-providers "["MySAMLIdP", "LoginWithAmazon"]"
```

コマンドが成功すると、 は確認 AWS CLI を返します。

```
{
    "UserPoolClient": {
        "ClientId": "MyClientID",
        "SupportedIdentityProviders": [
            "LoginWithAmazon",
            "MySAMLIdP"
        ],
        "CallbackURLs": [
            "https://example.com"
        ],
        "AllowedOAuthScopes": [
            "openid"
        ],
        "ClientName": "Example",
        "AllowedOAuthFlows": [
            "implicit",
            "code"
        ],
        "RefreshTokenValidity": 30,
        "AuthSessionValidity": 3,
        "CreationDate": 1524628110.29,
        "AllowedOAuthFlowsUserPoolClient": true,
        "UserPoolId": "MyUserPoolID",
        "LastModifiedDate": 1530055177.553
    }
}
```

詳細については、 AWS CLI コマンドリファレンス[update-user-pool-client](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)」を参照してください。

AWS API: [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html)

## ユーザープールアプリケーションクライアント (AWS CLI および AWS API) に関する情報の取得
<a name="cognito-user-pools-app-idp-settings-cli-api-describe-user-pool-client"></a>

```
aws cognito-idp describe-user-pool-client --user-pool-id MyUserPoolID --client-id MyClientID
```

詳細については、 AWS CLI コマンドリファレンス[describe-user-pool-client](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/describe-user-pool-client.html)」を参照してください。

AWS API: [DescribeUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPoolClient.html)

## ユーザープール (AWS CLI および AWS API) 内のすべてのアプリケーションクライアント情報を一覧表示する
<a name="cognito-user-pools-app-idp-settings-cli-api-list-user-pool-clients"></a>

```
aws cognito-idp list-user-pool-clients --user-pool-id "MyUserPoolID" --max-results 3
```

詳細については、 AWS CLI コマンドリファレンス[list-user-pool-clients](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/list-user-pool-clients.html)」を参照してください。

AWS API: [ListUserPoolClients](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUserPoolClients.html)

## ユーザープールアプリケーションクライアント (AWS CLI および AWS API) の削除
<a name="cognito-user-pools-app-idp-settings-cli-api-delete-user-pool-client"></a>

```
aws cognito-idp delete-user-pool-client --user-pool-id "MyUserPoolID" --client-id "MyAppClientID"
```

詳細については、 AWS CLI コマンドリファレンスを参照してください: [delete-user-pool-client](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/delete-user-pool-client.html)

AWS API: [DeleteUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserPoolClient.html)

# ユーザープール内のユーザーデバイスの使用
<a name="amazon-cognito-user-pools-device-tracking"></a>

Amazon Cognito ユーザープール API を使用してローカルユーザープールのユーザーをサインインさせる場合、[脅威保護](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-threat-protection.html)からのユーザーのアクティビティログをユーザーの各デバイスに関連付けることができます。また、オプションとして、ユーザーが信頼されたデバイスを使用している場合は、多要素認証 (MFA) をスキップするのを許可できます。Amazon Cognito には、デバイス情報がまだ含まれていないサインインへのレスポンスにデバイスキーが含まれます。デバイスキーの形式は `Region_UUID` です。デバイスキー、Secure Remote Password (SRP) ライブラリ、およびデバイス認証を許可するユーザープールがあれば、アプリ内のユーザーに現在のデバイスを信頼するように求めることができ、サインイン時に MFA コードの入力を求める必要がなくなります。

**Topics**
+ [記憶済みデバイスのセットアップ](#amazon-cognito-user-pools-setting-up-remembered-devices)
+ [デバイスキーの取得](#user-pools-remembered-devices-getting-a-device-key)
+ [デバイスでのサインイン](#user-pools-remembered-devices-signing-in-with-a-device)
+ [デバイスの表示、更新、削除](#user-pools-remembered-devices-viewing-updating-forgetting)

## 記憶済みデバイスのセットアップ
<a name="amazon-cognito-user-pools-setting-up-remembered-devices"></a>

Amazon Cognito ユーザープールでは、ユーザーの各デバイスを固有のデバイス識別子、つまりデバイスキーに関連付けることができます。サインイン時にデバイスキーを提示してデバイス認証を実行すると、*信頼されたデバイス*の認証フローを使用してアプリケーションを設定できます。このフローでは、アプリケーションのセキュリティ要件またはユーザーの設定に応じて、後まで MFA を使わずにサインインする選択肢をユーザーに提示できます。この期間の終了時に、アプリケーションはデバイスのステータスを *[記憶されていない]* に変更し、ユーザーはデバイスを記憶することを確定するまで MFA を使用してサインインする必要があります。例えば、アプリケーションは 30、60、または 90 日間、デバイスを信頼するようにユーザーに求める場合があります。この日付をカスタム属性に保存し、その日にデバイスの記憶されたステータスを変更できます。次に、MFA コードを送信するとともに、認証が完了した後にデバイスを再度記憶するように設定するように、ユーザーに再度求める必要があります。

1. 記憶されているデバイスは、MFA がアクティブなユーザープールでのみ MFA をオーバーライドできます。

ユーザーが記憶されているデバイスでログインする場合、認証フロー中に追加のデバイス認証を実行する必要があります。詳細については、「[デバイスでのサインイン](#user-pools-remembered-devices-signing-in-with-a-device)」を参照してください。

ユーザープールの **[サインイン]** メニューの **[デバイス追跡]** で、デバイスを記憶するようにユーザープールを設定します。Amazon Cognito コンソールを使用して記憶済みデバイス機能をセットアップするときは、**[常に]**、**[User Opt-In]** (ユーザーオプトイン)、および **[いいえ]** の 3 つのオプションがあります。

**記憶しない**  
ユーザープールでは、ログイン時にデバイスを記憶するように求めるメッセージは表示されません。

**常に記憶する**  
アプリがユーザーのデバイスを確認すると、ユーザープールは常にデバイスを記憶し、今後デバイスへのログインが成功しても MFA チャレンジを返しません。

**ユーザーオプトイン**  
アプリがユーザーのデバイスを確認しても、ユーザープールは MFA チャレンジを自動的に抑制しません。デバイスを記憶するかどうかをユーザーが選択するようにユーザーに求める必要があります。

**[常に記憶する]** または **[ユーザーオプトイン]** を選択すると、ユーザーが未確認のデバイスからサインインするたびに、Amazon Cognito はデバイス ID キーとシークレットを生成します。デバイスキーは、ユーザーがデバイス認証を実行したときにアプリがユーザープールに送信する最初の識別子です。

確認済みの各ユーザーデバイスでは、自動的に記憶されるかオプトインされたかに関係なく、ユーザーがサインインするたびにデバイス識別子キーとシークレットを使用してデバイスを認証できます。

[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) または [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストで、ユーザープールの記憶デバイス設定を構成することもできます。詳細については、[DeviceConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html#CognitoUserPools-UpdateUserPool-request-DeviceConfiguration) のプロパティを参照してください。

Amazon Cognito ユーザープール API には記憶されているデバイスに対してさらに 2 つのオペレーションがあります。

1. [ListDevices](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListDevices.html) と [AdminListDevices](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminListDevices.html) は、ユーザーのデバイスキーとそのメタデータのリストを返します。

1. [GetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetDevice.html) と [AdminGetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminGetDevice.html) は、単一のデバイスのデバイスキーとメタデータを返します。

1. [UpdateDeviceStatus](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateDeviceStatus.html) と [AdminUpdateDeviceStatus](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateDeviceStatus.html) は、ユーザーのデバイスを記憶済みまたは未記憶として設定します。

1. [ForgetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgetDevice.html) と [AdminForgetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminForgetDevice.html) は、ユーザーの確認済みデバイスをプロファイルから削除します。

名前が `Admin` で始まる API オペレーションはサーバー側アプリで使用するもので、IAM 認証情報を使用して認証する必要があります。詳細については、「[API、OIDC、マネージドログインページの認証についての理解](authentication-flows-public-server-side.md#user-pools-API-operations)」を参照してください。

## デバイスキーの取得
<a name="user-pools-remembered-devices-getting-a-device-key"></a>

ユーザーがユーザープール API を使用してサインインし、認証パラメータに `DEVICE_KEY` としてデバイスキーを含めない場合、Amazon Cognito はレスポンスに新しいデバイスキーを返します。クライアント側パブリックアプリでは、デバイスキーをアプリストレージに配置することで、今後のリクエストに含められるようになります。機密のサーバー側アプリで、ブラウザー Cookie または別のクライアント側トークンをユーザーのデバイスキーで設定します。

ユーザーが信頼できるデバイスを使用してサインインする前に、アプリはデバイスキーを確認して追加情報を提供する必要があります。デバイスキー、わかりやすい名前、パスワード検証ツール、およびソルトを使用してユーザーのデバイスを確認する [ConfirmDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmDevice.html) リクエストを Amazon Cognito に生成します。ユーザープールでオプトインデバイス認証を設定した場合、Amazon Cognito は `ConfirmDevice` リクエストに、ユーザーは現在のデバイスを記憶するかどうかを選択する必要があるプロンプトで応答する必要があります。[UpdateDeviceStatus](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateDeviceStatus.html) リクエストでユーザーが選択した内容を返信します。

ユーザーのデバイスを確認したが、記憶されるように設定しなかった場合、Amazon Cognito は関連付けを保存しますが、デバイスキーを入力するとデバイス以外のサインインで続行します。デバイスは、ユーザーのセキュリティとトラブルシューティングに役立つログを生成できます。確認済みで記憶されていないデバイスは、サインイン機能を利用しませんが、セキュリティモニタリングログ機能は利用します。アプリケーションクライアントの脅威保護を有効にし、デバイスのフィンガープリントをリクエストにエンコードすると、Amazon Cognito はユーザーイベントを確認済みのデバイスに関連付けます。

**新しいデバイスキーを取得するには**

1. [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API リクエストを使用してユーザーのサインインセッションを開始します。

1. ユーザーのサインインセッションが完了したことをマークする JSON Web トークン (JWT) を受け取るまで、すべての認証チャレンジに [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) で応答します。

1. アプリで、Amazon Cognito がその `RespondToAuthChallenge` または `InitiateAuth` レスポンスの `NewDeviceMetadata` に返す値 (`DeviceGroupKey` および `DeviceKey`) を記録します。

1. ユーザー用の新しい SRP シークレット、つまりソルトおよびパスワード検証ツールを生成します。この関数は SRP ライブラリを提供する SDK で使用できます。

1. ユーザーにデバイス名の入力を求めるか、ユーザーのデバイス特性からデバイス名を生成します。

1. [ConfirmDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmDevice.html) API リクエストでユーザーのアクセストークン、デバイスキー、デバイス名、SRP シークレットを指定します。ユーザープールがデバイスを **[常に記憶する]** に設定されていれば、ユーザー登録は完了です。

1. Amazon Cognito が `"UserConfirmationNecessary": true` で `ConfirmDevice` に応答した場合は、デバイスを記憶するかどうかを選択するようユーザーに促します。ユーザーがデバイスを記憶すると断言したら、ユーザーのアクセストークン、デバイスキー、および `"DeviceRememberedStatus": "remembered"` を使用して [UpdateDeviceStatus](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateDeviceStatus.html) API リクエストを生成します。

1. Amazon Cognito にデバイスを記憶するように指示した場合、次回のサインイン時に MFA チャレンジの代わりに `DEVICE_SRP_AUTH` チャレンジが表示されます。

## デバイスでのサインイン
<a name="user-pools-remembered-devices-signing-in-with-a-device"></a>

ユーザーのデバイスを記憶するように設定すると、Amazon Cognito ではユーザーが同じデバイスキーでサインインするときに MFA コードを送信する必要がなくなります。デバイス認証は、MFA 認証チャレンジをデバイス認証チャレンジに置き換えるだけです。グループとしてサインインすることはできません。ユーザーはまずパスワードまたはカスタムチャレンジを使用して認証を完了する必要があります。記憶しているデバイスでのユーザーの認証プロセスは次のとおりです。

[カスタム認証チャレンジ Lambda トリガー](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-challenge.html)を使用するフローでデバイス認証を実行するには、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API リクエストで `DEVICE_KEY` パラメータを渡します。ユーザーがすべてのチャレンジに成功し、`CUSTOM_CHALLENGE` チャレンジが `true` の `issueTokens` 値を返すと、Amazon Cognito は最後の 1 つの `DEVICE_SRP_AUTH` チャレンジを返します。

**デバイスでのサインインするには**

1. ユーザーのデバイスキーをクライアントストレージから取得します。

1. [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API リクエストを使用してユーザーのサインインセッションを開始します。`USER_SRP_AUTH`、`REFRESH_TOKEN_AUTH`、`USER_PASSWORD_AUTH`、または `CUSTOM_AUTH` の `AuthFlow` を選択します。`AuthParameters` で、ユーザーのデバイスキーを `DEVICE_KEY` パラメータに追加し、選択したログインフローに必要なその他のパラメータを含めます。

   1. 認証チャレンジへの `PASSWORD_VERIFIER` レスポンスのパラメータで `DEVICE_KEY` を渡すこともできます。

1. レスポンスに `DEVICE_SRP_AUTH` チャレンジを受け取るまで、チャレンジレスポンスを完了します。

1. [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) API リクエストで、`DEVICE_SRP_AUTH` の `ChallengeName` と `USERNAME`、`DEVICE_KEY`、および `SRP_A` のパラメータを送信します。

1. Amazon Cognito は `DEVICE_PASSWORD_VERIFIER` チャレンジで応答します。このチャレンジレスポンスには、`SECRET_BLOCK` および `SRP_B` の値が含まれます。

1. SRP ライブラリを使用して `PASSWORD_CLAIM_SIGNATURE`、`PASSWORD_CLAIM_SECRET_BLOCK`、`TIMESTAMP`、`USERNAME`、`DEVICE_KEY` パラメータを生成して送信します。これらは追加の `RespondToAuthChallenge` リクエストで送信してください。

1. ユーザーの JWT を受け取るまで、追加のチャレンジを完了してください。

次の擬似コードは、`DEVICE_PASSWORD_VERIFIER` チャレンジレスポンスの値を計算する方法を示しています。デバイスによる SRP 認証の場合は、ユーザーの*新しい* SRP シークレット (新しい高エントロピーパスワード `DeviceSecret`、ソルト、および関連するパスワード検証子) を生成します。これらの値は、ユーザーの SRP 認証に使用されるパスワード、ソルト、検証子とは異なります。これらはデバイス認証専用であり、デバイスにのみ保存されます。ユーザーのデバイスの SRP シークレットを生成する関数は、[SRP ライブラリ](https://github.com/secure-remote-password/implementations)にあり、さまざまな SDK で利用できます。

```
PASSWORD_CLAIM_SECRET_BLOCK = SECRET_BLOCK
TIMESTAMP = "Tue May 7 00:09:40 UTC 2025"
k = SHA256(N || g) as a non-negative integer in big-endian
u = SHA256(SRP_A || SRP_B) as a non-negative integer in big-endian
x = SHA256(salt || SHA256(DeviceGroupKey || DeviceKey || ":" || DeviceSecret)) as a non-negative integer in big-endian
S_USER = (SRP_B - k * g^x)^(a + u * x) % N
K_USER = HKDF_HMAC_SHA256(salt=u, ikm=S_USER, info="Caldera Derived Key", length=16 bytes)
PASSWORD_CLAIM_SIGNATURE = Base64(HMAC_SHA256(key=K_USER, message=(DeviceGroupKey || DeviceKey || PASSWORD_CLAIM_SECRET_BLOCK || TIMESTAMP)))
```

## デバイスの表示、更新、削除
<a name="user-pools-remembered-devices-viewing-updating-forgetting"></a>

Amazon Cognito API を使用して、アプリに次の機能を実装できます。

1. ユーザーの現在のデバイスに関する情報を表示します。

1. ユーザーのすべてのデバイスのリストを表示します。

1. デバイスの「記憶済み」状態を解除する

1. デバイスの記憶状態を更新します。

以下の説明の API リクエストを承認するアクセストークンには、`aws.cognito.signin.user.admin` スコープを含める必要があります。Amazon Cognito は、Amazon Cognito ユーザープール API を使用して生成するすべてのアクセストークンに、このスコープのクレームを追加します。サードパーティ IdP は、Amazon Cognito を認証するユーザーのデバイスと MFA を個別に管理する必要があります。マネージドログインでは、`aws.cognito.signin.user.admin` スコープをリクエストできますが、マネージドログインではデバイス情報が高度なセキュリティのユーザーログに自動的に追加され、デバイスが記憶されることはありません。

**デバイスに関する情報を表示する**  
ユーザーのデバイスに関する情報をクエリして、そのデバイスが現在も使用されているかどうかを判断できます。例えば、記憶されているデバイスが 90 日間サインインしていない場合に、そのデバイスを非アクティブ化することができます。
+ パブリッククライアントアプリにユーザーのデバイス情報を表示するには、ユーザーのアクセスキーとデバイスキーを [GetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetDevice.html) API リクエストで送信します。
+ 機密クライアントアプリにユーザーのデバイス情報を表示するには、 AWS 認証情報を使用して [AdminGetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminGetDevice.html) API リクエストに署名し、ユーザーのユーザー名、デバイスキー、ユーザープールを送信します。

**ユーザーのすべてのデバイスのリストを表示する**  
ユーザーのすべてのデバイスとそのプロパティのリストを表示できます。例えば、現在のデバイスが記憶されているデバイスと一致することを検証することが可能です。
+ パブリッククライアントアプリでは、[ListDevices](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListDevices.html) API リクエストでユーザーのアクセストークンを送信します。
+ 機密クライアントアプリで、 AWS 認証情報を使用して [AdminListDevices](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminListDevices.html) API リクエストに署名し、ユーザーのユーザー名とユーザープールを送信します。

**デバイスの「記憶済み」状態を解除する**  
ユーザーのデバイスキーは削除できます。これは、ユーザーがデバイスを使用しなくなったと判断した場合や、異常なアクティビティを検出してユーザーに MFA を再度完了するように促す場合に役立ちます。デバイスを後で再登録するには、新しいデバイスキーを生成して保存する必要があります。
+ パブリッククライアントアプリでは、[ForgetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgetDevice.html) API リクエストでユーザーのデバイスキーとアクセストークンを送信します。
+ 機密クライアントアプリでは、[AdminForgetDevice](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminForgetDevice.html) API リクエストでユーザーのデバイスキーとアクセストークンを送信します。

# ユーザープール分析に Amazon Pinpoint を使用する
<a name="cognito-user-pools-pinpoint-integration"></a>

**注記**  
**サポート終了通知:** 2026 年 10 月 30 日に、 AWS は Amazon Pinpoint のサポートを終了します。2026 年 10 月 30 日を過ぎると、Amazon Pinpoint コンソールまたは Amazon Pinpoint のリソース (エンドポイント、セグメント、キャンペーン、ジャーニー、分析) にアクセスできなくなります。詳細については、「[Amazon Pinpoint のサポート終了](https://docs.aws.amazon.com/console/pinpoint/migration-guide)」を参照してください。**注:** SMS、音声、モバイルプッシュ、OTP、電話番号の検証に関連する APIs は、この変更の影響を受けず、 AWS エンドユーザーメッセージングでサポートされています。

Amazon Cognito ユーザープールは、Amazon Cognito ユーザープールの分析を提供し、Amazon Pinpoint キャンペーンのユーザーデータを強化するために Amazon Pinpoint と統合されています。Amazon Pinpoint は、プッシュ通知を使用するモバイルアプリケーションでのユーザーエンゲージメントを促進するために、分析と的を絞ったキャンペーンを提供します。Amazon Cognito ユーザープールでの Amazon Pinpoint 分析のサポートを使用すると、Amazon Pinpoint コンソールでユーザープールへのサインアップ、サインイン、失敗した認証、デイリーアクティブユーザー数 (DAU)、および月間アクティブユーザー数 (MAU) を追跡できます。デバイスプラットフォーム、デバイスロケール、およびアプリケーションのバージョンなどのデータを異なる日付範囲や属性で表示できます。

また、アプリケーションにカスタム属性を設定することもできます。これらは、Amazon Pinpoint でユーザーを分割し、的を絞ったプッシュ通知をユーザーに送信するために使用できます。Amazon Cognito コンソールの **[アプリケーションクライアント]** メニューで、アプリケーションクライアントの **[分析]** 設定の **[Amazon Pinpoint とユーザー属性データを共有]** を選択すると、Amazon Pinpoint は、ユーザーの E メールアドレスと電話番号用に追加のエンドポイントを作成します。

Amazon Cognito コンソールを使用してユーザープールの Amazon Pinpoint 分析をアクティブ化すると、Amazon Cognito がユーザープールの Amazon Pinpoint に API リクエストを送信するときに引き継ぐ[サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)も作成されます。分析設定を追加する IAM プリンシパルには、[CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) 権限が必要です。サービスにリンクされたロールは、[AWSServiceRoleForAmazonCognitoIdp](https://console.aws.amazon.com/iamv2/home?region=us-east-1#/roles/details/AWSServiceRoleForAmazonCognitoIdp) です。詳細については、「[Amazon Cognito のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。

Amazon Cognito API で `AnalyticsConfiguration` をアプリケーションクライアントに適用する際、Amazon Pinpoint にカスタム IAM ロールを割り当てて、そのロールを引き継ぐ外部 ID を割り当てることができます。ロールは `cognito-idp` サービスプリンシパルを信頼している必要があり、ロール信頼ポリシーで外部 ID が必要な場合は、`AnalyticsConfiguration` と一致する必要があります。**Amazon Pinpoint プロジェクトには**、ロール `cognito-idp:Describe*` 権限と以下の権限を付与する必要があります。
+ `mobiletargeting:UpdateEndpoint`
+ `mobiletargeting:PutEvents`

## Amazon Cognito と Amazon Pinpoint の利用可能なリージョン
<a name="cognito-user-pools-find-region-mappings"></a>

次の表は、次のいずれかの条件を満たす Amazon Cognito と Amazon Pinpoint 間の AWS リージョン マッピングを示しています。
+ Amazon Pinpoint プロジェクトは、米国東部 (バージニア北部) (us-east-1) リージョンでのみ使用できます。
+ Amazon Pinpoint プロジェクトは、同じリージョン*または*米国東部 (バージニア北部) (us-east-1) リージョンで使用できます。

デフォルトでは、Amazon Cognito は同じ AWS リージョンの Amazon Pinpoint プロジェクトにのみ分析を送信できます。このルールの例外は、次の表のリージョンと Amazon Pinpoint が利用できないリージョンです。

Amazon Pinpoint は、次のリージョンでは利用できません。これらのリージョンの Amazon Cognito ユーザープールは分析をサポートしていません。
+ 欧州 (ミラノ)
+ 中東 (バーレーン)
+ アジアパシフィック (大阪)
+ イスラエル (テルアビブ)
+ アフリカ (ケープタウン)
+ アジアパシフィック (ジャカルタ)
+ アジアパシフィック (マレーシア)

この表は、Amazon Cognito ユーザープールを構築したリージョンと、Amazon Pinpoint の対応するリージョンとの関係を示しています。Amazon Pinpoint プロジェクトを Amazon Cognito と統合するには、使用可能なリージョンに設定する必要があります。


| Amazon Cognito ユーザープールのリージョン | Amazon Pinpoint プロジェクトのリージョン | 
| --- | --- | 
|  ap-northeast-1  |  us–east–1  | 
|  ap-northeast-2  |  us–east–1  | 
|  ap-south-1  |  us-east-1、ap-south-1  | 
|  ap-southeast-1  |  us–east–1  | 
|  ap-southeast-2  |  us-east-1、ap-southeast-2  | 
|  ca-central-1  |  us–east–1  | 
|  eu-central-1  |  us-east-1、eu-central-1  | 
|  eu-west-1  |  us-east-1、eu-west-1  | 
|  eu-west-2  |  us–east–1  | 
|  us-east-1  |  us–east–1  | 
|  us-east-2  |  us–east–1  | 
|  us-west-2  |  us-east-1、us-west-2  | 

**リージョンマッピングの例**
+ ap-northeast-1 でユーザープールを作成する場合、Amazon Pinpoint プロジェクトは us-east-1 で作成する必要があります。
+ ap-south-1 でユーザープールを作成する場合、Amazon Pinpoint プロジェクトは us-east-1 または ap-south-1 のいずれかで作成できます。

**注記**  
上記の表 AWS リージョン を除くすべての について、Amazon Cognito はユーザープールと同じリージョンの Amazon Pinpoint プロジェクトのみを使用できます。ユーザープールを構築したリージョンで Amazon Pinpoint が利用できず、表にも記載されていない場合、Amazon Cognito はそのリージョンで Amazon Pinpoint 分析をサポートしません。詳細な AWS リージョン 情報については、「[Amazon Pinpoint エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/pinpoint.html)」を参照してください。

### Amazon Pinpoint 分析設定の指定 (AWS マネジメントコンソール)
<a name="cognito-user-pools-pinpoint-integration-console"></a>

Amazon Cognito ユーザープールを設定して、分析データを Amazon Pinpoint に送信できます。Amazon Cognito は、ローカルユーザーの分析データのみを Amazon Pinpoint に送信します。ユーザープールを Amazon Pinpoint プロジェクトに関連付けるように設定したら、API リクエストに `AnalyticsMetadata` を含める必要があります。詳細については、「[アプリを Amazon Pinpoint と統合する](#cognito-user-pools-pinpoint-integration-client)」を参照してください。

**分析の設定を指定する**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。 AWS 認証情報を求められる場合があります。

1. **[User Pools]** (ユーザープール) を選択して、リストから既存のユーザープールを選択します。

1. **[アプリケーションクライアント]** メニューを選択し、更新するアプリケーションクライアントを選択します。

1. **[ピンポイント分析]** の下で **[分析]** タブの **[有効化]** を選択します。

1. **[Pinpoint Region]** (Pinpoint リージョン) を選択します。

1. **[Amazon Pinpoint project]** (Amazon Pinpoint プロジェクト) を選択するか、**[Create Amazon Pinpoint project]** (Amazon Pinpoint プロジェクトを作成する) を選択します。
**注記**  
Amazon Pinpoint プロジェクト ID は、Amazon Pinpoint プロジェクトに固有の 32 文字の文字列です。これは Amazon Pinpoint コンソールにリストされています。  
複数の Amazon Cognito アプリケーションを単一の Amazon Pinpoint プロジェクトにマッピングできますが、各 Amazon Cognito アプリは 1 つの Amazon Pinpoint プロジェクトにしかマップできません。  
Amazon Pinpoint では、各プロジェクトを単一のアプリにする必要があります。例えば、ゲームデベロッパーが 2 つのゲームを持っている場合、両方のゲームが同じ Amazon Cognito ユーザープールを使用しているとしても、各ゲームを個別の Amazon Pinpoint プロジェクトにする必要があります。Amazon Pinpoint プロジェクトの詳細については、「[Amazon Pinpoint でプロジェクトを作成する](https://docs.aws.amazon.com/push-notifications/latest/userguide/mobile-push.html#mobile-push-create-project)」を参照してください。

1. Amazon Cognito が E メールアドレスと電話番号を Amazon Pinpoint に送信し、ユーザー用の追加のエンドポイントを作成する場合は、**[User data sharing]** (ユーザーデータの共有) で **[Share user data with Amazon Pinpoint]** (Amazon Pinpoint でユーザーデータを共有する) を選択します。ユーザーが E メールアドレスと電話番号を確認した後、Amazon Cognito はそれらがユーザーアカウントで利用可能な場合にのみ Amazon Pinpoint と共有します。
**注記**  
エンドポイントは、Amazon Pinpoint でプッシュ通知を送信することができるユーザーデバイスを一意に識別します。エンドポイントの詳細については、*Amazon Pinpoint デベロッパーガイド*の「[エンドポイントの追加](https://docs.aws.amazon.com/pinpoint/latest/developerguide/endpoints.html)」を参照してください。

1. **[Save changes]** (変更の保存) をクリックします。

### Amazon Pinpoint 分析設定の指定 (AWS CLI および AWS API)
<a name="cognito-user-pools-pinpoint-integration-cli-api"></a>

以下のコマンドを使用して、ユーザープールの Amazon Pinpoint 分析設定を指定します。

**アプリケーション作成時にユーザープールの既存のクライアントアプリケーションの分析設定を指定する**
+ AWS CLI: `aws cognito-idp create-user-pool-client`
+ AWS API: [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html)

**ユーザープールの既存のクライアントアプリケーションの分析設定を更新する**
+ AWS CLI: `aws cognito-idp update-user-pool-client`
+ AWS API: [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html)

**注記**  
Amazon Cognito は、`ApplicationArn` の使用時にリージョン内の統合をサポートします。

## アプリを Amazon Pinpoint と統合する
<a name="cognito-user-pools-pinpoint-integration-client"></a>

*ユーザープール API* の Amazon Cognito *ローカルユーザー*の分析メタデータを Amazon Pinpoint に公開できます。

**ローカルユーザー**  
サードパーティー ID プロバイダー (IdP) を通じてサインインするのではなく、アカウントにサインアップしたユーザー、またはユーザープールで作成されたユーザー。

**ユーザープール API**  
カスタムユーザーインターフェイス (UI) でアプリケーションを使用して AWS SDK と統合できるオペレーション。マネージドログインでサインインしたフェデレーションユーザーまたはローカルユーザーの分析メタデータを渡すことはできません。ユーザープール API オペレーションのリストについては、「[Amazon Cognito API リファレンス](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html)」を参照してください。

キャンペーンに公開するようにユーザープールを設定すると、Amazon Cognito は次の API オペレーションのためのメタデータを Amazon Pinpoint に渡します。
+ `AdminInitiateAuth`
+ `AdminRespondToAuthChallenge`
+ `ConfirmForgotPassword`
+ `ConfirmSignUp`
+ `ForgotPassword`
+ `InitiateAuth`
+ `ResendConfirmationCode`
+ `RespondToAuthChallenge`
+ `SignUp`

ユーザーのセッションに関するメタデータを Amazon Pinpoint キャンペーンに渡すには、API リクエストの `AnalyticsMetadata` パラメータに `AnalyticsEndpointId` 値を含めます。JavaScript の例については、「*AWS ナレッジセンター*」の「[Amazon Pinpoint ダッシュボードに Amazon Cognito ユーザープールの分析が表示されないのはなぜですか?](https://aws.amazon.com/premiumsupport/knowledge-center/pinpoint-cognito-user-pool-analytics/)」を参照してください。

# Amazon Cognito ユーザープールの E メール設定
<a name="user-pool-email"></a>

アプリケーションでの特定のイベントにより、Amazon Cognito がユーザーに E メールを送信する場合があります。例えば、E メールの検証を必須とするようにユーザープールを設定している場合、ユーザーがアプリの新しいアカウントにサインアップする、またはパスワードをリセットする場合に Amazon Cognito が E メールを送信します。E メールを開始するアクションに応じて、検証コードまたは仮パスワードが含まれます。

E メール配信を処理するには、次のいずれかのオプションを使用できます。
+ Amazon Cognito サービスに組み込まれている[デフォルトの E メール設定](#user-pool-email-default)。
+ [Amazon Simple Email Service (Amazon SES) の設定](#user-pool-email-developer)。

ユーザープールを作成した後に、配信オプションを変更できます。

Amazon Cognito は、ユーザーが入力できるコードか選択可能な URL リンクのいずれかを含む E メールメッセージをユーザーに送信します。次の表は、E メールメッセージを生成できるイベントを示しています。

**メッセージオプション**


| アクティビティ | API オペレーション: | 配信オプション | 形式オプション | カスタマイズ可能 | [メッセージテンプレート](cognito-user-pool-settings-message-customizations.md) | 
| --- |--- |--- |--- |--- |--- |
| Forgot password | [ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html), [AdminResetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html) | Email, SMS | code | Yes | 検証メッセージ | 
| Invitation | [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html) | Email, SMS | code | Yes | 招待メッセージ | 
| Self-registration | [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html), [ResendConfirmationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html) | Email, SMS | code, link | Yes | 検証メッセージ | 
| Email address or phone number verification | [UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html), [AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html), [GetUserAttributeVerificationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserAttributeVerificationCode.html) | Email, SMS | code | Yes | 検証メッセージ | 
| Multi-factor authentication (MFA) | [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html), [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) | Email¹, SMS, authenticator app | code | Yes² | MFA メッセージ | 
| One-time password authentication (OTP) | [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html), [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) | Email¹, SMS | code | Yes | MFA メッセージ³ | 

¹ エッセンシャル以上の[機能プラン](cognito-sign-in-feature-plans.md)と [Amazon SES E メール設定](#user-pool-email-developer)が必要です。

² SMS メッセージおよび E メールメッセージの場合。

³ ユーザープールで MFA が必須またはオプションである場合にのみ、MFA メッセージテンプレートをカスタマイズできます。MFA が非アクティブの場合、Amazon Cognito はデフォルトのテンプレートを使用してワンタイムパスワードを送信します。

Amazon SES はメールメッセージに対して料金を請求します。詳細については、「[Amazon SES の料金](https://aws.amazon.com/ses/pricing/) 」を参照してください。

E メール MFA の詳細については、「[SMS メッセージ MFA と E メールメッセージ MFA](user-pool-settings-mfa-sms-email-message.md)」を参照してください。

Amazon Cognito は、1 つの送信先に対する短期間での E メールや SMS メッセージの追加配信を防止する場合があります。ユーザープールが影響を受けていると思われる場合は、[メッセージ配信エラーのログ](exporting-quotas-and-usage.md#exporting-quotas-and-usage-messages)を設定および確認してから、アカウントチームにお問い合わせください。

## デフォルトの E メール設定
<a name="user-pool-email-default"></a>

Amazon Cognito は、デフォルトの E メール設定を使用して E メール配信を処理できます。デフォルトのオプションを使用すると、Amazon Cognito は、ユーザープールに毎日送信するメールの数を制限します。サービスの制限に関する詳細については、「[Amazon Cognito のクォータ](quotas.md)」を参照してください。一般的な実稼働環境では、デフォルトの E メール制限は必要な配信ボリュームを下回っています。大規模なデリバリーボリュームを有効にするには、Amazon SES E メール設定を使用する必要があります。

デフォルトの設定を使用する場合は、 AWS によって管理される Amazon SES リソースを使用して E メールメッセージを送信します。Amazon SES は、[ハードバウンス](https://docs.aws.amazon.com/ses/latest/dg/send-email-concepts-deliverability.html#send-email-concepts-deliverability-bounce)を返す E メールアドレスを[アカウントレベルのサプレッションリスト](https://docs.aws.amazon.com/ses/latest/dg/sending-email-suppression-list.html)または[グローバルサプレッションリスト](https://docs.aws.amazon.com/ses/latest/dg/send-email-concepts-deliverability.html#send-email-concepts-deliverability-suppression-list)に追加します。配信不能な E メールアドレスが後で配信可能になった場合、ユーザープールがデフォルト設定を使用するように設定されている間は、サプレッションリストからの削除を制御できません。E メールアドレスは AWS、マネージドサプレッションリストに無期限に残すことができます。配信不能な E メールアドレスを管理するには、次のセクションで説明するように、アカウントレベルのサプレッションリストで Amazon SES E メール設定を使用します。

デフォルトの E メール設定を使用すると、オプションでは、次のいずれかの E メールアドレスを FROM アドレスとして使用できます。
+ デフォルトの E メールアドレス (*no-reply@verificationemail.com*)。
+ カスタム E メールアドレス。独自の E メールアドレスを使用する前に、それを Amazon SES で検証し、このアドレスを使用するための許可を Amazon Cognito に付与する必要があります。

## Amazon SES の E メール設定
<a name="user-pool-email-developer"></a>

アプリケーションは、デフォルトのオプションで利用できるよりも大きいボリュームを必要とする可能性があります。可能なデリバリーボリュームを増やすには、Amazon SES リソースとユーザープールを使用してユーザーに E メールを送信します。独自の Amazon SES 設定で E メールメッセージを送信するときに、[E メール送信アクティビティをモニタリングする](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/monitor-sending-activity.html)こともできます。

Amazon SES の設定を使用する前に、1 つ、または複数の E メールアドレスまたはドメインを Amazon SES で検証する必要があります。検証済み E メールアドレスまたは検証済みドメインのアドレスを、ユーザープールに割り当てる FROM E メールアドレスとして使用します。Amazon Cognito が E メールをユーザーに送信するときは、Amazon SES を呼び出し、その E メールアドレスを使用するようになります。

Amazon SES の設定を使用する場合は、次の条件が適用されます。
+ ユーザープールの E メール配信制限が、 AWS アカウントの Amazon SES 検証済み E メールアドレスに適用される制限と同じになります。
+ Amazon SES のアカウントレベルのサプレッションリストで、[グローバルサプレッションリスト](https://docs.aws.amazon.com/ses/latest/dg/send-email-concepts-deliverability.html#send-email-concepts-deliverability-suppression-list)を上書きして、配信不能な E メールアドレスへのメッセージを管理することができます。アカウントレベルのサプレッションリストを使用すると、E メールメッセージのバウンスが送信者としてのアカウントの評価に影響します。詳細については、Amazon Simple Email Service デベロッパーガイドの「[Amazon SES アカウントレベルのサプレッションリストの使用](https://docs.aws.amazon.com/ses/latest/dg/sending-email-suppression-list.html)」を参照してください。

### Amazon SES の E メール設定リージョン
<a name="user-pool-email-developer-region-mapping"></a>

ユーザープール AWS リージョン を作成する には、Amazon SES での E メールメッセージの設定に関する 3 つの要件のいずれかがあります。ユーザープールと同じリージョン、同じリージョンを含む複数のリージョン、または 1 つ以上のリモートリージョンの Amazon SES から E メールメッセージを送信できます。最高のパフォーマンスを得るには、ユーザープールと同じリージョンというオプションがある場合は、これで Amazon SES 検証済み ID の E メールメッセージを送信します。Amazon SES 検証済み ID のリージョン要件のカテゴリ

**リージョン内のみ**  
ユーザープールは、ユーザープール AWS リージョン と同じ で検証済み ID を持つ E メールメッセージを送信できます。カスタム `FROM` E メールアドレスのないデフォルトの E メール設定では、Amazon Cognito は同じリージョンで `no-reply@verificationemail.com` 検証済み ID を使用します。

**下位互換性あり**  
ユーザープールは、同じリージョン AWS リージョン または次のいずれかの代替リージョンで、検証済み ID を含む E メールメッセージを送信できます。  
+ 米国東部 (バージニア北部)
+ 米国西部 (オレゴン)
+ 欧州 (アイルランド)
この機能は、サービスの起動時に Amazon Cognito の要件を満たすように作成した可能性のあるユーザープールリソースの継続性をサポートします。その期間のユーザープールは、限られた数の ID が検証済みの E メールメッセージのみを送信できます AWS リージョン。カスタム `FROM` E メールアドレスのないデフォルトの E メール設定では、Amazon Cognito は同じリージョンで `no-reply@verificationemail.com` 検証済み ID を使用します。

**代替リージョン**  
ユーザープールは、ユーザープールリージョン外の代替 で、検証 AWS リージョン 済み ID を含む E メールメッセージを送信できます。この設定は、Amazon Cognito が利用可能なリージョンで Amazon SES が利用できない場合に発生します。  
代替リージョンでの検証済み ID の Amazon SES 送信認可ポリシーは、発信元のリージョンの Amazon Cognito サービスプリンシパルを信頼する必要があります。詳細については、「[デフォルトの E メール設定を使用するアクセス許可を付与するには](#user-pool-email-permissions-default)」を参照してください。  
これらのリージョンの一部では、Amazon Cognito は、`COGNITO_DEFAULT` のデフォルト E メール設定のために E メールメッセージを 2 つの代替リージョンに分割します。このような場合、カスタム `FROM` E メールアドレスを使用するには、各代替リージョンでの検証済み ID の Amazon SES 送信認可ポリシーが、発信元のリージョンの Amazon Cognito サービスプリンシパルを信頼する必要があります。詳細については、「[デフォルトの E メール設定を使用するアクセス許可を付与するには](#user-pool-email-permissions-default)」を参照してください。これらのリージョンでの `DEVELOPER` の Amazon SES E メール設定では、*最初に*リストされたリージョンで検証済み ID を使用し、ユーザープールリージョンで Amazon Cognito サービスプリンシパルを信頼するように設定する必要があります。例えば、中東 (アラブ首長国連邦) のユーザープールで、`cognito-idp.me-central-1.amazonaws.com` を信頼するように欧州 (フランクフルト) で検証済み ID を設定します。カスタム `FROM` E メールアドレスのないデフォルトの E メール設定では、Amazon Cognito は各リージョンで `no-reply@verificationemail.com` 検証済み ID を使用します。

**注記**  
以下の条件の組み合わせでは、リージョン要素のワイルドカードを使用して [EmailConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-EmailConfiguration) の `SourceArn` パラメータを `arn:${Partition}:ses:*:${Account}:identity/${IdentityName}` 形式で指定する必要があります。これにより、ユーザープールは、 AWS アカウント 両方の で同じ検証済み ID を持つ E メールメッセージを送信できます AWS リージョン。  
EmailSendingAccount は `COGNITO_DEFAULT` です。
カスタム `FROM` アドレスを使用します。
ユーザープールは**代替リージョン**で E メールを送信します。
ユーザープールには、次の「**Amazon SES でサポートされているリージョン**」の表に指定されている *2 番目*[1](#cognito-email-alternate-regions-note) の**代替リージョン**があります。

 AWS SDK、Amazon Cognito API または CLI を使用してプログラムでユーザープールを作成する場合、、 または AWS CloudFormationユーザープールは AWS CDK、EmailConfiguration の `SourceArn`パラメータがユーザープールに指定する Amazon SES ID を含む E メールメッセージを送信します。 [EmailConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-EmailConfiguration) Amazon SES ID は、サポートされている を占有する必要があります AWS リージョン。`EmailSendingAccount` が `COGNITO_DEFAULT` で `SourceArn` パラメータを指定しない場合、Amazon Cognito はユーザープールを作成したリージョン内のリソースを使用して `no-reply@verificationemail.com` から E メールメッセージを送信します。

次の表は、Amazon Cognito で Amazon SES ID を AWS リージョン 使用できる を示しています。 Amazon Cognito


| ユーザープールリージョン | リージョンオプション | Amazon SES がサポートされるリージョン | 
| --- | --- | --- | 
|  米国東部 (バージニア北部)  |  下位互換性あり  |  米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  米国東部 (オハイオ)  |  下位互換性あり  |  米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  米国西部 (北カリフォルニア)  |  リージョン内のみ  |  米国西部 (北カリフォルニア)  | 
|  米国西部 (オレゴン)  |  下位互換性あり  |  米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  カナダ (中部)  |  下位互換性あり  |  カナダ (中部)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  カナダ西部 (カルガリー)  |  代替リージョン  |  カナダ (中部）、米国西部 (北カリフォルニア)[1](#cognito-email-alternate-regions-note)  | 
|  メキシコ (中部)  |  代替リージョン  |  米国東部 (バージニア北部)、米国西部 (オレゴン)[1](#cognito-email-alternate-regions-note)  | 
|  アジアパシフィック (東京)  |  下位互換性あり  |  アジアパシフィック (東京)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  アジアパシフィック (香港)  |  代替リージョン  |  アジアパシフィック (シンガポール)、アジアパシフィック (東京)[1](#cognito-email-alternate-regions-note)  | 
|  アジアパシフィック (ソウル)  |  下位互換性あり  |  アジアパシフィック (ソウル)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
| アジアパシフィック (マレーシア) | 代替リージョン | アジアパシフィック (シドニー)、アジアパシフィック (シンガポール)[1](#cognito-email-alternate-regions-note) | 
| アジアパシフィック (タイ) | 代替リージョン | アジアパシフィック (シンガポール)、アジアパシフィック (ムンバイ)[1](#cognito-email-alternate-regions-note) | 
|  アジアパシフィック (ムンバイ)  |  下位互換性あり  |  アジアパシフィック (ムンバイ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  アジアパシフィック (ハイデラバード)  |  代替リージョン  |  アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)[1](#cognito-email-alternate-regions-note)  | 
|  アジアパシフィック (シンガポール)  |  下位互換性あり  |  アジアパシフィック (シンガポール)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  アジアパシフィック (シドニー)  |  下位互換性あり  |  アジアパシフィック (シドニー)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  アジアパシフィック (大阪)  |  リージョン内のみ  |  アジアパシフィック (大阪)  | 
|  アジアパシフィック (ジャカルタ)  |  リージョン内のみ  |  アジアパシフィック (ジャカルタ)  | 
|  アジアパシフィック (メルボルン)  |  代替リージョン  |  アジアパシフィック (シドニー)、アジアパシフィック (シンガポール)[1](#cognito-email-alternate-regions-note)  | 
|  欧州 (アイルランド)  |  下位互換性あり  |  米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  欧州 (ロンドン)  |  下位互換性あり  |  欧州 (ロンドン)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  欧州 (パリ)  |  リージョン内のみ  |  欧州 (パリ)  | 
|  欧州 (フランクフルト)  |  下位互換性あり  |  欧州 (フランクフルト)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)  | 
|  欧州 (チューリッヒ)  |  代替リージョン  |  欧州 (フランクフルト)、欧州 (ロンドン)[1](#cognito-email-alternate-regions-note)  | 
|  欧州 (ストックホルム)  |  リージョン内のみ  |  欧州 (ストックホルム)  | 
| 欧州 (ミラノ) |  リージョン内のみ  | 欧州 (ミラノ) | 
| 欧州 (スペイン) |  代替リージョン  | 欧州 (パリ)、欧州 (ストックホルム)[1](#cognito-email-alternate-regions-note) | 
|  中東 (バーレーン)  |  リージョン内のみ  |  中東 (バーレーン)  | 
|  中東 (アラブ首長国連邦)  |  代替リージョン  |  欧州 (フランクフルト)、欧州 (ロンドン)[1](#cognito-email-alternate-regions-note)  | 
|  南米 (サンパウロ)  |  リージョン内のみ  |  南米 (サンパウロ)  | 
|  イスラエル (テルアビブ)  |  リージョン内のみ  |  イスラエル (テルアビブ)  | 
|  アフリカ (ケープタウン)  |  リージョン内のみ  |  アフリカ (ケープタウン)  | 

 1 デフォルトの E メール設定を持つユーザープールで使用されます。Amazon Cognito は、各リージョンで同じ E メールアドレスを持つ検証済み ID に E メールメッセージを配信します。カスタム `FROM` アドレスを使用するには、`arn:${Partition}:ses:*:${Account}:identity/${IdentityName}` 形式の `SourceArn` パラメータを使用して `EmailConfiguration` を設定します。

## ユーザープールの E メールの設定
<a name="user-pool-email-configure"></a>

ユーザープールの E メール設定を指定するには、以下のステップを完了します。使用する設定に応じて、Amazon SES、 AWS Identity and Access Management (IAM)、および Amazon Cognito での IAM アクセス許可が必要になる場合があります。

**注記**  
これらのステップで作成したリソースを AWS アカウント間で共有することはできません。例えば、あるアカウントのユーザープールを設定してから、別のアカウントの Amazon SES E メールアドレスで使用することはできません。複数のアカウントで Amazon Cognito を使用する場合は、それぞれのアカウントでこれらのステップを繰り返すようにしてください。

### ステップ 1: Amazon SES での E メールアドレスを検証する
<a name="user-pool-email-configure-verify-ses"></a>

次のいずれかを行う場合は、ユーザープールを設定する前に、Amazon SES で 1 つ、または複数の E メールアドレスを検証する必要があります。
+ FROM アドレスとして独自の E メールアドレスを使用する
+ Amazon SES の設定を使用して E メール配信を処理する

E メールアドレスを検証することにより、そのアドレスを所有していることを確認する (不正使用の防止に役立ちます)

Amazon SES での E メールアドレスの検証については、*Amazon Simple Email Service デベロッパーガイド*の「[E メールアドレスの検証](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/verify-email-addresses-procedure.html)」を参照してください。Amazon SES でのドメインの検証の詳細については、「[ドメインの検証](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/verify-domains.html)」を参照してください。

### ステップ 2: Amazon SES サンドボックスからアカウントを移動する
<a name="user-pool-email-configure-sandbox"></a>

デフォルトの Amazon Cognito E メール設定を使用している場合は、このステップを省略します。

で最初に Amazon SES を使用すると AWS リージョン、そのリージョン AWS アカウント の Amazon SES サンドボックスに が配置されます。Amazon SES は、サンドボックスを使用して不正使用や悪用を防ぎます。Amazon SES 設定を使用して E メール配信を処理している場合は、Amazon Cognito がユーザーに E メールを送信する前に、サンドボックスから AWS アカウント を移動させる必要があります。

サンドボックスでは、Amazon SES が、送信できる E メールの数と、それらの送信先に制限を課します。E メールは、Amazon SES で検証したアドレスとドメインのみに送信できます。または、Amazon SES メールボックスシミュレーターのアドレスにも E メールを送信できます。がサンドボックスに AWS アカウント 残っている間は、本番環境のアプリケーションに Amazon SES 設定を使用しないでください。この状況では、Amazon Cognito がユーザーの E メールアドレスにメッセージを送信することができません。

サンドボックス AWS アカウント から を削除するには、[Amazon SESサンドボックスからの移動](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html)*」を参照してください。*

### ステップ 3: Amazon Cognito に E メール許可を付与する
<a name="user-pool-email-permissions"></a>

Amazon Cognito がユーザーに E メールを送信する前に、特定の許可を Amazon Cognito に付与する必要がある場合があります。付与するアクセス許可、およびそれらを付与するために使用するプロセスは、デフォルトの E メール設定と Amazon SES の設定のどちらを使用しているかに応じて異なります。

#### デフォルトの E メール設定を使用するアクセス許可を付与するには
<a name="user-pool-email-permissions-default"></a>

このステップは、**Cognito で E メールを送信**するようにユーザープールを設定するか、 `EmailSendingAccount` を `COGNITO_DEFAULT` に設定する場合にのみ実施します。

デフォルトの E メール設定では、ユーザープールは次のいずれかのアドレスを使用して E メールを送信できます。
+ デフォルトのアドレス `no-reply@verificationemail.com`。
+ Amazon SES での検証された E メールアドレスまたはドメインからのカスタム FROM アドレス。

カスタムアドレスを使用している場合、Amazon Cognito には、そのアドレスからユーザーに E メールを送信するための追加のアクセス許可が必要です。これらのアクセス許可は、Amazon SES でアドレス用またはドメイン用の[送信認可ポリシー](https://docs.aws.amazon.com/ses/latest/dg/sending-authorization.html)によって付与されます。Amazon Cognito コンソールを使用してユーザープールにカスタムアドレスを追加する場合、ポリシーは Amazon SES 検証済み E メールアドレスに自動的にアタッチされます。ただし、 AWS CLI や Amazon Cognito API など、コンソールの外部でユーザープールを設定する場合は、[Amazon SES コンソール](https://console.aws.amazon.com/ses/)または [PutIdentityPolicy](https://docs.aws.amazon.com/ses/latest/APIReference/API_PutIdentityPolicy.html) API を使用してポリシーをアタッチする必要があります。

**注記**  
FROM アドレスは、 AWS CLI または Amazon Cognito API を使用して検証済みドメインでのみ設定できます。

送信承認ポリシーは、Amazon Cognito を使用して Amazon SES を呼び出すアカウントリソースに基づいてアクセスを許可、または拒否します。リソースベースのポリシーに関する詳細については、 [IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)を参照してください。リソースベースのポリシーの例についても、[Amazon SES デベロッパーガイド](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-authorization-policy-examples.html)で確認いただけます。

**Example 送信承認ポリシー**  
次の送信承認ポリシーの例では、Amazon SES 検証済み ID を使用するための限定された権限が Amazon Cognito に付与されています。Amazon Cognito は、条件 `aws:SourceArn` のユーザープールと条件 `aws:SourceAccount` のアカウントの両方に代わって送信する場合にのみ、E メールメッセージを送信できます。  
ユーザープールリージョンまたは代替リージョンの送信認可ポリシーでは、E メールメッセージを送信することを Amazon Cognito サービスプリンシパルに許可する必要があります。詳細については、[リージョン表](#ses-regions-table)を参照してください。**ユーザープールリージョン**が **Amazon SES リージョン**で少なくとも 1 つの値と一致する場合は、次の例のグローバルサービスプリンシパルを使用して送信認可ポリシーを設定します。    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "stmnt1234567891234",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "email.cognito-idp.amazonaws.com"
                ]
            },
            "Action": [
                "SES:SendEmail",
                "SES:SendRawEmail"
            ],
            "Resource": "arn:aws:ses:us-east-1:111122223333:identity/support@example.com",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:cognito-idp:us-east-1:111122223333:userpool/us-east-1_EXAMPLE"
                }
            }
        }
    ]
}
```
Amazon SES は、Amazon Cognito AWS リージョン が利用可能なすべてのオプトインで利用できるわけではありません。中東 (アラブ首長国連邦) が例として挙げられますが、欧州 (フランクフルト) (`eu-central-1`) で検証済み ID を持つ E メールのみを送信できます。デフォルトの E メール設定を持つユーザープールでは、Amazon Cognito は 2 つのリージョンのそれぞれで検証済み ID を含む E メールメッセージも送信します。中東 (アラブ首長国連邦) の場合、追加のリージョンは欧州 (ロンドン) です。両方のリージョンの送信認可ポリシーを更新する必要があります。  
各代替リージョンの送信認可ポリシーでは、E メールメッセージを送信することを、ユーザープールオプトインリージョンの Amazon Cognito サービスプリンシパルに許可する必要があります。詳細については、[リージョン表](#ses-regions-table)を参照してください。リージョンが**代替リージョン**としてマークされている場合は、次の例のように、リージョンサービスプリンシパルを使用して送信認可ポリシーを設定します。必要に応じて、サンプルリージョン識別子 *me-central-1* を必要なリージョン ID に置き換えます。    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "cognito-idp.me-central-1.amazonaws.com"
                ]
            },
            "Action": [
                "SES:SendEmail",
                "SES:SendRawEmail"
            ],
            "Resource": "arn:aws:ses:us-east-1:111122223333:identity/support@example.com",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:cognito-idp:us-east-1:111122223333:userpool/us-east-1_EXAMPLE"
                }
            }
        }
    ]
}
```
ポリシー構文の詳細については、「*Amazon Simple Email Service デベロッパーガイド*」の「[Amazon SES 送信承認ポリシー](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-authorization-policies.html)」を参照してください。  
その他の例については、「*Amazon Simple Email Service デベロッパーガイド*」の「[Amazon SES 送信承認ポリシーの例](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-authorization-policy-examples.html)」を参照してください。

#### Amazon SES の設定を使用する許可を付与する
<a name="user-pool-email-permissions-developer"></a>

Amazon SES の設定を使用するようにユーザープールを設定する場合、Amazon Cognito には、ユーザーに E メールを送信するときに代理で Amazon SES を呼び出すための追加の許可が必要です。この承認は、IAM サービスで付与されます。

このオプションでユーザープールを設定すると、Amazon Cognito が AWS アカウントに*サービスリンクロール* (IAM ロールの一種) を作成します。このロールには、Amazon Cognito が Amazon SES にアクセスし、お客様のアドレスを使用して E メールを送信できるようにする許可が含まれています。

Amazon Cognito は、設定を設定するユーザーセッションの AWS 認証情報を使用して、サービスにリンクされたロールを作成します。このセッションの IAM 権限には、`iam:CreateServiceLinkedRole` アクションが含まれている必要があります。IAM のアクセス許可の詳細については、IAM *ユーザーガイド*の[AWS 「リソースのアクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)」を参照してください。

Amazon Cognito が作成するサービスリンクロールの詳細については、「[Amazon Cognito のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。

### ステップ 4: ユーザープールを設定する
<a name="user-pool-email-configure-user-pool"></a>

以下のいずれかを使用してユーザープールを設定する場合は、次のステップを完了します。
+ E メール送信者として表示されるカスタムの FROM アドレス
+ ユーザーが FROM アドレスに送信するメッセージを受信するカスタムの REPLY-TO アドレス
+ Amazon SES の設定

**注記**  
検証済み ID が E メールアドレスの場合、Amazon Cognito はデフォルトで、その E メールアドレスを FROM と REPLY-TO の E メールアドレスとして設定します。ただし、検証済み ID がドメインの場合は、FROM の E メールアドレスに値を指定する必要があります。

デフォルトの Amazon Cognito E メール設定とアドレスを使用する場合は、この手順を省略します。

**カスタム E メールアドレスを使用するようにユーザープールを設定する方法**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[認証方法]** メニューを選択し、**[E メール設定]** を見つけ、**[編集]** を選択します。

1. **[Edit email configuration]** (E メールの設定) の編集ページで、**[Send email from Amazon SES]** (Amazon SES からメールを送信する) または**[Send email with Amazon Cognito]** (Amazon Cognito で E メールを送信する) を選択します。**[Send email from Amazon SES]** (Amazon SES からメールを送信する) を選択した場合のみ、**[SES Region]** (SES リージョン)、**[Configuration Set]** (設定セット)、および **[FROM sender name]** (FROM 送信者名) をカスタマイズできます。

1. カスタムの FROM アドレスを使用するには、次の手順を実行します。

   1. **[SES Region]** (SES リージョン) で、検証済み E メールアドレスが含まれているリージョンを選択します。

   1. **[FROM email address]** (FROM E メールアドレス) で、E メールアドレスを選択します。Amazon SES で検証済みの E メールアドレスを使用します。

   1. (オプション) **[Configuration set]** (設定セット) で Amazon SES で使用する設定セットを選択します。この変更を行って保存すると、サービスにリンクされたロールが作成されます。

   1. (オプション) **[FROM sender address]** (FROM 送信者アドレス) で E メールアドレスを入力します。E メールアドレスだけ、または E メールアドレスと分かりやすい名前を `Jane Doe <janedoe@example.com>` 形式で指定できます。

   1. (オプション) **[REPLY-TO email address]** (REPLY-TO E メールアドレス) で、ユーザーが FROM アドレスに送信するメッセージを受信する E メールアドレスを入力します。

1. **[Save changes]** (変更の保存) をクリックします。

**関連トピック**
+ [E メール検証メッセージのカスタマイズ](cognito-user-pool-settings-message-customizations.md#cognito-user-pool-settings-email-verification-message-customization)
+ [ユーザー招待メッセージのカスタマイズ](cognito-user-pool-settings-message-customizations.md#cognito-user-pool-settings-user-invitation-message-customization)

# Amazon Cognito ユーザープール用の SMS メッセージ設定
<a name="user-pool-sms-settings"></a>

ユーザープールの Amazon Cognito イベントには、Amazon Cognito がユーザーに SMS テキストメッセージを送信する結果となるものがあります。例えば、電話番号の検証を必須とするようにユーザープールを設定している場合、ユーザーがアプリケーションの新しいアカウントにサインアップする、またはパスワードをリセットする場合に Amazon Cognito が SMS テキストメッセージを送信します。SMS テキストメッセージを開始するアクションに応じて、メッセージには検証コード、一時的なパスワード、またはウェルカムメッセージが含まれます。

Amazon Cognito は、SMS テキストメッセージの配信に Amazon Simple Notification Service (Amazon SNS) を使用します。Amazon SNS は、SMS メッセージを渡します AWS End User Messaging SMS。Amazon Cognito 経由で初めてテキストメッセージを送信する場合、 は[サンドボックス環境](https://docs.aws.amazon.com/sms-voice/latest/userguide/sandbox.html) AWS End User Messaging SMS に配置します。サンドボックス環境では、SMS テキストメッセージのアプリケーションをテストできます。サンドボックスでは、メッセージの送信をシミュレートすることだけができます。

**注記**  
2024 年 11 月、 は Amazon SNS SMS メッセージングを AWS に置き換えました AWS End User Messaging SMS。現在、Amazon Cognito コンソールは Amazon SNS リソースを参照しています。ユーザープールは Amazon SNS Publish オペレーションを使用して SMS メッセージを開始します。これはパススルーです AWS End User Messaging SMS。 [https://docs.aws.amazon.com/sns/latest/api/API_Publish.html](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)したがって、`sms-voice:SendTextMessage` ではなく、`sns:Publish` のアクセス許可を設定する必要があります。

AWS End User Messaging SMS は SMS テキストメッセージの料金を請求します。詳細については、[AWS End User Messaging SMS 料金表](https://aws.amazon.com/end-user-messaging/pricing/)を参照してください。

Amazon Cognito は、ユーザーが入力できるコードを含む SMS メッセージをユーザーに送信します。次の表は、SMS メッセージを生成できるイベントを示しています。

**メッセージオプション**


| アクティビティ | API オペレーション: | 配信オプション | 形式オプション | カスタマイズ可能 | [メッセージテンプレート](cognito-user-pool-settings-message-customizations.md) | 
| --- |--- |--- |--- |--- |--- |
| Forgot password | [ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html), [AdminResetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html) | Email, SMS | code | Yes | 検証メッセージ | 
| Invitation | [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html) | Email, SMS | code | Yes | 招待メッセージ | 
| Self-registration | [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html), [ResendConfirmationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html) | Email, SMS | code, link | Yes | 検証メッセージ | 
| Email address or phone number verification | [UpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserAttributes.html), [AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html), [GetUserAttributeVerificationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUserAttributeVerificationCode.html) | Email, SMS | code | Yes | 検証メッセージ | 
| Multi-factor authentication (MFA) | [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html), [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) | Email¹, SMS, authenticator app | code | Yes² | MFA メッセージ | 
| One-time password authentication (OTP) | [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html), [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) | Email¹, SMS | code | Yes | MFA メッセージ³ | 

¹ エッセンシャル以上の[機能プラン](cognito-sign-in-feature-plans.md)と [Amazon SES E メール設定](user-pool-email.md#user-pool-email-developer)が必要です。

² SMS メッセージおよび E メールメッセージの場合。

³ ユーザープールで MFA が必須またはオプションである場合にのみ、MFA メッセージテンプレートをカスタマイズできます。MFA が非アクティブの場合、Amazon Cognito はデフォルトのテンプレートを使用してワンタイムパスワードを送信します。

AWS End User Messaging SMS は SMS メッセージに対して課金します。詳細については、[AWS End User Messaging SMS 料金表](https://aws.amazon.com/end-user-messaging/pricing/)を参照してください。

MFA の詳細については、「[SMS メッセージ MFA と E メールメッセージ MFA](user-pool-settings-mfa-sms-email-message.md)」を参照してください。

Amazon Cognito は、1 つの送信先に対する短期間での E メールや SMS メッセージの追加配信を防止する場合があります。ユーザープールが影響を受けていると思われる場合は、[メッセージ配信エラーのログ](exporting-quotas-and-usage.md#exporting-quotas-and-usage-messages)を設定および確認してから、アカウントチームにお問い合わせください。

## ベストプラクティス
<a name="user-pool-sms-settings-best-practices"></a>

世界中で一方的な SMS トラフィックの量が多いため、一部の政府は SMS メッセージの送信者と受信者の間に障壁を課しています。SMS メッセージを MFA やユーザーアップデートに使用する場合は、メッセージが確実に送られるように追加の手順を踏む必要があります。また、ユーザーが住んでいる可能性のある国の SMS メッセージ関連の規制を監視し、SMS メッセージの設定を最新の状態に保つ必要があります。詳細については、「*AWS End User Messaging SMS ユーザーガイド*」の「[SMS および MMS の国別の機能と制限](https://docs.aws.amazon.com/sms-voice/latest/userguide/phone-numbers-sms-support-by-country.html)」を参照してください。

SMS メッセージを使用してユーザーを認証および検証することは、セキュリティ上のベストプラクティスではありません。電話番号は所有者が変わる場合があり、ユーザーの MFA の*所有している*要素を確実に表さないかもしれません。代わりに、アプリまたはサードパーティーの IdP で TOTP MFA を実装してください。また、[カスタム認証チャレンジの Lambda トリガー](user-pool-lambda-challenge.md) を使って、追加のカスタム認証要素を作成することもできます。

SMS メッセージ配信アーキテクチャの保護については、以下のリンクを参照してください。
+ [Amazon Cognito ユーザープールを使用したユーザーサインアップ詐欺や SMS ポンピングのリスクを軽減する](https://aws.amazon.com/blogs/security/reduce-risks-of-user-sign-up-fraud-and-sms-pumping-with-amazon-cognito-user-pools/)
+ [SMS Pumping に対する防御: AWS 人為的に拡張されたトラフィックとの戦いに役立つ新機能](https://aws.amazon.com/blogs/messaging-and-targeting/defending-against-sms-pumping-new-aws-features-to-help-combat-artificially-inflated-traffic/)

## Amazon Cognito ユーザープールでの SMS メッセージングの初回セットアップ
<a name="user-pool-sms-settings-first-time"></a>

Amazon Cognito は Amazon SNS を間接的に使用して AWS End User Messaging SMS、ユーザープールから SMS メッセージを送信します。[カスタム SMS 送信者の Lambda トリガー](user-pool-lambda-custom-sms-sender.md) を使用して、独自のリソースを使用し、SMS メッセージを送信することもできます。特定の で SMS テキストメッセージを初めてセットアップすると AWS リージョン、 はそのリージョン AWS アカウント の SMS サンドボックスに AWS End User Messaging SMS を配置します。 AWS End User Messaging SMS はサンドボックスを使用して不正使用を防止し、コンプライアンス要件を満たします。 AWS アカウント がサンドボックスにある場合、 はいくつかの[制限](https://docs.aws.amazon.com/sms-voice/latest/userguide/sandbox.html#sandbox-sms) AWS End User Messaging SMS を適用します。例えば、発信元 ID がある場合、最大 10 個の検証済み送信先番号にテキストメッセージを送信したり、発信元 ID なしでメッセージの送信をシミュレートしたりできます。がサンドボックスに AWS アカウント 残っている間は、本番環境で SMS メッセージを送信しないでください。サンドボックスに置かれている間、Amazon Cognito はユーザーの電話番号にメッセージを送信できません。

**Topics**
+ [Amazon Cognito が SMS メッセージを送信するために使用できる IAM ロールを準備する AWS End User Messaging SMS](#sms-create-a-role)
+ [SMS メッセージの AWS リージョン を選択する](#sms-choose-a-region)
+ [米国の電話番号に SMS メッセージを送信するための発信元 ID を取得する](#user-pool-sms-settings-first-time-origination)
+ [SMS サンドボックスに置かれていることを確認する](#user-pool-sms-settings-first-time-confirm-sandbox)
+ [アカウントをサンドボックスから移動する](#user-pool-sms-settings-first-time-out-sandbox)
+ [でシミュレーター番号または検証済み電話番号を使用する AWS End User Messaging SMS](#user-pool-sms-settings-first-time-verify-numbers)
+ [Amazon Cognito でユーザープールのセットアップを完了する](#user-pool-sms-settings-first-time-finish-user-pool)

### Amazon Cognito が SMS メッセージを送信するために使用できる IAM ロールを準備する AWS End User Messaging SMS
<a name="sms-create-a-role"></a>

ユーザープールから SMS メッセージを送信すると、Amazon Cognito はアカウントの IAM ロールを引き受けます。Amazon Cognito は、そのロールに割り当てられた `sns:Publish` アクセス許可を使用して、ユーザーに SMS メッセージを送信します。Amazon Cognito コンソールでは、ユーザープールの **[認証方法]** メニューの **[SMS]** の下で **[IAM ロールの選択]** を設定するか、この選択をユーザープール作成ウィザードで行うことができます。

次の IAM ロール信頼ポリシーの例では、Amazon Cognito ユーザープールに、ロールを引き受ける制限付きの機能を付与しています。Amazon Cognito は、次の条件を満たす場合にのみロールを引き受けることができます。
+ assume-role オペレーションは、`aws:SourceArn` 条件のユーザープールに代わって行われます。
+ assume-role オペレーションは、`aws:SourceAccount` 条件によって設定された AWS アカウント のユーザープールに代わって行われます。
+ assume-role オペレーションには、`sts:externalId` 条件の外部 ID が含まれます。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "cognito-idp.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
                    "aws:SourceAccount": "111122223333"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:cognito-idp:us-west-2:111122223333:userpool/us-west-2_EXAMPLE"
                }
            }
        }
    ]
}
```

------

条件 `aws:SourceArn` の値には、正確な[ユーザープール ARN](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncognitouserpools.html#amazoncognitouserpools-resources-for-iam-policies) またはワイルドカード ARN を指定できます。 AWS マネジメントコンソール または DescribeUserPool API リクエストを使用して、ユーザープールの ARNs を検索します。 [DescribeUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPool.html) 

[多要素認証](user-pool-settings-mfa-sms-email-message.md)用の SMS メッセージを送信するには、IAM ロールの信頼ポリシーに `sts:ExternalId` 条件が含まれている必要があります。この条件の値は、ユーザープールの [SmsConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-SmsConfiguration) の `ExternalId` プロパティと一致する必要があります。Amazon Cognito コンソールでユーザープールの作成プロセス中に IAM ロールを作成すると、Amazon Cognito は、ロールとユーザープール設定で外部 ID をセットアップします。これは、既存の IAM ロールを使用する場合には適用されません。

[UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストのユーザープール `ExternalId` パラメータを更新したうえで、IAM ロールの信頼ポリシーを同じ値の `sts:externalId` 条件で更新する必要があります。API を使用して元の設定を保持するようにユーザープールを更新する方法については、「[ユーザープールとアプリケーションクライアントの設定更新](cognito-user-pool-updating.md)」を参照してください。

IAM ロールおよび信頼ポリシーの詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[ロールに関する用語と概念](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html)」を参照してください。

### SMS メッセージの AWS リージョン を選択する
<a name="sms-choose-a-region"></a>

**注記**  
の SMS メッセージが で管理 AWS されるようになりました[AWS End User Messaging SMS](https://console.aws.amazon.com/sms-voice/home)。

一部の では AWS リージョン、Amazon Cognito SMS メッセージに使用する Amazon SNS リソースを含むリージョンを選択できます。 Amazon Cognito アジアパシフィック (ソウル) を除く Amazon Cognito が利用可能なすべての AWS リージョン で、ユーザープールを作成した AWS リージョン で Amazon SNS リソースを使用できます。リージョンを選択したときに SMS メッセージングを高速かつ信頼性の高いものにするには、ユーザープールと同じリージョンの Amazon SNS リソースを使用します。

新規ユーザープールウィザードの**メッセージ配信の設定**ステップで、SMS リソースのリージョンを選択します。既存のユーザープールの **[認証方法]** メニューで **[SMS]** の下にある **[編集]** を選択することもできます。

起動時に、一部の AWS リージョン Amazon Cognito は代替リージョンに Amazon SNS リソースを含む SMS メッセージを送信しました。希望するリージョンを設定するには、ユーザープールの [SmsConfigurationType](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SmsConfigurationType.html) オブジェクトの `SnsRegion` パラメータを使用します。次の表から **Amazon Cognito リージョン** に Amazon Cognito ユーザープールリソースをプログラムによって作成し、`SnsRegion` パラメータを提供しない場合、ユーザープールは**レガシー Amazon SNS 代替リージョン**で Amazon SNS リソースを使用して SMS メッセージを送信します。

アジアパシフィック (ソウル) の Amazon Cognito ユーザープール AWS リージョン は、アジアパシフィック (東京) リージョンの Amazon SNS 設定を使用する必要があります。

Amazon SNS (経由 AWS End User Messaging SMS) は、すべての新しいアカウントの使用量クォータを 1 か月あたり 1.00 USD (USD) に設定します。Amazon Cognito で使用する で支出制限を引き上げ AWS リージョン た可能性があります。 AWS リージョン Amazon SNS SMS メッセージの を変更する前に、 AWS サポートセンターでクォータ引き上げケースを開いて、新しいリージョンの制限を増やします。詳細については、「 *AWS End User Messaging SMS ユーザーガイド*[」の AWS End User Messaging SMS 「MMS および音声サンドボックスから本番環境への移行](https://docs.aws.amazon.com/sms-voice/latest/userguide/sandbox.html#sandbox-sms-move-to-production)」を参照してください。

次の表の任意の **Amazon Cognito リージョン**の SMS メッセージを、対応する **SMS メッセージリージョン**の AWS End User Messaging SMS リソースで送信できます。


| Amazon Cognito リージョン | SMS メッセージリージョン | 
| --- | --- | 
|  米国東部 (オハイオ)  |  米国東部 (オハイオ)、米国東部 (バージニア北部)  | 
|  米国東部 (バージニア北部)  |  米国東部 (バージニア北部)  | 
|  米国西部 (北カリフォルニア)  |  米国西部 (北カリフォルニア)  | 
|  米国西部 (オレゴン)  |  米国西部 (オレゴン)  | 
|  カナダ (中部)  |  カナダ (中部)、米国東部 (バージニア北部)  | 
|  カナダ西部 (カルガリー)  |  カナダ西部 (カルガリー)  | 
|  メキシコ (中部)  |  メキシコ (中部)  | 
|  欧州 (フランクフルト)  |  欧州 (フランクフルト)、欧州 (アイルランド)  | 
|  欧州 (ロンドン)  |  欧州 (ロンドン)、欧州 (アイルランド)  | 
|  欧州 (アイルランド)  |  欧州 (アイルランド)  | 
|  欧州 (パリ)  |  欧州 (パリ)  | 
|  欧州 (ストックホルム)  |  欧州 (ストックホルム)  | 
|  欧州 (ミラノ)  |  欧州 (ミラノ)  | 
|  欧州 (スペイン)  |  欧州 (スペイン)  | 
|  欧州 (チューリッヒ)  |  欧州 (チューリッヒ)  | 
| アジアパシフィック (マレーシア) | アジアパシフィック (シンガポール) | 
|  アジアパシフィック (タイ)  |  アジアパシフィック (ムンバイ)  | 
|  アジアパシフィック (ムンバイ)  |  アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)  | 
|  アジアパシフィック (ハイデラバード)  |  アジアパシフィック (ハイデラバード)  | 
|  アジアパシフィック (香港)  |  アジアパシフィック (シンガポール)  | 
|  アジアパシフィック (ソウル)  |  アジアパシフィック (東京)  | 
|  アジアパシフィック (シンガポール)  |  アジアパシフィック (シンガポール)  | 
|  アジアパシフィック (シドニー)  |  アジアパシフィック (シドニー)  | 
|  アジアパシフィック (東京)  |  アジアパシフィック (東京)  | 
|  アジアパシフィック (ジャカルタ)  |  アジアパシフィック (ジャカルタ)  | 
|  アジアパシフィック (大阪)  |  アジアパシフィック (大阪)  | 
|  アジアパシフィック (メルボルン)  |  アジアパシフィック (メルボルン)  | 
|  中東 (バーレーン)  |  中東 (バーレーン)  | 
|  中東 (アラブ首長国連邦)  |  中東 (アラブ首長国連邦)  | 
|  南米 (サンパウロ)  |  南米 (サンパウロ)  | 
|  イスラエル (テルアビブ)  |  イスラエル (テルアビブ)  | 
|  アフリカ (ケープタウン)  |  アフリカ (ケープタウン)  | 

### 米国の電話番号に SMS メッセージを送信するための発信元 ID を取得する
<a name="user-pool-sms-settings-first-time-origination"></a>

米国の電話番号に SMS テキストメッセージを送信する場合は、SMS サンドボックステスト環境または本番環境を構築するかどうかにかかわらず、発信元 ID を取得する必要があります。

米国の通信事業者は、米国の電話番号にメッセージを送信する場合に発信元 ID を義務付けています。発信元 ID をまだ取得していない場合は、取得する必要があります。発信元 ID を取得する方法については、「*AWS End User Messaging SMS ユーザーガイド*」の「[電話番号をリクエストする](https://docs.aws.amazon.com/sms-voice/latest/userguide/phone-numbers-request.html)」を参照してください。

同じ に複数の発信元 ID がある場合 AWS リージョン、 は、ショートコード、10DLC、通話料無料番号の優先順位で発信元 ID タイプ AWS End User Messaging SMS を選択します。この優先順位を変更することはできません。詳細については、「[AWS End User Messaging SMS に関するよくある質問](https://aws.amazon.com/end-user-messaging/faqs/)」を参照してください。

### SMS サンドボックスに置かれていることを確認する
<a name="user-pool-sms-settings-first-time-confirm-sandbox"></a>

次の手順を使用して SMS サンドボックスに移動していることを確認します。本番稼働 AWS リージョン 用 Amazon Cognito ユーザープールがある ごとに繰り返します。

#### Amazon Cognito コンソールで SMS サンドボックスステータスを確認します。
<a name="check-that-you-are-in-the-sms-sandbox"></a>

**SMS サンドボックスに置かれていることを確認する**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから存在するユーザープールを 1 つ選択します。

1. **[認証方法]** メニューを選択します。

1. **[SMS configuration]** (SMS 設定) セクションで、**[Move to Amazon SNS production environment]** (Amazon SNS 本番環境に移行する) を展開します。アカウントが SMS サンドボックスに置かれている場合は、以下のメッセージが表示されます。

   **SMS メッセージの設定を完了するための AWS のサービス 依存関係を設定する**

   このメッセージが表示されない場合は、アカウント内での SMS メッセージのセットアップが既に実行されています。「[Amazon Cognito でユーザープールのセットアップを完了する](#user-pool-sms-settings-first-time-finish-user-pool)」へ進んでください。

1. **[Amazon SNS 本番環境に移行]** で [[Amazon SNS]](https://console.aws.amazon.com/sns/home) リンクを選択します。これにより、新しいタブで Amazon SNS コンソールが開きます。

1. サンドボックス環境に置かれていることを確認します。コンソールメッセージには、サンドボックスのステータスと AWS リージョン、次のように表示されます。

   `This account is in the SMS sandbox in US East (N. Virginia).`

### アカウントをサンドボックスから移動する
<a name="user-pool-sms-settings-first-time-out-sandbox"></a>

本番稼働でアプリを使用するには、アカウントを SMS サンドボックスから本番環境に移動します。Amazon Cognito で使用する AWS End User Messaging SMS リソースを含む発信元 ID を に設定 AWS リージョン したら、 が SMS サンドボックスに AWS アカウント 残っている間、米国の電話番号を確認できます。本番環境にいる場合は、SMS メッセージを送信する前にユーザーの電話番号を検証する必要はありません。

コンソールまたは Amazon SNS AWS End User Messaging SMS コンソールからサンドボックスを終了するリクエストを作成できます。詳細な手順については、「*AWS End User Messaging SMS ユーザーガイド*」の「[SMS サンドボックスからの移動](https://docs.aws.amazon.com/sms-voice/latest/userguide/sandbox.html#sandbox-sms-move-to-production)」を参照してください。

### でシミュレーター番号または検証済み電話番号を使用する AWS End User Messaging SMS
<a name="user-pool-sms-settings-first-time-verify-numbers"></a>

SMS サンドボックスからアカウントを移動した場合は、このステップをスキップします。

サンドボックス内に残っていて、発信元番号を設定している場合は、検証済みの送信先番号にメッセージを送信できます。検証済みの送信先を設定するには、「*AWS End User Messaging SMS ユーザーガイド*」の「[検証済みの送信先電話番号を追加する](https://docs.aws.amazon.com/sms-voice/latest/userguide/verify-destination-phone-number.html)」を参照してください。

シミュレートした送信元と送信先を使用してメッセージを送信することもできます。シミュレーターメッセージはログを生成しますが、通信事業者ネットワーク経由で送信されることはありません。[[ショートカット]](https://console.aws.amazon.com/sms-voice/home?#/shortcuts) メニューから、**[SMS シミュレーターで SMS 送信をテストする]** を選択します。詳細については、「*AWS End User Messaging SMS ユーザーガイド*」の「[シミュレーター電話番号](https://docs.aws.amazon.com/sms-voice/latest/userguide/test-phone-numbers.html)」を参照してください。

### Amazon Cognito でユーザープールのセットアップを完了する
<a name="user-pool-sms-settings-first-time-finish-user-pool"></a>

ユーザープールを作成または[編集](signing-up-users-in-your-app.md#verification-configure)していたブラウザタブに戻ります。手順を完了します。ユーザープールに SMS 設定を正常に追加すると、Amazon Cognito は内部の電話番号にテストメッセージを送信して、設定が機能することを確認します。Amazon SNS は、テスト SMS メッセージごとに料金を請求します。

# Amazon Cognito ユーザープールのセキュリティ機能を使用する
<a name="managing-security"></a>

ネットワーク侵入、パスワードの推測、ユーザーのなりすまし、悪意のあるサインアップやサインインからアプリケーションを保護する場合があります。Amazon Cognito ユーザープールのセキュリティ機能の設定は、セキュリティアーキテクチャの重要なコンポーネントである可能性があります。アプリケーションのセキュリティは、「 責任共有モデル」で説明されているように*、お客様の責任「クラウド内のセキュリティ*」です。 AWS [https://aws.amazon.com/compliance/shared-responsibility-model/](https://aws.amazon.com/compliance/shared-responsibility-model/)この章のツールは、これらの目標に沿ったアプリケーションセキュリティ設計の機能に役立ちます。

ユーザープールを設定するときに行う必要がある重要な決定は、パブリックサインアップとパブリックサインインを許可するかどうかです。機密クライアント、管理上の作成とユーザーの確認、ドメインのないユーザープールなどのユーザープールオプションの中には、インターネット経由の攻撃の程度が小さいものがあります。ただし、一般的なユースケースは、インターネット上のすべてのユーザーからサインアップを受け入れ、すべてのオペレーションをユーザープールに直接送信するパブリッククライアントです。どの設定でも、特にこうしたパブリック設定の場合は、セキュリティ機能を念頭に置いてユーザープールの計画とデプロイを行うことをお勧めします。セキュリティが不十分な場合、不要なソースが新しいアクティブユーザーを作成したり、既存のユーザーを悪用しようとしたりすると、 AWS 請求書にも影響する可能性があります。

MFA と脅威保護は、[ローカルユーザー](cognito-terms.md#terms-localuser)に適用されます。サードパーティー IdP は、[フェデレーションユーザー](cognito-terms.md#terms-federateduser)のセキュリティ体制を担当します。ユーザープールのセキュリティ機能

**多要素認証 (MFA)**  
ユーザープールのサインインを確認するために、ユーザープールが E メール (エッセンシャル機能プランまたはプラス機能プランの場合)、SMS メッセージ、または Authenticator アプリケーションを使用して送信するコードをリクエストします。

**脅威保護**  
リスクの指標に関してサインインをモニタリングして、MFA を適用するか、またはサインインをブロックします。アクセストークンにカスタムクレームとスコープを追加します。MFA コードを E メールで送信します。

**AWS WAF ウェブ ACLs**  
[ユーザープールエンドポイントと認証 API](authentication-flows-public-server-side.md#user-pools-API-operations) への受信トラフィックについて、ネットワークレイヤーとアプリケーションレイヤーでの望ましくないアクティビティがないか検査します。

**大文字と小文字の区別**  
E メールアドレスまたは任意のユーザー名が、文字の大文字と小文字の区別を除き、他のユーザーと同じになるユーザーの作成を防止します。

**削除保護**  
自動システムがユーザープールを誤って削除しないようにします。 AWS マネジメントコンソールでのユーザープールの削除を追加で確認する必要があります。

**ユーザー存在エラー**  
ユーザープール内の既存のユーザー名とエイリアスの開示を防止します。ユーザー名が有効かどうかにかかわらず、認証に失敗した場合に一般的なエラーを返します。

**Topics**
+ [ユーザープールに MFA を追加します](user-pool-settings-mfa.md)
+ [脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)
+ [AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)
+ [ユーザープールの大文字と小文字の区別](user-pool-case-sensitivity.md)
+ [ユーザープールの削除保護](user-pool-settings-deletion-protection.md)
+ [ユーザー存在エラー応答の管理](cognito-user-pool-managing-errors.md)

# ユーザープールに MFA を追加します
<a name="user-pool-settings-mfa"></a>

これは、一般的にはユーザー名とパスワードになっている、初期設定の*知っていること*の認証要素に、*持っていること*の認証要素を追加するものです。パスワードを主要な認証要素とするユーザーをサインインさせるには、SMS テキストメッセージ、E メールメッセージ、または時間ベースのワンタイムパスワード (TOTP) を追加要素として選択できます。

多要素認証 (MFA) は、アプリケーション内の[ローカルユーザー](cognito-terms.md#terms-localuser)のセキュリティを向上させます。[フェデレーションユーザー](cognito-terms.md#terms-federateduser)の場合、Amazon Cognito はすべての認証プロセスを IdP に委任するので、追加の認証要素を提供しません。

**注記**  
新しいユーザーがアプリに初めてサインインするときに、Amazon Cognito は OAuth 2.0 トークンを発行します。これは、ユーザープールに MFA が必要な場合でも同様です。ユーザーが初めてサインインするときの 2 番目の認証要因は、Amazon Cognito が送信する検証メッセージの確認です。ユーザープールに MFA が必要な場合、Amazon Cognito は、最初のログイン試行後の各サインイン試行で使用する追加のサインイン係数を登録するようユーザーに要求します。

アダプティブ認証では、リスクレベルの上昇に対応して、追加の要素認証を要求するようにユーザープールを設定できます。アダプティブ認証をユーザープールに追加するには、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。

ユーザープールの MFA が `required` に設定されている場合は、すべてのユーザーはサインインするために MFA を完了する必要があります。サインインするために、各ユーザーには、少なくとも 1 つの MFA 要素が必要です。MFA を必須にする場合は、ユーザーオンボーディングに MFA セットアップを含め、ユーザープールでユーザーのサインインを許可する必要があります。

MFA を必須に設定すると、マネージドログインは MFA を設定することをユーザーに求めます。ユーザープールで MFA をオプションとして設定すると、マネージドログインはユーザーに設定を求めません。オプションの MFA を使用するには、ユーザーに MFA を設定するかどうかを選択するようプロンプトを表示し、API 入力を案内して追加のサインイン要素を確認するインターフェースをアプリに構築する必要があります。

**Topics**
+ [ユーザープールの MFA について知っておくべきこと](#user-pool-settings-mfa-prerequisites)
+ [ユーザー MFA 設定](#user-pool-settings-mfa-preferences)
+ [ユーザー実行時の MFA ロジックの詳細](#user-pool-settings-mfa-user-outcomes)
+ [ユーザープールでの多要素認証を設定する](#user-pool-configuring-mfa)
+ [SMS メッセージ MFA と E メールメッセージ MFA](user-pool-settings-mfa-sms-email-message.md)
+ [TOTP ソフトウェアトークン MFA](user-pool-settings-mfa-totp.md)

## ユーザープールの MFA について知っておくべきこと
<a name="user-pool-settings-mfa-prerequisites"></a>

MFA を設定する前に、次の点を考慮します。
+ ユーザーは MFA を使用する*か*、パスワードレス要素でサインインできます。ただし、ユーザープール `MULTI_FACTOR_WITH_USER_VERIFICATION`で `FactorConfiguration`を に設定すると、ユーザー検証付きのパスキーが MFA 要件を満たすことができます`WebAuthnConfiguration`。
  + [ワンタイムパスワード](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passwordless)をサポートするユーザープールでは、MFA を必須に設定することはできません。
  + ユーザープールで `AllowedFirstAuthFactors` MFA が必要な場合、 `EMAIL_OTP`または `SMS_OTP`を に追加することはできません。`WEB_AUTHN` `FactorConfiguration` が に設定されている場合、 を追加できます`MULTI_FACTOR_WITH_USER_VERIFICATION`。
  + [選択ベースのサインイン](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)では、ユーザープールで MFA が必須である場合にのみ、すべてのアプリケーションクライアントに `PASSWORD` 要素と `PASSWORD_SRP` 要素を提供します。ユーザー名パスワードフローの詳細については、このガイドの「**認証**」章で「[永続的なパスワードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-password)」と「[永続的なパスワードと安全なペイロードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-srp)」を参照してください。
  + MFA がオプションであるユーザープールでは、MFA 要素を設定したユーザーは、選択ベースのサインインでユーザー名パスワード認証フローを使用してのみサインインできます。これらのユーザーは、すべての[クライアントベースのサインイン](authentication-flows-selection-sdk.md#authentication-flows-selection-client)フローを利用できます。

  次の表は、ユーザープールの MFA 設定とユーザーによる MFA 要素の設定が、パスワードなしの要素を使用したユーザーのサインインに与える影響を示しています。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-settings-mfa.html)
+ ユーザーが希望する MFA の方法は、パスワードの復旧に使用できる方法に影響します。希望する MFA を E メールメッセージにしたユーザーは、パスワードリセットコードを E メールで受信できません。希望する MFA を SMS メッセージにしたユーザーは、パスワードリセットコードを SMS で受信できません。

  希望するパスワードリセット方法の対象にユーザーがなっていない場合、[[パスワード復旧]](managing-users-passwords.md#user-pool-password-reset-and-recovery) 設定で代替オプションを提供する必要があります。例えば、復旧メカニズムで E メールが最優先事項になっており、E メール MFA がユーザープールのオプションである場合があります。この場合、SMS メッセージによるアカウント復旧を 2 番目のオプションとして追加するか、管理 API オペレーションを使用してこれらのユーザーのパスワードをリセットします。

  Amazon Cognito は、有効な復旧方法を持たないユーザーからのパスワードリセットリクエストに対して、`InvalidParameterException` エラーレスポンスで応答します。

  [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html#API_UpdateUserPool_Examples) のリクエスト本文の例は、`AccountRecoverySetting` を示しています。E メールメッセージによるパスワードのリセットが利用できない場合、ユーザーはここにフォールバックして、SMS メッセージによる復旧を行うことができます。
+ ユーザーは、MFA とパスワードのリセットコードを、同じ E メールアドレスや電話番号で受け取ることはできません。E メールメッセージのワンタイムパスワード (OTP) を MFA に使用する場合、アカウントの復旧には SMS メッセージを使用する必要があります。SMS メッセージの OTP を MFA に使用する場合、アカウントの復旧には E メールメッセージを使用する必要があります。MFA を使用するユーザープールでは、属性として E メールアドレスがあっても電話番号がないか、電話番号があっても E メールアドレスがない場合、ユーザーはセルフサービスのパスワード復旧を完了できない可能性があります。

  この設定でユーザーがユーザープールのパスワードをリセットできない状況を防ぐには、`email` および `phone_number` [属性を必須](user-pool-settings-attributes.md)に設定します。別の方法として、ユーザーのサインアップ時や管理者によるユーザープロファイルの作成時に、これらの属性を常に収集して設定するようにプロセスを設定することもできます。ユーザーが両方の属性を持っている場合、Amazon Cognito は、ユーザーの MFA 要素*ではない*送信先にパスワードリセットコードを自動的に送信します。
+ ユーザープールで MFA を有効にし、2 番目の要素として **SMS メッセージ**または **E メールメッセージ**を選択すると、Amazon Cognito で検証していない電話番号または E メール属性にメッセージを送信できます。ユーザーが MFA を完了すると、Amazon Cognito は、`phone_number_verified` 属性または `email_verified` 属性を `true` に設定します。
+ MFA コードの提示に 5 回失敗すると、Amazon Cognito は [サインイン試行の失敗時におけるロックアウト動作](authentication.md#authentication-flow-lockout-behavior) で説明した指数関数的タイムアウトロックアウトプロセスを開始します。
+ アカウントがユーザープールの Amazon Simple Notification Service (Amazon SNS) リソース AWS リージョン を含む の SMS サンドボックスにある場合は、SMS メッセージを送信する前に Amazon SNS で電話番号を確認する必要があります。詳細については、「[Amazon Cognito ユーザープール用の SMS メッセージ設定](user-pool-sms-settings.md)」を参照してください。
+ 脅威保護で検出されたイベントに応じてユーザーの MFA ステータスを変更するには、Amazon Cognito ユーザープールコンソールで MFA を有効にしてオプションとして設定します。詳細については、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。
+ E メールメッセージと SMS メッセージでは、各ユーザーに E メールアドレスと電話番号の属性が必要です。ユーザープールでは、`email` または `phone_number` を必須の属性として設定できます。この場合、ユーザーは電話番号を指定しない限りサインアップを完了できません。これらの属性について必要に応じた設定を行わずに、E メールメッセージ MFA または SMS メッセージ MFA を実行する場合は、サインアップ時に E メールアドレスまたは電話番号の入力を求めます。ベストプラクティスとして、ユーザープールを設定して、[これらの属性を検証する](signing-up-users-in-your-app.md)ようにユーザーに自動的にメッセージを送信します。

  Amazon Cognito は、ユーザーが SMS メッセージまたは E メールメッセージで仮コードを受信し、[VerifyUserAttribute](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifyUserAttribute.html) API リクエストでそのコードを返した場合、その電話番号または E メールアドレスを検証済みとしてカウントします。代わりに、チームは、電話番号を設定し、[AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) API リクエストを実行する管理用アプリケーションを使用して検証済みとしてマークできます。
+ MFA を必須に設定し、複数の認証要素をアクティブ化した場合、Amazon Cognito は新しいユーザーに、使用する MFA 要素を選択するよう求めます。ユーザーは、SMS メッセージ MFA をセットアップするための電話番号と、E メールメッセージ MFA をセットアップするための E メールアドレスを持っている必要があります。使用可能なメッセージベースの MFA に属性が定義されていない場合、Amazon Cognito は TOTP MFA を設定するようにユーザーに求めます。MFA 要素 (`SELECT_MFA_TYPE`) を選択し、選択した要素 (`MFA_SETUP`) を設定するように求めるプロンプトが、[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) の API オペレーションへのチャレンジレスポンスとして表示されます。

## ユーザー MFA 設定
<a name="user-pool-settings-mfa-preferences"></a>

ユーザーは複数の MFA 要素を設定できます。アクティブにできるのは 1 つだけです。ユーザープール設定またはユーザープロンプトで、ユーザーの有効な MFA 設定を選択できます。ユーザープールの設定と独自のユーザーレベルの設定が以下の条件を満たす場合、ユーザープールは MFA コードをユーザーに要求します。

1. ユーザープールで MFA をオプションまたは必須に設定している。

1. ユーザーは、有効な `email` 属性または `phone_number` 属性を持っているか、Authenticator アプリケーションを TOTP 用にセットアップ済みである。

1. 少なくとも 1 つの MFA 要素がアクティブである。

1. 1 つの MFA 要素を優先として設定している。

### サインインと MFA に同じ要素を使用しない
<a name="user-pool-settings-mfa-preferences-same-factor"></a>

ユーザープールは、1 つのサインイン要素を一部またはすべてのユーザーが使用できる唯一のサインインおよび MFA オプションにする方法で設定できます。この結果は、プライマリサインインのユースケースが E メールメッセージまたは SMS メッセージワンタイムパスワード (OTPs) である場合に発生する可能性があります。ユーザーが優先する MFA は、次の条件でサインインと同じタイプの要素である場合があります。
+ ユーザープールには MFA が必要です。
+ E メールと SMS OTP は、ユーザープールでサインイン*オプションと* MFA オプションを使用できます。
+ ユーザーは E メールまたは SMS メッセージ OTP でサインインします。
+ E メールアドレス属性はありますが、電話番号属性はありません。または、電話番号属性はありますが、E メールアドレス属性はありません。

このシナリオでは、ユーザーは E メール OTP でサインインし、E メール OTP で MFA を完了できます。このオプションは、MFA の必須関数をキャンセルします。ワンタイムパスワードでサインインするユーザーは、MFA とは異なる配信方法をサインインに使用できる必要があります。ユーザーに SMS オプションと E メールオプションの両方がある場合、Amazon Cognito は別の要素を自動的に割り当てます。たとえば、ユーザーが E メール OTP でサインインする場合、希望する MFA は SMS OTP です。

ユーザープールがサインインと MFA の両方で OTP 認証をサポートしている場合、次の手順を実行して同じ要素認証に対処します。

1. サインイン要因として E メールと SMS OTP の両方を有効にします。

1. E メールと SMS OTP の両方を MFA 要因として有効にします。

1. 収集

### ユーザープールの設定と MFA オプションへの影響
<a name="user-pool-settings-mfa-preferences-things-to-know"></a>

ユーザープールの設定は、ユーザーが選択できる MFA の方法に影響します。以下のいくつかのユーザープール設定が、ユーザーによる MFA の設定に影響します。
+ Amazon Cognito コンソールの **[サインイン]** メニューの **[多要素認証]** 設定で、MFA をオプションまたは必須に設定するか、オフにすることができます。この設定と同等の API は、`CreateUserPool`、`UpdateUserPool`、および `SetUserPoolMfaConfig` の [MfaConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-MfaConfiguration) パラメータです。

  また、**[多要素認証]** 設定では、**[MFA の方法]** 設定によって、ユーザーが設定できる MFA 要素が決まります。この設定と同等の API は [SetUserPoolMfaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserPoolMfaConfig.html) オペレーションです。
+ **[サインイン]** メニューの **[ユーザーアカウントの復旧]** で、パスワードを忘れたユーザーにユーザープールからメッセージを送信する方法を設定できます。ユーザーの MFA の方法は、パスワードを忘れた場合のコードをユーザープールから配信する方法と同じにすることはできません。パスワードを忘れた場合の配信方法の API パラメータは、`CreateUserPool` および `UpdateUserPool` の [AccountRecoverySetting](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-AccountRecoverySetting) パラメータです。

  例えば、復旧オプションが **[E メールのみ]** の場合、ユーザーは E メール MFA を設定できません。これは、同じユーザープールで E メール MFA を有効にして、復旧オプションを **[E メールのみ]** に設定することはできないためです。このオプションを **[使用可能な場合は E メール、それ以外の場合は SMS]** に設定すると、E メールが優先の復旧オプションになりますが、ユーザーが E メールメッセージ復旧の対象でない場合、ユーザープールは SMS メッセージにフォールバックできます。この場合、ユーザーは E メール MFA を優先として設定し、パスワードをリセットするときにのみ SMS メッセージを受信できます。
+ 使用できるものとして 1 つの MFA の方法のみを設定した場合、ユーザーの MFA 設定を管理する必要はありません。
+ SMS をアクティブに設定すると、ユーザープールで SMS メッセージが、使用できる MFA の方法に自動的になります。

  ユーザープール内の独自の Amazon SES リソースと、エッセンシャル機能プランまたはプラス機能プランを使用した、アクティブな [E メール設定](user-pool-email.md)により、E メールメッセージは自動的にユーザープールで使用可能な MFA 方法になります。
+ ユーザープールで MFA を必須に設定すると、ユーザーは MFA の方法を有効または無効にできません。設定できるのは、希望する方法のみです。
+ ユーザープールで MFA をオプションとして設定すると、マネージドログインは、MFA を設定するようユーザーに求めません。ただし、希望する MFA の方法を持っているユーザーには、MFA コードの入力を求めます。
+ [[脅威保護]](cognito-user-pool-settings-threat-protection.md) を有効にし、アダプティブ認証レスポンスをフル機能モードで設定する場合、MFA がユーザープールでオプションになっている必要があります。アダプティブ認証によるレスポンスオプションの 1 つは、サインイン試行にリスクレベルが含まれていると評価されたユーザーに MFA を要求することです。

  コンソールの **[サインアップ]** メニューの **[必須属性]** 設定は、ユーザーがアプリケーションにサインアップするために E メールアドレスまたは電話番号を入力する必要があるかどうかを決定します。ユーザーが対応する属性を持っている場合、E メールメッセージと SMS メッセージは MFA 要素として適格になります。`CreateUserPool` の[スキーマ](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#CognitoUserPools-CreateUserPool-request-Schema)パラメータは、必要に応じて属性を設定します。
+ ユーザープールで MFA を必須として設定した場合、ユーザーがマネージドログインを使用してサインインすると、Amazon Cognito はユーザープールで利用可能な MFA 方法から選択するようユーザーに求めます。マネージドログインは、E メールアドレスまたは電話番号の収集と TOTP の設定を処理します。以下の図は、Amazon Cognito がユーザーに提示するオプションの背後のロジックを示しています。

### ユーザーの MFA 設定を構成する
<a name="user-pool-settings-mfa-preferences-configure"></a>

アクセストークン認証を使用するセルフサービスモデル、または管理 API オペレーションを使用する管理者管理モデルで、ユーザーの MFA の希望を設定できます。これらのオペレーションは MFA の方法を有効または無効にし、複数の方法のうちのいずれかを、希望するオプションとして設定します。ユーザーが MFA の希望を設定すると、Amazon Cognito はサインイン時に、希望する MFA の方法によるコードを提供するようにユーザーに求めます。希望を設定していないユーザーは、`SELECT_MFA_TYPE` チャレンジで、希望する方法を選択するよう求めるプロンプトを受け取ります。
+ ユーザーセルフサービスモデルまたはパブリックアプリケーションでは、サインインユーザーのアクセストークンで認可された [SetUserMfaPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserMFAPreference.html) によって MFA の設定が決まります。
+ 管理者管理アプリケーションまたは機密アプリケーションでは、管理者 AWS 認証情報で承認された [AdminSetUserPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserMFAPreference.html) が MFA 設定を設定します。

また、Amazon Cognito コンソールの **[ユーザー]** メニューからユーザーの MFA 設定を構成することもできます。Amazon Cognito ユーザープール API オペレーションのパブリック認証モデルと機密認証モデルの詳細については、「[API、OIDC、マネージドログインページの認証についての理解](authentication-flows-public-server-side.md#user-pools-API-operations)」を参照してください。

## ユーザー実行時の MFA ロジックの詳細
<a name="user-pool-settings-mfa-user-outcomes"></a>

ユーザーがサインインするときに実行する手順を決定するために、ユーザープールはユーザーの MFA 設定、[ユーザー属性](user-pool-settings-attributes.md)、[ユーザープールの MFA 設定](#user-pool-configuring-mfa)、[脅威保護](cognito-user-pool-settings-adaptive-authentication.md)アクション、[セルフサービスのアカウントの復旧](managing-users-passwords.md#user-pool-password-reset-and-recovery)に関する設定を評価します。次に、ユーザーをサインインさせ、MFA の方法の選択、設定、または入力をユーザーに求めます。MFA の方法を設定する場合、ユーザーは [E メールアドレスまたは電話番号](user-pool-settings-mfa-sms-email-message.md)を指定するか、[TOTP Authenticator を登録](user-pool-settings-mfa-totp.md#totp-mfa-set-up-api)する必要があります。事前に MFA のオプションを設定し、[優先オプションを登録](#user-pool-settings-mfa-preferences-configure)することもできます。以下の図は、ユーザープールの設定が、初回サインアップ直後のサインイン試行にどのような影響を及ぼすかを詳しく示しています。

ここに示したロジックは、SDK ベースのアプリケーションと[マネージドログイン](cognito-user-pools-managed-login.md)のサインインに適用されますが、マネージドログインの場合、影響はあまり明確ではありません。MFA のトラブルシューティングを行うときは、ユーザーの結果から遡って、決定に影響を及ぼしたユーザープロファイルやユーザープールの設定を検討してください。

![\[Amazon Cognito ユーザープールでのエンドユーザーによる MFA 選択の意思決定プロセスを示す図。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-mfa-decision-tree.png)


次のリストは、意思決定ロジック図の番号に対応したステップごとの詳しく説明です。![\[checkmark\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png) は、認証の成功とフローの結果を示します。![\[error\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/error.png) は、認証の失敗を示します。

1. ユーザーはサインイン画面でユーザー名を入力するか、ユーザー名とパスワードを入力します。有効な認証情報を提示しない場合、サインインリクエストは拒否されます。

1. ユーザー名パスワード認証が成功したら、MFA を必須、オプション、またはオフのいずれにするかを決めます。オフにした場合は、正しいユーザー名とパスワードを入力すると、認証が成功します。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

   1. MFA をオプションにした場合は、ユーザーが TOTP Authenticator を設定済みであるかどうかを確認します。TOTP を設定済みである場合は、TOTP を使用した MFA を求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

   1. 脅威保護のアダプティブ認証機能により、MFA を設定することをユーザーに求めているかどうかを確認します。MFA が割り当てられていない場合、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

1. MFA が必須であるか、アダプティブ認証が MFA を割り当て済みである場合は、ユーザーが MFA 要素を有効および優先として設定しているかどうかを確認します。設定している場合は、その要素を使用した MFA の入力を求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

1. ユーザーが MFA 設定を指定していない場合は、ユーザーが TOTP Authenticator を登録済みであるかどうかを確認します。

   1. ユーザーが TOTP Authenticator を登録済みである場合は、TOTP MFA がユーザープールで使用可能かどうかを確認します (ユーザーが以前に Authenticator を設定した後で、TOTP MFA が無効になっている可能性があります)。

   1. E メールメッセージ MFA または SMS メッセージ MFA もユーザープールで利用できるかどうかを確認します。

   1.  E メール MFA も SMS MFA も利用できない場合は、ユーザーに TOTP を使用した MFA を求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

   1. E メール MFA または SMS MFA が利用可能な場合は、ユーザーが対応する `email` 属性または `phone_number` 属性を持っているかどうかを確認します。持っている場合は、セルフサービスのアカウント復旧のプライマリ方法ではなく、MFA が有効になっている属性であれば、ユーザーが使用できます。

   1. TOTP と利用可能な SMS MFA 要素または E メール MFA 要素を含む `MFAS_CAN_SELECT` オプションを使用して、`SELECT_MFA_TYPE` チャレンジに応答するようユーザーに求めます。

   1.  `SELECT_MFA_TYPE` チャレンジに応じて選択した要素の入力をユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

1. ユーザーが TOTP Authenticator を登録していないか、登録済みでも TOTP MFA が現在無効になっている場合は、ユーザーが `email` 属性または `phone_number` 属性を持っているかどうかを確認します。

1.  ユーザーが属性として E メールアドレスまたは電話番号のみを持っている場合、その属性が、ユーザープールでパスワードリセット用のアカウント復旧メッセージを送信するために実装する方法と同じであるかどうかを確認します。同じである場合、MFA を必須としているサインインは完了できず、Amazon Cognito はエラーを返します。このユーザーのサインインを有効にするには、復旧用ではない属性を追加するか、TOTP Authenticator を登録する必要があります。![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/error.png)

   1. 復旧用ではない E メールアドレスや電話番号を利用できる場合は、対応する E メール要素または SMS MFA 要素が有効になっているかどうかを確認します。

   1. 復旧用ではない E メールアドレス属性があり、E メール MFA が有効になっている場合は、`EMAIL_OTP` チャレンジに応答するよう求められます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

   1. 復旧用ではない電話番号属性があり、SMS MFA が有効になっている場合は、`SMS_MFA` チャレンジに応答するよう求められます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

   1. 有効な E メール MFA 要素または SMS MFA 要素の対象となる属性がない場合は、TOTP MFA が有効になっているかどうかを確認します。TOTP MFA が無効になっている場合、ユーザーは MFA を必須としているサインインを完了できず、Amazon Cognito はエラーを返します。このユーザーのサインインを有効にするには、復旧用ではない属性を追加するか、TOTP Authenticator を登録する必要があります。![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/error.png)
**注記**  
ユーザーが TOTP Authenticator を持っているが TOTP MFA が無効になっている場合、このステップは **[いいえ]** と評価済みです。

   1. TOTP MFA が有効になっている場合は、`MFAS_CAN_SETUP` オプションの `SOFTWARE_TOKEN_MFA` を使用してユーザーに `MFA_SETUP` チャレンジを提示します。このチャレンジを完了するには、ユーザーの TOTP Authenticator を個別に登録し、`"ChallengeName": "MFA_SETUP", "ChallengeResponses": {"USERNAME": "[username]", "SESSION": "[Session ID from VerifySoftwareToken]}"` を使用して応答する必要があります。

   1. ユーザーが [VerifySoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifySoftwareToken.html) リクエストからのセッショントークンで `MFA_SETUP` チャレンジに応答すると、ユーザーは `SOFTWARE_TOKEN_MFA` チャレンジに応答するよう求められます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

1. ユーザーが E メールアドレスと電話番号の両方を持っている場合は、どちらの属性がパスワードリセットのアカウント復旧メッセージのプライマリ方法であるかを確認します。

   1. セルフサービスのアカウントの復旧が無効になっている場合は、どちらの属性も MFA に使用できます。E メール MFA 要素と SMS MFA 要素の一方または両方が有効になっているかどうかを確認します。

   1. 両方の属性が MFA 要素として有効になっている場合は、`MFAS_CAN_SELECT` のオプション (`SMS_MFA` と `EMAIL_OTP`) を使用して `SELECT_MFA_TYPE` チャレンジに応答するようユーザーに求めます。

   1. `SELECT_MFA_TYPE` チャレンジに応じて選択した要素の入力をユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

   1. 1 つの属性のみが適格な MFA 要素である場合は、残りの要素のチャレンジに応答するようユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

      この結果が生じるのは、以下の場合です。

      1. ユーザーが `email` 属性と `phone_number` 属性を持っていて、SMS MFA と E メール MFA が有効であり、アカウント復旧のプライマリ方法が E メールまたは SMS メッセージである場合。

      1. ユーザーが `email` 属性と `phone_number` 属性を持っていて、SMS MFA または E メール MFA の一方のみが有効であり、セルフサービスのアカウントの復旧が無効になっている場合。

1. ユーザーが TOTP Authenticator を登録しておらず、`email` 属性も `phone_number` 属性も持っていない場合は、`MFA_SETUP` チャレンジに応答するようユーザーに求めます。`MFAS_CAN_SETUP` のリストには、ユーザープールのすべての有効な MFA 要因のうち、アカウント復旧のプライマリ方法ではないものが表示されます。ユーザーは E メール MFA または TOTP MFA で `ChallengeResponses` を使用し、このチャレンジに応答できます。SMS MFA を設定するには、電話番号属性を別個に追加し、認証を再開します。

   TOTP MFA の場合は、`"ChallengeName": "MFA_SETUP", "ChallengeResponses": {"USERNAME": "[username]", "SESSION": "[Session ID from VerifySoftwareToken]"}` を使用して応答します。

   E メール MFA の場合は、`"ChallengeName": "MFA_SETUP", "ChallengeResponses": {"USERNAME": "[username]", "email": "[user's email address]"}` を使用して応答します。

   1. `SELECT_MFA_TYPE` チャレンジに応じて選択した要素の入力をユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。![\[Green circular icon with a checkmark symbol inside.\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/checkmark.png)

## ユーザープールでの多要素認証を設定する
<a name="user-pool-configuring-mfa"></a>

MFA を設定するには、Amazon Cognito コンソールを使用するか、[SetUserPoolMfaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserPoolMfaConfig.html) API オペレーションと SDK メソッドを使用できます。

**Amazon Cognito コンソールで MFA を設定する**

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

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[サインイン]** メニューを選択します。**[多要素認証]** を見つけて、**[編集]** を選択します。

1. ユーザープールで使用する **[MFA enforcement]** (MFA 強制実行) 方法を選択します。  
![\[Amazon Cognito コンソールの MFA オプションを示すスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-mfa.png)

   1. **MFA が必要**。ユーザープール内のすべてのユーザーは、さらに SMS、E メール、または時間ベースのワンタイムパスワード (TOTP) コードを追加の認証要素として使用し、サインインする必要があります。

   1. **オプションの MFA**。ユーザーに追加のサインイン要素を登録するオプションを提供した場合でも、MFA を設定していないユーザーに依然としてサインインを許可できます。アダプティブ認証を使用している場合は、このオプションを選択してください。アダプティブ認証の詳細については、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。

   1. **MFA なし**。ユーザーは、サインイン要素を追加登録することはできません。

1. アプリケーションでサポートする **[MFA methods]** (MFA メソッド) を選択します。2 番目の要素として **E メールメッセージ**、**SMS メッセージ**または TOTP 生成**認証アプリケーション**を設定できます。

1. 2 番目の要素として SMS テキストメッセージを使用していて、SMS メッセージ用の Amazon Simple Notification Service で使用する IAM ロールを設定していない場合は、コンソールで作成できます。ユーザープールの **[認証方法]** メニューで、**[SMS]** を見つけて **[編集]** を選択します。Amazon Cognito がユーザーに SMS メッセージを送信することを許可する既存のロールを使用することもできます。詳細については、[「IAM ロール」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を参照してください。

   E メールメッセージを第 2 の要素として使用し、Amazon Simple Email Service (Amazon SES) で E メールメッセージに使用する送信元 ID を設定していない場合は、コンソールで作成します。**[SES で E メールを送信]** オプションを選択する必要があります。ユーザープールの **[認証方法]** メニューで、**[E メール]** を見つけて **[編集]** を選択します。リストの利用可能な検証済み ID から **[送信元の Eメールアドレス]** を選択します。検証済みドメイン (`example.com` など) を選択した場合は、検証済みドメイン (`admin-noreply@example.com` など) で **[送信者の名前]** も設定する必要があります。

1. **[Save changes]** (変更の保存) をクリックします。

# SMS メッセージ MFA と E メールメッセージ MFA
<a name="user-pool-settings-mfa-sms-email-message"></a>

SMS MFA メッセージと E メールの MFA メッセージは、サインインする前にユーザーがメッセージの宛先にアクセスできることを確認します。パスワードだけでなく、元のユーザーの SMS メッセージまたは E メールの受信トレイにもアクセスできることを確認します。Amazon Cognito は、ユーザーがユーザー名とパスワードを正常に提供した後にユーザープールが送信した短いコードを提供するようユーザーに要求します。

ユーザーがプロファイルに E メールアドレスまたは電話番号を追加すると、SMS メッセージ MFA および E メールメッセージ MFA に追加の設定は必要ありません。Amazon Cognito は、未検証の E メールアドレスと電話番号にメッセージを送信できます。ユーザーが最初の MFA を完了すると、Amazon Cognito は、その E メールアドレスまたは電話番号を検証済みとしてマークします。

MFA 認証は、MFA を持つユーザーがアプリケーションにユーザー名とパスワードを入力したときに開始されます。アプリケーションは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) API リクエストまたは [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) API リクエストを呼び出す SDK メソッドでこれらの初期パラメータを送信します。API レスポンスの `ChallengeParameters` には、認証コードが送信された場所を示す `CODE_DELIVERY_DESTINATION` 値が含まれます。アプリケーションで、ユーザーに電話を確認するよう求め、かつコードの入力要素を含めたフォームを表示します。コードを入力したら、チャレンジレスポンス API リクエストでコードを送信してサインインプロセスを完了します。

MFA を持つユーザーが[マネージドログイン](cognito-user-pools-managed-login.md)ページでユーザー名とパスワードを使用してサインインすると、ユーザーは MFA コードを入力するよう自動的に求められます。

ユーザープールは、 AWS アカウントの Amazon Simple Notification Service (Amazon SNS) リソースを使用して、MFA およびその他の Amazon Cognito 通知に関して SMS メッセージを送信します。同様に、ユーザープールは、アカウントの Amazon Simple Email Service (Amazon SES) リソースを使用して E メールメッセージを送信します。これらのリンクされたサービスでは、メッセージ配信の AWS 請求書に独自のコストが発生します。また、本番稼働ボリュームでメッセージを送信するための追加要件もあります。詳細については、以下のリンクを参照してください。
+ [Amazon Cognito ユーザープール用の SMS メッセージ設定](user-pool-sms-settings.md)
+ [ワールドワイド SMS 料金](https://aws.amazon.com/sns/sms-pricing/)
+ [Amazon Cognito ユーザープールの E メール設定](user-pool-email.md)
+ [Amazon SES の価格設定](https://aws.amazon.com/ses/pricing)

## SMS メッセージ MFA と E メールメッセージ MFA に関する考慮事項
<a name="user-pool-settings-mfa-sms-email-message-considerations"></a>
+ ユーザーに E メール MFA でのサインインを許可するには、ユーザープールに次の設定オプションが必要です。

  1. ユーザープールにプラス機能プランまたはエッセンシャル機能プランがある。詳細については、「[ユーザープールの機能プラン](cognito-sign-in-feature-plans.md)」を参照してください。

  1. ユーザープールは、独自の Amazon SES リソースを使用して E メールメッセージを送信する。詳細については、「[Amazon SES の E メール設定](user-pool-email.md#user-pool-email-developer)」を参照してください。
+ MFA コードは、アプリケーションクライアントで設定した**認証フローセッションの持続期間**の間有効です。

  認証フローセッションの持続期間は、Amazon Cognito コンソールの **[アプリケーションクライアント]** メニューで、アプリケーションクライアントを**編集**するときに設定します。`CreateUserPoolClient` または `UpdateUserPoolClient` API リクエストで認証フローセッション持続期間を設定することも可能です。詳細については、「[認証セッションの例](authentication.md#amazon-cognito-user-pools-authentication-flow)」を参照してください。
+ 検証されていない電話番号または E メールアドレスに Amazon Cognito が送信した SMS または E メールメッセージからユーザーがコードを正常に提供すると、Amazon Cognito は、対応する属性を検証済みとしてマークします。
+ MFA に関連付けられた電話番号または E メールアドレスの値に対してユーザーがセルフサービスで変更を加えるには、サインインしたうえでアクセストークンを使用してリクエストを認可する必要があります。現在の電話番号または E メールアドレスにアクセスできない場合は、サインインできません。チームは、[AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) API リクエストで管理者 AWS 認証情報を使用してこれらの値を変更する必要があります。
+ ユーザープールで [SMS を設定](user-pool-sms-settings.md)した後は、使用できる MFA 要素として SMS メッセージを無効にすることはできません。

# TOTP ソフトウェアトークン MFA
<a name="user-pool-settings-mfa-totp"></a>

ユーザープールで TOTP ソフトウェアトークン MFA を設定すると、ユーザーはユーザー名とパスワードでサインインし、TOTP を使用して認証を完了します。ユーザーがユーザー名とパスワードを設定して検証した後、MFA の TOTP ソフトウェアトークンを有効化できます。アプリケーションでユーザーのサインインに Amazon Cognito のマネージドログインを使用する場合、ユーザーはユーザー名とパスワードを送信し、別のサインインページで TOTP パスワードを送信します。

ユーザープールの TOTP MFA は、Amazon Cognito コンソールでアクティブ化することも、Amazon Cognito API オペレーションを使用してもかまいません。ユーザープールレベルでは、[SetUserPoolMfaConfig](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserPoolMfaConfig.html) を呼び出すことで、MFA を設定して TOTP MFA を有効化できます。

**注記**  
TOTP ソフトウェアトークン MFA がユーザープールに対して有効になっていない場合は、Amazon Cognito で、ユーザーをトークンに関連付けたり、トークンで検証することができません。この場合、ユーザーは`SoftwareTokenMFANotFoundException`説明による例外`Software Token MFA has not been enabled by the userPool`を受診します。ソフトウェアトークン MFA が後にユーザープールに対して非アクティブ化された場合、以前に TOTP トークンを関連付けて検証したユーザーは、引き続き MFA で使用することができます。

ユーザーの TOTP の設定には複数のステップが伴います。ユーザーはシークレットコードを受け取り、ワンタイムパスワードを入力して、このコードを検証します。次に、ユーザーの TOTP MFA を有効にするか、ユーザーの優先 MFA メソッドとして TOTP を設定することができます。

ユーザープールで TOTP MFA を必須に設定した場合、ユーザーがマネージドログインでアプリケーションにサインアップするときに、Amazon Cognito はユーザープロセスを自動化します。Amazon Cognito は、ユーザーに MFA メソッドの選択を促し、Authenticator アプリケーションを設定するための QR コードを表示し、MFA 登録を確認します。ユーザーが SMS と TOTP MFA のどちらかを選択できるようにしたユーザープールでは、Amazon Cognito もユーザーに選択肢を提示します。

**重要**  
ユーザープールに関連付けられた AWS WAF ウェブ ACL があり、ウェブ ACL のルールが CAPTCHA を提示すると、マネージドログイン TOTP 登録で回復不可能なエラーが発生する可能性があります。CAPTCHA アクションを含み、マネージドログインの TOTP には影響しないルールを作成するには、「[マネージドログイン TOTP MFA 用の AWS WAF ウェブ ACL の設定](#totp-waf)」を参照してください。 AWS WAF ウェブ ACL と Amazon Cognito の詳細については、「[AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)」を参照してください。

 AWS SDK と [Amazon Cognito ユーザープール API を使用してカスタムビルド UI に TOTP MFA を実装するには、](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html)「」を参照してください[ユーザーの TOTP MFA の設定](#totp-mfa-set-up-api)。

MFA をユーザープールに追加するには、「[ユーザープールに MFA を追加します](user-pool-settings-mfa.md)」を参照してください。

**TOTP MFA 考慮事項と制約事項**

1. Amazon Cognito は、TOTP コードを生成する Authenticator アプリケーションを介してソフトウェアトークン MFA をサポートします。Amazon Cognito はハードウェアベースの MFA をサポートしていません。

1. TOTP を設定していないユーザーに対してユーザープールが TOTP を必要とする場合、ユーザーはワンタイムアクセストークンを受け取り、アプリはそれを使ってユーザーの TOTP MFA を有効化することができます。後続のサインイン試行は、ユーザーが追加の TOTP サインイン要素を登録するまで失敗します。
   + ユーザーが `SignUp` API オペレーションまたはマネージドログインを使用してユーザープールにサインアップすると、サインアップを完了したときに 1 回限りのトークンを受け取ります。
   + ユーザーを作成し、ユーザーが初期パスワードを設定すると、Amazon Cognito はマネージドログインからユーザーに 1 回限りのトークンを発行します。ユーザーに永続的なパスワードを設定すると、ユーザーが最初にサインインしたときに Amazon Cognito が 1 回限りのトークンを発行します。
   + Amazon Cognito は、[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) API オペレーションでサインインする管理者が作成したユーザーには 1 回限りのトークンを発行しません。ユーザーが初期パスワードの設定のチャレンジに成功した後、またはユーザーに永続的なパスワードを設定すると、Amazon Cognito はすぐに MFA の設定をユーザーに要求します。

1. MFA を必須としているユーザープールのユーザーは、ワンタイムアクセストークンを既に受け取っていても、TOTP MFA を設定していない場合、MFA を設定するまでマネージドログインでサインインできません。アクセストークンの代わりに、[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) に対する `MFA_SETUP` チャレンジの `session` レスポンス値を、[AssociateSoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AssociateSoftwareToken.html) リクエストで使用できます。

1. ユーザーが TOTP を設定した場合は、TOTP が後でユーザープールに対して無効にされた場合でも、その TOTP を MFA に使用できます。

1. Amazon Cognito は、HMAC-SHA1 ハッシュ関数を使用してコードを生成する認証アプリケーションからの TOTP のみを受け入れます。SHA-256 ハッシュで生成されたコードは `Code mismatch` エラーを返します。

## ユーザーの TOTP MFA の設定
<a name="totp-mfa-set-up-api"></a>

ユーザーが最初にサインインすると、アプリはワンタイムアクセストークンを使用して TOTP プライベートキーを生成し、テキスト形式または QR コード形式でユーザーに提示します。ユーザーは Authenticator アプリケーションを設定し、その後のサインイン試行の TOTP を提供します。アプリケーションまたはマネージドログインは、この TOTP を MFA チャレンジレスポンスで TOTP を Amazon Cognito に提示します。

状況によっては、マネージドログインにより、新規ユーザーに TOTP Authenticator を設定するように求めます。詳細については、「[ユーザー実行時の MFA ロジックの詳細](user-pool-settings-mfa.md#user-pool-settings-mfa-user-outcomes)」を参照してください。

**Topics**
+ [TOTP ソフトウェアトークンを関連付ける](#user-pool-settings-mfa-totp-associate-token)
+ [TOTP トークンを検証](#user-pool-settings-mfa-totp-verification)
+ [TOTP MFA でのサインイン](#user-pool-settings-mfa-totp-sign-in)
+ [TOTP トークンを削除](#user-pool-settings-mfa-totp-remove)

### TOTP ソフトウェアトークンを関連付ける
<a name="user-pool-settings-mfa-totp-associate-token"></a>

TOTP トークンを関連付けるには、ワンタイムパスワードで検証する必要のあるシークレットコードをユーザーに送信する必要があります。トークンの関連付けには 3 つのステップが必要です。

1. ユーザーが TOTP ソフトウェアトークン MFA を選択したら、[AssociateSoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AssociateSoftwareToken.html) を呼び出して、一意に生成された共有シークレットキーコードをユーザーアカウントに返します。AssociateSoftwareToken は、アクセストークンまたはセッション文字列を使用して承認できます。

1. アプリは、プライベートキーまたはプライベートキーから生成した QR コードをユーザーに提示します。ユーザーは、Google Authenticator などの TOTP 生成アプリにプライベートキーを入力する必要があります。入力するには、アプリケーションでプライベートキーから生成した QR コードをスキャンするか、手動で入力します。

1. ユーザーがキーを入力するか、Google Authenticator などの認証システムアプリケーションに QR コードをスキャンすると、アプリがコードの生成を開始します。

### TOTP トークンを検証
<a name="user-pool-settings-mfa-totp-verification"></a>

次に、TOTP トークンを検証します。以下のように、ユーザーからサンプルコードをリクエストし、Amazon Cognito サービスに提供して、ユーザーが TOTP コードを正常に生成していることを確認します。

1. アプリは、ユーザーが認証システムアプリケーションを適切に設定したことを示すコードの入力をユーザーに促します。

1. ユーザーの認証システムアプリケーションは、一時的なパスワードを表示します。認証システムアプリケーションは、ユーザーに与えたシークレットキーに基づいてパスワードを作成します。

1. ユーザーは一時パスワードを入力します。アプリは、`[VerifySoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifySoftwareToken.html)` API リクエストで一時パスワードを Amazon Cognito に渡します。

1.  Amazon Cognito は、ユーザーに関連付けられたシークレットキーを保持し、TOTP を生成し、ユーザーが指定したシークレットキーと比較します。一致した場合は、`VerifySoftwareToken` は `SUCCESS` レスポンスを返します。

1. Amazon Cognito は TOTP 要素をユーザーに関連付けます。

1. `VerifySoftwareToken` オペレーションが `ERROR` レスポンスを返した場合は、ユーザーのクロックが正しいこと、およびリトライの最大回数を超えていないことを確認します。Amazon Cognito は、試行の前後 30 秒以内の TOTP トークンを受け入れ、マイナークロックスキューを考慮します。問題が解決したら、VerifySoftwareToken オペレーションをもう一度試してください。

### TOTP MFA でのサインイン
<a name="user-pool-settings-mfa-totp-sign-in"></a>

この時点で、ユーザーは時間ベースのワンタイムパスワードを使用したサインインを行います。以下はその手順です。

1. ユーザーはユーザー名とパスワードを入力してクライアントアプリにサインインします。

1. TOTP MFA チャレンジが呼び出され、アプリが一時パスワードを入力するプロンプトをユーザーに表示します。

1. ユーザーは、関連付けられた TOTP 生成アプリから一時パスワードを取得します。

1. ユーザーが TOTP コードをクライアントアプリに入力します。アプリは、コードを検証するよう Amazon Cognito サービスに通知します。サインインごとに、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) を呼び出して新しい TOTP 認証チャレンジに対するレスポンスを取得する必要があります。

1. Amazon Cognito によってトークンが検証されると、サインインが成功し、ユーザーは認証フローを続行します。

### TOTP トークンを削除
<a name="user-pool-settings-mfa-totp-remove"></a>

最後に、アプリは TOTP 設定を非アクティブ化することをユーザーに許可する必要があります。現在、ユーザーの TOTP ソフトウェアトークンを削除することはできません。ユーザーのソフトウェアトークンを置き換えるには、新しいソフトウェアトークンを関連付けて検証します。ユーザーの TOTP MFA を無効にするには、[SetUserMFAPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserMFAPreference.html) を呼び出して、MFA を使用しないか、SMS MFA のみを使用するようにユーザーを変更します。

1. MFA をリセットしたいユーザーのためのインターフェイスをアプリケーション内に作成します。このインターフェイスでユーザーにパスワードの入力を求めます。

1. Amazon Cognito が TOTP MFA チャレンジを返す場合は、ユーザーの MFA 設定を [SetUserMFAPreference](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetUserMFAPreference.html) で更新します。

1. アプリで、MFA を非アクティブ化したことをユーザーに伝え、再度サインインするよう促します。

## マネージドログイン TOTP MFA 用の AWS WAF ウェブ ACL の設定
<a name="totp-waf"></a>

ユーザープールに関連付けられた AWS WAF ウェブ ACL があり、ウェブ ACL のルールが CAPTCHA を示している場合、マネージドログイン TOTP 登録で回復不可能なエラーが発生する可能性があります。 AWS WAF CAPTCHA ルールは、マネージドログインとクラシックホスト UI の TOTP MFA *にのみ*この効果があります。SMS MFA は影響を受けません。

CAPTCHA ルールにより、ユーザーが TOTP MFA の設定を完了できない場合、Amazon Cognito は次のエラーを表示します。

Request not allowed due to WAF captcha. (WAF captcha によりリクエストは許可されていません。)

このエラーは、 がユーザープールがバックグラウンドで行う [AssociateSoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AssociateSoftwareToken.html) および [VerifySoftwareToken](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_VerifySoftwareToken.html) API リクエストに応答して CAPTCHA AWS WAF をプロンプトすると発生します。CAPTCHA アクションを含み、マネージドログインページの TOTP に影響しないルールを作成するには、ルール内の CAPTCHA アクションから `AssociateSoftwareToken` と `VerifySoftwareToken` の `x-amzn-cognito-operation-name` ヘッダー値を除外します。

次のスクリーンショットは、`x-amzn-cognito-operation-name`ヘッダー値が `AssociateSoftwareToken`または でないすべてのリクエストに CAPTCHA アクションを適用する AWS WAF ルールの例を示しています`VerifySoftwareToken`。

![\[または のx-amzn-cognito-operation-nameヘッダー値を持たないすべてのリクエストに CAPTCHA AssociateSoftwareToken アクションを適用する AWS WAF ルールのスクリーンショットVerifySoftwareToken。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-WAF-rule-TOTP.png)


 AWS WAF ウェブ ACLs「」を参照してください[AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)。 Amazon Cognito

# 脅威保護を備えた高度なセキュリティ
<a name="cognito-user-pool-settings-threat-protection"></a>

ユーザープールを作成すると、Amazon Cognito コンソールのナビゲーションメニューで **[脅威保護]** にアクセスできます。脅威保護機能をオンにして、さまざまなリスクに応じて実行されるアクションをカスタマイズできます。また、監査モードを使用して、セキュリティ緩和策を適用せずに、検出されたリスクに関するメトリクスを収集できます。監査モードの場合、脅威保護は Amazon CloudWatch にメトリクスを発行します。Amazon Cognito が脅威保護の最初のイベントを生成すると、メトリクスを確認できます。「[脅威保護メトリクスの表示](metrics-for-cognito-user-pools.md#user-pool-settings-viewing-threat-protection-metrics)」を参照してください。

脅威保護 (以前は*高度なセキュリティ機能*と呼ばれていました) は、ユーザープール内の望ましくないアクティビティをモニタリングするツールと、潜在的に悪意のあるアクティビティを自動的にシャットダウンする設定ツールのセットです。脅威保護には、標準認証オペレーション用とカスタム認証オペレーション用の異なる設定オプションがあります。例えば、追加のセキュリティ要素を設定済みのカスタム認証で、疑わしいサインインを使用したユーザーに通知を送信するが、基本的なユーザー名/パスワード認証を使用した同じリスクレベルのユーザーをブロックする場合などです。

脅威保護は、プラス機能プランで利用できます。詳細については、「[ユーザープールの機能プラン](cognito-sign-in-feature-plans.md)」を参照してください。

以下のユーザープールオプションは、脅威保護のコンポーネントです。

**漏えいした認証情報**  
ユーザーは複数のユーザーアカウントのパスワードを再利用します。Amazon Cognito の認証情報漏えい機能では、ユーザー名とパスワードの公開漏えいに関するデータを収集し、ユーザーの認証情報を漏えいした認証情報のリストと比較します。漏えいした認証情報の検出では、よく推測されるパスワードもチェックされます。ユーザープールのユーザー名とパスワードの標準認証フローで、漏えいした認証情報を確認できます。Amazon Cognito は、セキュアリモートパスワード (SRP) またはカスタム認証で漏えいした認証情報を検出しません。  
漏えいした認証情報の確認を促すユーザーアクションと、それに応じて Amazon Cognito に実行してほしいアクションを選択できます。サインイン、サインアップ、パスワード変更のイベントでは、Amazon Cognito は**サインインをブロック**するか、**サインインを許可**することができます。どちらの場合も、Amazon Cognito はユーザーアクティビティログを生成し、そこでイベントに関する詳細情報を確認できます。  
**詳細情報**  
[漏えいした認証情報の検出の使用](cognito-user-pool-settings-compromised-credentials.md)

**アダプティブ認証**  
Amazon Cognito は、ユーザーのサインインリクエストから位置情報とデバイス情報を確認し、自動応答を適用してユーザープールのユーザーアカウントを疑わしいアクティビティから保護します。ユーザーアクティビティをモニタリングし、ユーザー名パスワードと SRP、カスタム認証で検出されたリスクレベルへの応答を自動化できます。  
脅威保護を有効にすると、Amazon Cognito はユーザーアクティビティにリスクスコアを割り当てます。疑わしいアクティビティには自動応答を割り当てることができます。たとえば、**MFA を義務付けたり**、**ログインをブロックしたり**、アクティビティの詳細とリスクスコアを記録したりできます。また、疑わしいアクティビティをユーザーに通知する E メールメッセージを自動的に送信して、ユーザーがパスワードのリセットやその他の自発的なアクションを実行できるようにすることもできます。  
**詳細情報**  
[アダプティブ認証の使用](cognito-user-pool-settings-adaptive-authentication.md)

**IP アドレスの許可リストと拒否リスト**  
Amazon Cognito の脅威保護を **[フル機能]** モードで使用することで、IP アドレスの **[常にブロック]** と **[常に許可]** の例外を作成できます。**常にブロック** 例外リストの IP アドレスからのセッションは、アダプティブ認証によってリスクレベルが割り当てられておらず、ユーザープールにサインインできません。  

**IP アドレスの許可リストとブロックリストについて知っておくべきこと**
+ **[常にブロック]** と **[常に許可]** は CIDR 形式で示す必要があります。例えば、24 ビットマスクを `192.0.2.0/24`、単一の IP アドレスを `192.0.2.252/32` で示します。
+  **[常にブロック]** する IP 範囲の IP アドレスを持つデバイスは、SDK ベースやマネージドログインのアプリケーションを使用してサインアップまたはサインインできませんが、サードパーティの IdP を使用してサインインできます。
+ **[常に許可]** と **[常にブロック]** のリストはトークンの更新には影響しません。
+ Amazon Cognito は、**[常に許可]** する IP 範囲のデバイスにアダプティブ認証 MFA ルールを適用しませんが、漏えいした認証情報のルールを適用します。

**ログのエクスポート**  
脅威保護は、ユーザープールに対するユーザーの認証リクエストの詳細なログを記録します。これらのログには、脅威評価、ユーザー情報、ロケーションやデバイスなどのセッションメタデータが含まれます。これらのログについて、保持と分析のための外部アーカイブを作成できます。Amazon Cognito ユーザープールは、脅威保護ログを Amazon S3、CloudWatch Logs、Amazon Data Firehose にエクスポートします。詳細については、「[ユーザーイベント履歴の表示とエクスポート](cognito-user-pool-settings-adaptive-authentication.md#user-pool-settings-adaptive-authentication-event-user-history)」を参照してください。  
**詳細情報**  
[脅威保護ユーザーアクティビティログのエクスポート](exporting-quotas-and-usage.md#exporting-quotas-and-usage-user-activity)

**Topics**
+ [脅威保護に関する考慮事項と制限事項](#cognito-user-pool-threat-protection-considerations)
+ [ユーザープールで脅威保護を有効にする](#cognito-user-pool-threat-protection-activating)
+ [脅威保護の強制適用の概念](#cognito-user-pool-settings-threat-protection-threat-protection-enforcement)
+ [標準認証とカスタム認証の脅威保護](#cognito-user-pool-settings-threat-protection-threat-protection-types)
+ [脅威保護の前提条件](#cognito-user-pool-threat-protection-prerequisites)
+ [脅威保護の設定](#cognito-user-pool-settings-configure-threat-protection)
+ [漏えいした認証情報の検出の使用](cognito-user-pool-settings-compromised-credentials.md)
+ [アダプティブ認証の使用](cognito-user-pool-settings-adaptive-authentication.md)
+ [アプリケーションにおける脅威保護のためのデータ収集](user-pool-settings-viewing-threat-protection-app.md)

## 脅威保護に関する考慮事項と制限事項
<a name="cognito-user-pool-threat-protection-considerations"></a>

**脅威保護オプションは認証フローによって異なる**  
Amazon Cognito は、アダプティブ認証と、認証フローの `USER_PASSWORD_AUTH` と `ADMIN_USER_PASSWORD_AUTH` による漏えいした認証情報の検出の両方をサポートしています。`USER_SRP_AUTH` のアダプティブ認証のみを有効にできます。フェデレーティッドサインインでは脅威保護を使用できません。

**常にブロックする IP はリクエストクォータにカウントされる**  
ユーザープールの **常にブロック** 例外リストの IP アドレスからのブロックされたリクエストは、ユーザープールの[リクエストレートクォータ](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#category_operations) に貢献します。

**脅威保護にはレート制限は適用されない**  
一部の悪意のあるトラフィックは、分散型サービス拒否 (DDoS) 攻撃など、大量のリクエストの特徴を持っています。Amazon Cognito が受信トラフィックに適用するリスク評価はリクエストごとに行われるため、リクエストボリュームは考慮されません。大量のイベント内における個々のリクエストは、大量攻撃でのロールに関連しないアプリケーションレイヤーの理由で、リスクスコアと自動レスポンスを受け取る場合があります。ユーザープールにボリューメトリック攻撃に対する防御を実装するには、 AWS WAF ウェブ ACLs を追加します。詳細については、「[AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)」を参照してください。

**脅威保護は M2M リクエストには影響しません**  
クライアント認証情報の付与は、ユーザーアカウントに接続しないマシンツーマシン (M2M) 認可を目的としています。脅威保護は、ユーザープール内のユーザーアカウントとパスワードのみをモニタリングします。M2M アクティビティでセキュリティ機能を実装するには、リクエストレートとコンテンツをモニタリング AWS WAF するための の機能を検討してください。詳細については、「[AWS WAF ウェブ ACL をユーザープールに関連付ける](user-pool-waf.md)」を参照してください。

## ユーザープールで脅威保護を有効にする
<a name="cognito-user-pool-threat-protection-activating"></a>

------
#### [ Amazon Cognito user pools console ]

**ユーザープールで脅威保護を有効にするには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. まだ有効にしていない場合は、**[設定]**メニューからプラス機能プランを有効にします。

1. **[脅威保護]** メニューを選択し、**[アクティブ化]** を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ API ]

[CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストで、機能プランをプラスに設定します。次のリクエスト本文の部分的な例では、脅威保護をフル機能モードに設定しています。完全なリクエストの例については、「[例](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html#API_CreateUserPool_Examples)」を参照してください。

```
"UserPoolAddOns": { 
      "AdvancedSecurityMode": "ENFORCED"
   }
```

------

脅威保護は、アカウント乗っ取りの兆候がないかについてユーザーオペレーションをモニタリングし、影響を受けるユーザーアカウントのセキュリティ保護に自動的に応答する機能の集合語です。脅威保護設定は、ユーザーが標準認証フローとカスタム認証フローでサインインするときに適用できます。

脅威保護は、ユーザーのサインイン、サインアウト、その他のアクティビティを詳細に記録する[ログを生成](cognito-user-pool-settings-adaptive-authentication.md#user-pool-settings-adaptive-authentication-event-user-history)します。これらのログは、サードパーティーのシステムにエクスポートできます。詳細については、「[ユーザーイベント履歴の表示とエクスポート](cognito-user-pool-settings-adaptive-authentication.md#user-pool-settings-adaptive-authentication-event-user-history)」を参照してください。

## 脅威保護の強制適用の概念
<a name="cognito-user-pool-settings-threat-protection-threat-protection-enforcement"></a>

脅威保護は、ユーザープールがユーザーアクティビティをモニタリングし、リスクレベルを割り当て、ログを生成する*監査のみ*モードで開始されます。ベストプラクティスとして、*フル機能モード*を有効にする前に、監査のみモードで 2 週間以上実行します。フル機能モードには、検出された危険なアクティビティと漏えいしたパスワードに対する一連の自動応答が含まれます。監査のみモードでは、Amazon Cognito が実行している脅威評価をモニタリングできます。また、擬陽性と陰性について機能をトレーニングする[フィードバックを提供](cognito-user-pool-settings-adaptive-authentication.md#user-pool-settings-adaptive-authentication-feedback)することもできます。

ユーザープールレベル、および個々のアプリケーションクライアントのレベルで、すべてのアプリケーションクライアントをカバーするように脅威保護の強制適用を設定できます。アプリケーションクライアント脅威保護の設定は、ユーザープールの設定を上書きします。アプリケーションクライアントで脅威保護を設定するには、Amazon Cognito コンソールでユーザープールの **[アプリケーションクライアント]** メニューのアプリケーションクライアント設定に移動します。そこでは、**[クライアントレベルの設定を使用]** により、アプリケーションクライアント専用の強制適用を設定できます。

さらに、標準認証タイプとカスタム認証タイプに対して脅威保護を個別に設定できます。

## 標準認証とカスタム認証の脅威保護
<a name="cognito-user-pool-settings-threat-protection-threat-protection-types"></a>

脅威保護を設定する方法は、ユーザープールとアプリケーションクライアントで実行している認証のタイプによって異なります。以下の各タイプの認証には、独自の強制適用モードと自動応答を使用できます。

**標準認証**  
*[標準認証]* は、ユーザー名パスワードフローとマネージドログインを使用したユーザーのサインイン、サインアウト、パスワード管理です。Amazon Cognito の脅威保護は、ユーザーがマネージドログインでサインインするときや、以下の API `AuthFlow` パラメータを使用するときに、オペレーションをモニタリングしてリスクの兆候がないか確認します。    
**[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-AuthFlow)**  
`USER_PASSWORD_AUTH`、`USER_SRP_AUTH`。漏えいした認証情報機能は、`USER_SRP_AUTH` サインイン時のパスワードにアクセスできず、このフローを用いてイベントのモニタリングや、イベントに対するアクションを行いません。  
**[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-AuthFlow)**  
`ADMIN_USER_PASSWORD_AUTH`、`USER_SRP_AUTH`。漏えいした認証情報機能は、`USER_SRP_AUTH` サインイン時のパスワードにアクセスできず、このフローを用いてイベントのモニタリングや、イベントに対するアクションを行いません。
標準認証の **[強制適用モード]** を **[監査のみ]** または **[フル機能]** に設定できます。標準認証の脅威モニタリングを無効にするには、脅威保護を **[強制適用なし]** に設定します。

**カスタム認証**  
*カスタム認証*は、[カスタムチャレンジ Lambda トリガー](user-pool-lambda-challenge.md)によるユーザーサインインです。マネージドログインではカスタム認証を実行できません。Amazon Cognito 脅威保護は、`InitiateAuth` および `AdminInitiateAuth` の API `AuthFlow` パラメータ `CUSTOM_AUTH` を使用してサインインするときに、リスクの指標についてオペレーションをモニタリングします。  
カスタム認証の **[強制適用モード]** は、**[監査のみ]**、**[フル機能]**、または **[強制適用なし]** に設定できます。**[強制適用なし]** オプションは、脅威保護の他の機能に影響を与えることなく、カスタム認証の脅威モニタリングを無効にします。

## 脅威保護の前提条件
<a name="cognito-user-pool-threat-protection-prerequisites"></a>

開始するには、以下が必要です。
+ アプリクライアントを持つユーザープール。詳細については、「[ユーザープールの開始方法](getting-started-user-pools.md)」を参照してください。
+ Amazon Cognito コンソールで多要素認証 (MFA) を **[Optional]** (オプション) に設定して、リスクに基づくアダプティブ認証機能を使用する。詳細については、「[ユーザープールに MFA を追加します](user-pool-settings-mfa.md)」を参照してください。
+ 通知に E メールを使用している場合は、[Amazon SES コンソール](https://console.aws.amazon.com/ses/home)に移動して、通知 E メールで使用する E メールアドレスまたはドメインの設定と検証を実行します。Amazon SES の詳細については、「[Amazon SES での ID の検証](https://docs.aws.amazon.com/ses/latest/dg/verify-addresses-and-domains.html)」を参照してください。

## 脅威保護の設定
<a name="cognito-user-pool-settings-configure-threat-protection"></a>

ユーザープールの脅威保護を設定するには、次の手順に従います。

**注記**  
Amazon Cognito ユーザープールコンソールでアプリケーションクライアント別の脅威保護設定をセットアップするには、**[アプリケーションクライアント]** メニューでアプリケーションクライアントを選択し、**[クライアントレベルの設定を使用]** を選択します。

------
#### [ AWS マネジメントコンソール ]

**ユーザープールの脅威保護を設定するには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[脅威保護]** メニューを選択し、**[アクティブ化]** を選択します。

1. 設定する脅威保護方法を、**標準認証とカスタム認証**から選択します。カスタム認証と標準認証にはさまざまな強制適用モードを設定できますが、それらは**フル機能**モードでの自動応答の設定を共有します。

1. **[Edit]** (編集) を選択します。

1. **[強制適用モード]** を選択します。検出されたリスクへの対応をすぐに開始するには、**[フル機能]** を選択し、漏えいした認証情報とアダプティブ認証への自動レスポンスを設定します。ユーザーレベルのログと CloudWatch で情報を収集するには、**[監査のみ]** を選択します。

   アクションを有効にする前の 2 週間、脅威保護を監査モードにしておくことをお勧めします。この間に、Amazon Cognito は、アプリケーションユーザーの使用パターンを学習でき、イベントフィードバックを提供してレスポンスを調整できます。

1. **[Audit only]** (監査のみ) を選択した場合、**[Save changes]** (変更の保存) を選択してください。**[Full function]** (完全な機能) を選択した場合:

   1. **侵害された認証情報**への応答は、 **[Custom]** (カスタム) アクションの実行または使用、または **[Cognito defaults]** (Cognito デフォルト) を選択します。**Cognito デフォルト**では、

      1. **サインイン**,**サインアップ**, および**パスワードの変更時**に、侵害された認証情報を検出します。

      1. 侵害された認証情報は、**[Block sign-in]** (サインインをブロックする) で応答します。

   1. **[漏えいした認証情報]** で **[カスタム]** アクションを選択した場合、Amazon Cognito で **[イベントの検出]** に使用するユーザープールアクションと、Amazon Cognito で実行する **[漏えいした認証情報に関する応答]** を選択します。侵害された認証情報による**サインインをブロック**または**サインインを許可**することができます。

   1. **[Adaptive authentication]** (アダプティブ認証) で、悪意のあるサインイン試行への応答方法を選択します。**[Custom]** (カスタム) アクションを実行または使用、または悪意のあるアクティビティの疑いに対応するために **[Cognito defaults]** (Cognito デフォルト) を選択します。**[Cognito defaults]** (Cognito デフォルト) を選択した場合、Amazon Cognito はすべてのリスクレベルでサインインをブロックし、ユーザーに通知しません。

   1. **[Adaptive authentication]** (アダプティブ認証) で、 **[Custom]** (カスタム) アクションを選択した場合、重要度レベルに基づいて検出されたリスクに対して、Amazon Cognito で実行する **[Automatic risk response]** (自動リスク対応) アクションを選択します。リスクのレベルに応じて対応を割り当てる場合、より高いレベルのリスクに対して、より制限の少ない対応を割り当てることはできません。リスクレベルには、次の対応を割り当てることができます。

      1. **サインインを許可する** - 予防策をとりません。

      1. **MFA のオプション** - ユーザーが MFA を設定している場合、Amazon Cognito はサインイン時に常に SMS またはタイムベースドワンタイムパスワード (TOTP) の追加要素を提供するようユーザーに要求します。ユーザーに MFA が設定されていない場合は、通常どおりサインインを続行できます。

      1. **MFA を要求** - ユーザーが MFA を設定している場合、Amazon Cognito はサインイン時に常に SMS または TOTP ファクターの追加要素の提供を要求します。ユーザーに MFA が設定されていない場合、Amazon Cognito は MFA を設定するよう促します。ユーザーに MFA を自動要求する前に、SMS MFA の電話番号をキャプチャするメカニズム、または TOTP MFA の認証アプリケーションを登録するメカニズムを、お客様のアプリケーションに設定してください。

      1. **サインインをブロックする** - ユーザーがサインインできないようにします。

      1. **ユーザーに通知する** - Amazon Cognito が検出したリスクと応答に関する情報を E メールでユーザーに送信します。送信するメッセージの E メールメッセージテンプレートをカスタマイズできます。

1. 前の手順で **[Notify user]** (ユーザーに通知する) を選択した場合、アダプティブ認証に使用する E メール配信設定と E メールメッセージテンプレートをカスタマイズできます。

   1. **[E メール設定]** で、アダプティブ認証に使用する **[SES リージョン]**、**[送信元の E メールアドレス]**、**[送信者の名前]**、**[返信先 E メールアドレス]** を選択します。ユーザープールの E メールメッセージを Amazon Simple Email Service の統合方法の詳細については、「[Amazon Cognito ユーザープールに使用する E メールの設定](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-email.html)」を参照してください。  
![\[ユーザーイベント履歴\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-advanced-security-ses-notification.png)

   1. **[Email templates]** (E メールテンプレート) を展開して、E メールメッセージの HTML とプレーンテキストバージョンの両方でアダプティブ認証通知をカスタマイズします。E メールメッセージテンプレートの詳細については、「[メッセージテンプレート](cognito-user-pool-settings-message-customizations.md#cognito-user-pool-settings-message-templates)」を参照してください。

1. **[IP アドレスの例外]** を展開して、脅威保護のリスク評価に関係なく、常に許可またはブロックする IPv4 または IPv6 アドレス範囲の **[常に許可]** または **[常にブロック]** のリストを作成します。[CIDR 表記](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation) で IP アドレスの範囲を指定します (例: 192.168.100.0/24)。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ API (user pool) ]

ユーザープールの脅威保護を設定するには、`UserPoolId` パラメータを含むが、`ClientId` パラメータを含まない [SetRiskConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetRiskConfiguration.html) API リクエストを送信します。ユーザープール用のリクエスト本文の例を次に示します。このリスク設定は、リスクの重大度に基づいて一連のアクションをエスカレートし、すべてのリスクレベルでユーザーに通知します。これは、漏えいした認証情報ブロックをサインアップオペレーションに適用します。

この設定を適用するには、別の [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストの `ENFORCED` に `AdvancedSecurityMode` を設定する必要があります。この例における `{username}` のようなプレースホルダーテンプレートの詳細については、「[MFA、認証、検証、招待メッセージの設定](cognito-user-pool-settings-message-customizations.md)」を参照してください。

```
{
   "AccountTakeoverRiskConfiguration": { 
      "Actions": { 
         "HighAction": { 
            "EventAction": "MFA_REQUIRED",
            "Notify": true
         },
         "LowAction": { 
            "EventAction": "NO_ACTION",
            "Notify": true
         },
         "MediumAction": { 
            "EventAction": "MFA_IF_CONFIGURED",
            "Notify": true
         }
      },
      "NotifyConfiguration": { 
         "BlockEmail": { 
            "Subject": "You have been blocked for suspicious activity",
            "TextBody": "We blocked {username} at {login-time} from {ip-address}."
         },
         "From": "admin@example.com",
         "MfaEmail": { 
            "Subject": "Suspicious activity detected, MFA required",
            "TextBody": "Unexpected sign-in from {username} on device {device-name}. You must use MFA."
         },
         "NoActionEmail": { 
            "Subject": "Suspicious activity detected, secure your user account",
            "TextBody": "We noticed suspicious sign-in activity by {username} from {city}, {country} at {login-time}. If this was not you, reset your password."
         },
         "ReplyTo": "admin@example.com",
         "SourceArn": "arn:aws:ses:us-west-2:123456789012:identity/admin@example.com"
      }
   },
   "CompromisedCredentialsRiskConfiguration": { 
      "Actions": { 
         "EventAction": "BLOCK"
      },
      "EventFilter": [ "SIGN_UP" ]
   },
   "RiskExceptionConfiguration": { 
      "BlockedIPRangeList": [ "192.0.2.0/24","198.51.100.0/24" ],
      "SkippedIPRangeList": [ "203.0.113.0/24" ]
   },
   "UserPoolId": "us-west-2_EXAMPLE"
}
```

------
#### [ API (app client) ]

アプリケーションクライアントの脅威保護を設定するには、`UserPoolId` パラメータと `ClientId` パラメータを含む [SetRiskConfiguration](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SetRiskConfiguration.html) API リクエストを送信します。次に、アプリケーションクライアント用のリクエストの本文の例を示します。このリスク設定は、ユーザープール設定よりも重大であり、高リスクのエントリをブロックします。また、漏えいした認証情報ブロックを適用して、サインアップ、サインイン、パスワードリセットの各オペレーションも行います。

この設定を適用するには、別の [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) API リクエストまたは [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) API リクエストの `ENFORCED` に `AdvancedSecurityMode` を設定する必要があります。この例における `{username}` のようなプレースホルダーテンプレートの詳細については、「[MFA、認証、検証、招待メッセージの設定](cognito-user-pool-settings-message-customizations.md)」を参照してください。

```
{
   "AccountTakeoverRiskConfiguration": { 
      "Actions": { 
         "HighAction": { 
            "EventAction": "BLOCK",
            "Notify": true
         },
         "LowAction": { 
            "EventAction": "NO_ACTION",
            "Notify": true
         },
         "MediumAction": { 
            "EventAction": "MFA_REQUIRED",
            "Notify": true
         }
      },
      "NotifyConfiguration": { 
         "BlockEmail": { 
            "Subject": "You have been blocked for suspicious activity",
            "TextBody": "We blocked {username} at {login-time} from {ip-address}."
         },
         "From": "admin@example.com",
         "MfaEmail": { 
            "Subject": "Suspicious activity detected, MFA required",
            "TextBody": "Unexpected sign-in from {username} on device {device-name}. You must use MFA."
         },
         "NoActionEmail": { 
            "Subject": "Suspicious activity detected, secure your user account",
            "TextBody": "We noticed suspicious sign-in activity by {username} from {city}, {country} at {login-time}. If this was not you, reset your password."
         },
         "ReplyTo": "admin@example.com",
         "SourceArn": "arn:aws:ses:us-west-2:123456789012:identity/admin@example.com"
      }
   },
   "ClientId": "1example23456789",
   "CompromisedCredentialsRiskConfiguration": { 
      "Actions": { 
         "EventAction": "BLOCK"
      },
      "EventFilter": [ "SIGN_UP", "SIGN_IN", "PASSWORD_CHANGE" ]
   },
   "RiskExceptionConfiguration": { 
      "BlockedIPRangeList": [ "192.0.2.1/32","192.0.2.2/32" ],
      "SkippedIPRangeList": [ "192.0.2.3/32","192.0.2.4/32" ]
   },
   "UserPoolId": "us-west-2_EXAMPLE"
}
```

------

# 漏えいした認証情報の検出の使用
<a name="cognito-user-pool-settings-compromised-credentials"></a>

Amazon Cognito は、ユーザーのユーザー名とパスワードが他の場所で侵害されたかどうかを検出できます。これは、ユーザーが複数のサイトで認証情報を再利用したり、安全でないパスワードを使用したりするときに発生します。Amazon Cognito は、マネージドログインと Amazon Cognito API で、ユーザー名とパスワードでサインインする[ローカルユーザー](cognito-terms.md#terms-localuser)をチェックします。

Amazon Cognito コンソールの **[脅威保護]** メニューで、**[漏えいした認証情報]** を設定できます。**[Event detection]** (イベント検出) を設定して、侵害された認証情報を監視するユーザーイベントを選択します。**[Compromised credentials responses]** (侵害された認証情報の応答) を設定し、侵害された認証情報が検出された場合にユーザーを許可するかブロックするかを選択します。Amazon Cognito は、サインイン時、サインアップ時、パスワード変更時に侵害された認証情報をチェックすることができます。

**[Allow sign-in]** (サインインを許可する) を選択する場合、Amazon CloudWatch Logs を確認して、Amazon Cognito がユーザーイベントに対して行う評価を監視できます。詳細については、「[脅威保護メトリクスの表示](metrics-for-cognito-user-pools.md#user-pool-settings-viewing-threat-protection-metrics)」を参照してください。**[Block sign-in]** (サインインをブロックする) を選択する場合、Amazon Cognito は、侵害された認証情報を使用するユーザーによるサインインを防止します。Amazon Cognito がユーザーのサインインをブロックすると、ユーザーの [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserType.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserType.html) が `RESET_REQUIRED` に設定されます。`RESET_REQUIRED` ステータスのユーザーは、再度サインインする前にパスワードを変更する必要があります。

漏えいした認証情報では、次のユーザーアクティビティのパスワードをチェックできます。

**サインアップ**  
ユーザープールは、ユーザーが [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html) オペレーションおよびマネージドログインのサインアップページで送信したパスワードをチェックし、漏えいの兆候を確認します。

**サインイン**  
ユーザープールは、ユーザーがパスワードベースのサインインで送信したパスワードをチェックし、漏えいの兆候を確認します。Amazon Cognito は、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) の `ADMIN_USER_PASSWORD_AUTH` フロー、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) の `USER_PASSWORD_AUTH` フロー、および両方の `USER_AUTH` フローの `PASSWORD` オプションを確認できます。  
現在 Amazon Cognito では、Secure Remote Password (SRP) フローでのサインイン操作に対する侵害された認証情報のチェックが行われません。SRP はサインイン時にハッシュ化されたパスワード証明書を送信します。Amazon Cognito は内部でパスワードにアクセスできないため、クライアントがプレーンテキストで渡したパスワードのみを評価できます。

**パスワードのリセット**  
ユーザープールは、セルフサービスのパスワードリセットオペレーション [ConfirmForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html) を使用して、新規ユーザーのパスワードを設定するオペレーションにおける漏えいの兆候をチェックします。このオペレーションに必要なコードは、[ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html) と [AdminResetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html) によって生成されます。  
漏えいした認証情報では、[AdminSetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html) で設定された仮パスワードや永続的な管理者設定パスワードをチェックしません。ただし、仮パスワードの場合、ユーザープールは [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) と [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) で `NEW_PASSWORD_REQUIRED` チャレンジへのレスポンスのパスワードをチェックします。

漏洩した認証情報の保護をユーザープールに追加するには、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。

# アダプティブ認証の使用
<a name="cognito-user-pool-settings-adaptive-authentication"></a>

アダプティブ認証では、リスクレベルの上昇に対応して、疑わしいサインインをブロックする、または 2 番目の要素認証を追加するようにユーザープールを設定できます。Amazon Cognito はサインインの試行ごとに、サインインリクエストが侵害されたソースからのものである可能性についてリスクスコアを生成します。このリスクスコアは、アプリケーションが提供するデバイスとユーザーの要因、および Amazon Cognito がリクエストから派生するその他の要因に基づいています。Amazon Cognito によるリスク評価に影響する要素には、IP アドレスとユーザーエージェント、ユーザーエージェント、および他のサインイン試行からの地理的な距離があります。アダプティブ認証は、Amazon Cognito がユーザーのセッションでリスクを検出し、ユーザーがまだ MFA メソッドを選択していない場合に、ユーザープール内のユーザーに対して多要素認証 (MFA) を有効にする、または多要素認証 (MFA) を要求することができます。ユーザーに MFA を有効にすると、アダプティブ認証の設定方法にかかわらず、認証中に必ず 2 つ目の要素を提供または設定するように求めるチャレンジが常に表示されます。ユーザーの観点から見ると、アプリは MFA の設定を支援し、また、オプションとして、Amazon Cognito では、ユーザーが追加の要素を設定するまで、ユーザーが再度サインインできないようにすることもできます。

Amazon Cognito は、サインイン試行、試行のリスクレベル、および失敗したチャレンジに関するメトリクスを Amazon CloudWatch にパブリッシュします。詳細については、「[脅威保護メトリクスの表示](metrics-for-cognito-user-pools.md#user-pool-settings-viewing-threat-protection-metrics)」を参照してください。

アダプティブ認証をユーザープールに追加するには、「[脅威保護を備えた高度なセキュリティ](cognito-user-pool-settings-threat-protection.md)」を参照してください。

**Topics**
+ [アダプティブ認証の概要](#security-cognito-user-pool-settings-adaptive-authentication-overview)
+ [API リクエストへのユーザーデバイスおよびセッションデータの追加](#user-pool-settings-adaptive-authentication-device-fingerprint)
+ [ユーザーイベント履歴の表示とエクスポート](#user-pool-settings-adaptive-authentication-event-user-history)
+ [イベントフィードバックを提供します](#user-pool-settings-adaptive-authentication-feedback)
+ [通知メッセージの送信](#user-pool-settings-adaptive-authentication-messages)

## アダプティブ認証の概要
<a name="security-cognito-user-pool-settings-adaptive-authentication-overview"></a>

Amazon Cognito コンソールの **[脅威保護]** メニューで、アダプティブ認証の設定を選択できます。これには、リスクレベル別に実行するアクション、ユーザーへの通知メッセージのカスタマイズなどが含まれます。すべてのアプリケーションクライアントにグローバルな脅威保護設定を割り当てる一方、個々のアプリケーションクライアントにはクライアントレベルの設定を適用できます。

Amazon Cognito アダプティブ認証は、各ユーザーセッションに**「高」**、**「中」**、**「低」**、**「リスクなし」**のいずれかのリスクレベルを割り当てます。

**[Enforcement method]** (強制実行メソッド) を **[Audit-only]** (監査専用) から **[Full-function]** (完全な機能) に変更する場合は、選択肢を慎重に検討してください。リスクレベルに適用する自動応答は、Amazon Cognito が同じ特性を持つ後続のユーザーセッションに割り当てるリスクレベルに影響します。例えば、Amazon Cognito が最初にリスクが高いと評価したユーザーセッションに何もしないか、**[Allow]** (許可) を選択すると、Amazon Cognito では同様のセッションのリスクが低いと見なします。


**リスクレベルごとに、以下のオプションから選択できます。**  

|  オプション  |  アクション  | 
| --- | --- | 
| 許可 | ユーザーは、追加要素なしでサインインできます。 | 
| オプションの MFA | 第 2 要素を設定しているユーザーは、サインインするために第 2 要素のチャレンジを完了する必要があります。SMS の電話番号と TOTP ソフトウェアトークンが利用可能な第 2 要素です。2 番目の要素が設定されていないユーザーは、1 つの認証情報のみでサインインできます。 | 
| MFA が必要 | 第 2 要素を設定しているユーザーは、サインインするために第 2 要素のチャレンジを完了する必要があります。Amazon Cognito は、第 2 要素が設定されていないユーザーのサインインをブロックします。 | 
| ブロック | Amazon Cognito は、指定されたリスクレベルですべてのサインイン試行をブロックします。 | 

**注記**  
SMS を 2 番目の認証要素として使用するために電話番号を検証する必要はありません。

## API リクエストへのユーザーデバイスおよびセッションデータの追加
<a name="user-pool-settings-adaptive-authentication-device-fingerprint"></a>

API を使用してユーザーのサインアップ、サインイン、パスワードのリセットを行う際に、ユーザーのセッションに関する情報を収集し、Amazon Cognito の脅威保護に渡すことができます。この情報には、ユーザーの IP アドレスと一意のデバイス識別子が含まれます。

ユーザーと Amazon Cognito の間に、プロキシサービスやアプリケーションサーバーなど、中間ネットワークデバイスがある場合があります。ユーザーのコンテキストデータを収集して Amazon Cognito に渡すことで、アダプティブ認証がサーバーやプロキシではなく、ユーザーエンドポイントの特性に基づいてリスクを計算できます。クライアント側アプリが Amazon Cognito API オペレーションを直接呼び出す場合、アダプティブ認証は送信元 IP アドレスを自動的に記録します。ただし、デバイスのフィンガープリントも収集しない限り、`user-agent` などの他のデバイス情報は記録されません。

このデータを Amazon Cognito コンテキストデータ収集ライブラリで生成して、Amazon Cognito の脅威保護に送信するには、[ContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ContextDataType.html) パラメータと [UserContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserContextDataType.html) パラメータを使用します。コンテキストデータ収集ライブラリは AWS SDKs に含まれています。詳細については、「[Amazon Cognito の認証と認可を、ウェブアプリケーションとモバイルアプリケーションに統合する](cognito-integrate-apps.md)」を参照してください。プラス機能プランを使用している場合は、`ContextData` を送信できます。詳細については、「[脅威保護の設定](cognito-user-pool-settings-threat-protection.md#cognito-user-pool-settings-configure-threat-protection)」を参照してください。

アプリケーションサーバーから以下の Amazon Cognito 認証 API オペレーションを呼び出す場合、`ContextData` パラメータにユーザーのデバイスの IP を渡します。また、サーバー名、サーバーパス、およびエンコードされたデバイスフィンガープリントデータを渡します。
+ [AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html)
+ [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html)

Amazon Cognito の認証されていない API オペレーションを呼び出すと、Amazon Cognito の脅威保護に `UserContextData` を送信できます。このデータには、`EncodedData` パラメータのデバイスフィンガープリントが含まれます。また、次の条件を満たす場合、`UserContextData` に `IpAddress` パラメータを送信できます。
+ ユーザープールをプラス機能プランで使用しています。詳細については、「[ユーザープールの機能プラン](cognito-sign-in-feature-plans.md)」を参照してください。
+ アプリクライアントにはクライアントシークレットがあります。詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。
+ アプリクライアントで **[Accept additional user context data]** (追加のユーザーコンテキストデータを受け入れる) をアクティブ化しました。詳細については、「[追加のユーザーコンテキストデータの受け入れ (AWS マネジメントコンソール)](#user-pool-settings-adaptive-authentication-accept-user-context-data)」を参照してください。

アプリは、以下の Amazon Cognito の認証されていない API オペレーションで、`UserContextData` パラメータにエンコードされたデバイスフィンガープリントデータとユーザーのデバイスの IP アドレスを入力できます。
+ [InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html)
+ [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html)
+ [SignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html)
+ [ConfirmSignUp](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmSignUp.html)
+ [ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html)
+ [ConfirmForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ConfirmForgotPassword.html)
+ [ResendConfirmationCode](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ResendConfirmationCode.html)

### 追加のユーザーコンテキストデータの受け入れ (AWS マネジメントコンソール)
<a name="user-pool-settings-adaptive-authentication-accept-user-context-data"></a>

ユーザープールは **[Accept additional user context data]** (追加のユーザーコンテキストデータを受け入れる) 機能をアクティブ化すると、`UserContextData` パラメータで IP アドレスを受け入れます。次の場合は、この機能をアクティブ化する必要はありません。
+ ユーザーは、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) のような認証された API オペレーションでのみサインインし、`ContextData` パラメータを使用します。
+ 認証されていない API オペレーションから、IP アドレスではなく、デバイスのフィンガープリントのみを Amazon Cognito の脅威保護に送信します。

Amazon Cognito コンソールでアプリクライアントを次のように更新し、追加のユーザーコンテキストデータのサポートを追加します。

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

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

1. **[アプリケーションクライアント]** メニューを選択します。

1. アプリケーションクライアントを選択または作成します。詳細については、「[ユーザープールのアプリクライアントの設定](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-app-idp-settings.html)」を参照してください。

1. **[App client information]** (アプリのクライアント情報) コンテナから **[Edit]** (編集) を選択します。

1. アプリクライアントの **[Advanced authentication settings]** (詳細な認証設定) で、**[Accept additional user context data]** (追加のユーザーコンテキストデータを受け入れる) を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

Amazon Cognito API でユーザーコンテキストデータを受け入れるようにアプリクライアントを設定するには、[CreateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html) または [UpdateUserPoolClient](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) リクエストで `EnablePropagateAdditionalUserContextData` を `true` に設定します。ウェブまたはモバイルアプリで脅威保護を使用する方法については、「[アプリケーションにおける脅威保護のためのデータ収集](user-pool-settings-viewing-threat-protection-app.md)」を参照してください。アプリがサーバーから Amazon Cognito を呼び出すときに、クライアント側からユーザーコンテキストデータを収集します。以下は、JavaScript SDK メソッド `getData` 使用する例です。

```
var EncodedData = AmazonCognitoAdvancedSecurityData.getData(username, userPoolId, clientId);
```

アダプティブ認証を使用するようにアプリを設計する場合は、最新の Amazon Cognito SDK をアプリに組み込むことをお勧めします。SDK の最新バージョンでは、デバイス ID、モデル、およびタイムゾーンなどのデバイスフィンガープリント情報を収集します。Amazon Cognito SDK の詳細については、「[ユーザープール SDK のインストール](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-sdk-links.html)」を参照してください。Amazon Cognito の脅威保護では、アプリケーションが正しい形式で送信したイベントのみを保存し、リスクスコアを割り当てます。Amazon Cognito がエラーレスポンスを返す場合は、リクエストに有効なシークレットハッシュが含まれていることと、`IPaddress` パラメータが、有効な IPv4 または IPv6 アドレスであることを確認します。

**`ContextData` および `UserContextData` リソース**
+ AWS Amplify Android 用 SDK: [GetUserContextData](https://github.com/aws-amplify/aws-sdk-android/blob/main/aws-android-sdk-cognitoidentityprovider/src/main/java/com/amazonaws/mobileconnectors/cognitoidentityprovider/CognitoUserPool.java#L626)
+ AWS Amplify SDK for iOS: [userContextData](https://github.com/aws-amplify/aws-sdk-ios/blob/d3cd4fa0086b526f2f5c9c6c58880c9da7004c66/AWSCognitoIdentityProviderASF/AWSCognitoIdentityProviderASF.m#L21)
+ JavaScript: [amazon-cognito-advanced-security-data.min.js](https://amazon-cognito-assets.us-east-1.amazoncognito.com/amazon-cognito-advanced-security-data.min.js)

## ユーザーイベント履歴の表示とエクスポート
<a name="user-pool-settings-adaptive-authentication-event-user-history"></a>

脅威保護を有効にすると、Amazon Cognito は、ユーザーによる認証イベントごとにログを生成します。デフォルトでは、Amazon Cognito コンソールの **[ユーザー]** メニューまたは [AdminListUserAuthEvents](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminListUserAuthEvents.html) API オペレーションを使用して、ユーザーログを表示できます。また、これらのイベントを、CloudWatch Logs、Amazon S3、Amazon Data Firehose などの外部システムにエクスポートすることもできます。エクスポート機能を使用すると、アプリケーション内のユーザーアクティビティに関するセキュリティ情報について、独自のセキュリティ分析システムにアクセスさせることが容易になります。

**Topics**
+ [ユーザーイベント履歴の表示 (AWS マネジメントコンソール)](#user-pool-settings-adaptive-authentication-event-user-history-console)
+ [ユーザーイベント履歴の表示 (API/CLI)](#user-pool-settings-adaptive-authentication-event-user-history-api-cli)
+ [ユーザー認証イベントのエクスポート](#user-pool-settings-adaptive-authentication-event-user-history-exporting)

### ユーザーイベント履歴の表示 (AWS マネジメントコンソール)
<a name="user-pool-settings-adaptive-authentication-event-user-history-console"></a>

ユーザーのサインイン履歴を表示するには、Amazon Cognito コンソールの **[ユーザー]** メニューでユーザーを選択できます。Amazon Cognito は、ユーザーイベント履歴を 2 年間保持します。

![\[ユーザーイベント履歴\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-advanced-security-event-history.png)


各サインインイベントにはイベント ID があります。イベントには、場所、デバイスの詳細、およびリスク検出結果など、対応するコンテキストデータもあります。

また、イベント ID を Amazon Cognito がイベントを記録した時点で発行したトークンと関連付けることができます。ID とアクセストークンには、ペイロードにこのイベント ID が含まれます。Amazon Cognito はまた、更新トークンの使用を元のイベント ID に関連付けます。元のイベント ID は、Amazon Cognito トークンの発行につながったサインインイベントのイベント ID まで追跡できます。システム内のトークンの使用は、特定の認証イベントまで追跡できます。詳細については、「[ユーザープール JSON ウェブトークン (JWT) の理解](amazon-cognito-user-pools-using-tokens-with-identity-providers.md)」を参照してください。

### ユーザーイベント履歴の表示 (API/CLI)
<a name="user-pool-settings-adaptive-authentication-event-user-history-api-cli"></a>

Amazon Cognito API オペレーション [AdminListUserAuthEvents](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminListUserAuthEvents.html) を使用して、または [admin-list-user-auth-events](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/admin-list-user-auth-events.html) を使用して AWS Command Line Interface (AWS CLI) を使用して、ユーザーイベント履歴をクエリできます。

------
#### [ AdminListUserAuthEvents request ]

次の `AdminListUserAuthEvents` 用のリクエスト本文は、1 人のユーザーの最新のアクティビティログを返します。

```
{
  "UserPoolId": "us-west-2_EXAMPLE", 
  "Username": "myexampleuser", 
  "MaxResults": 1
}
```

------
#### [ admin-list-user-auth-events request ]

次の `admin-list-user-auth-events` 用のリクエストは、1 人のユーザーの最新のアクティビティログを返します。

```
aws cognito-idp admin-list-user-auth-events --max-results 1 --username myexampleuser --user-pool-id us-west-2_EXAMPLE
```

------
#### [ Response ]

Amazon Cognito は、両方のリクエストに同じ JSON レスポンス本文を返します。以下は、リスク要因が含まれていないことが検出されたマネージドログインのサインインイベントのレスポンス例です。

```
{
    "AuthEvents": [
        {
            "EventId": "[event ID]",
            "EventType": "SignIn",
            "CreationDate": "[Timestamp]",
            "EventResponse": "Pass",
            "EventRisk": {
                "RiskDecision": "NoRisk",
                "CompromisedCredentialsDetected": false
            },
            "ChallengeResponses": [
                {
                    "ChallengeName": "Password",
                    "ChallengeResponse": "Success"
                }
            ],
            "EventContextData": {
                "IpAddress": "192.168.2.1",
                "DeviceName": "Chrome 125, Windows 10",
                "Timezone": "-07:00",
                "City": "Bellevue",
                "Country": "United States"
            }
        }
    ],
    "NextToken": "[event ID]#[Timestamp]"
}
```

------

### ユーザー認証イベントのエクスポート
<a name="user-pool-settings-adaptive-authentication-event-user-history-exporting"></a>

脅威保護から外部システムにユーザーイベントをエクスポートするようにユーザープールを設定します。サポートされている外部システムである Amazon S3、CloudWatch Logs、Amazon Data Firehose は、送信または取得するデータの AWS 請求にコストを追加する可能性があります。詳細については、「[脅威保護ユーザーアクティビティログのエクスポート](exporting-quotas-and-usage.md#exporting-quotas-and-usage-user-activity)」を参照してください。

------
#### [ AWS マネジメントコンソール ]

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

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[ログストリーミング]** メニューを選択します。**[Edit]** (編集) を選択します。

1. **[ログ記録ステータス]** で、**[ユーザーアクティビティログのエクスポートをアクティブ化]** の横にあるチェックボックスをオンにします。

1. **[ログ記録先]** で、ログを処理する AWS のサービス を **[CloudWatch ロググループ]**、**[Amazon Data Firehose ストリーム]**、または **[S3 バケット]** の中から選択します。

1. 選択すると、対応するリソースタイプがリソースセレクターに入力されます。リストからロググループ、ストリーム、またはバケットを選択します。**[作成]** ボタンを選択して、選択したサービスの AWS マネジメントコンソール に移動し、新しいリソースを作成することもできます。

1. **[変更を保存]** を選択します。

------
#### [ API ]

ユーザーアクティビティログの送信先のタイプを 1 つ選択します。

以下は、Firehose ストリームをログの送信先として設定する `SetLogDeliveryConfiguration` リクエスト本文の例です。

```
{
   "LogConfigurations": [
      {
         "EventSource": "userAuthEvents",
         "FirehoseConfiguration": {
            "StreamArn": "arn:aws:firehose:us-west-2:123456789012:deliverystream/example-user-pool-activity-exported"
         },
         "LogLevel": "INFO"
      }
   ],
   "UserPoolId": "us-west-2_EXAMPLE"
}
```

以下は、Amazon S3 バケットをログの送信先として設定する `SetLogDeliveryConfiguration` リクエスト本文の例です。

```
{
   "LogConfigurations": [
      {
         "EventSource": "userAuthEvents",
         "S3Configuration": { 
            "BucketArn": "arn:aws:s3:::amzn-s3-demo-logging-bucket"
         },
         "LogLevel": "INFO"
      }
   ],
   "UserPoolId": "us-west-2_EXAMPLE"
}
```

以下は、CloudWatch ロググループをログの送信先として設定する `SetLogDeliveryConfiguration` リクエスト本文の例です。

```
{
   "LogConfigurations": [
      {
         "EventSource": "userAuthEvents",
         "CloudWatchLogsConfiguration": { 
            "LogGroupArn": "arn:aws:logs:us-west-2:123456789012:log-group:DOC-EXAMPLE-LOG-GROUP"
         },
         "LogLevel": "INFO"
      }
   ],
   "UserPoolId": "us-west-2_EXAMPLE"
}
```

------

## イベントフィードバックを提供します
<a name="user-pool-settings-adaptive-authentication-feedback"></a>

イベントフィードバックは、リアルタイムでリスクの評価に反映され、リスク評価アルゴリズムを経時的に向上させます。ユーザーは、Amazon Cognito コンソールおよび API を使用して、サインイン試行の妥当性に関するフィードバックを提供できます。

**注記**  
イベントフィードバックは、Amazon Cognito が同じ特性を持つ後続のユーザーセッションに割り当てるリスクレベルに影響します。

Amazon Cognito コンソールで、**[ユーザー]** メニューからユーザーを選択し、**[イベントフィードバックを提供]** を選択します。イベントの詳細を確認して、**[Set as valid]** (有効として設定) または **[Set as invalid]** (無効として設定) できます。

コンソールでは、**[ユーザー]** メニューのユーザー詳細にサインイン履歴が一覧表示されます。エントリを選択すると、イベントを有効または無効としてマークできます。また、ユーザープール API オペレーション [AdminUpdateAuthEventFeedback](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateAuthEventFeedback.html) および AWS CLI コマンド [admin-update-auth-event-feedback](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/admin-update-auth-event-feedback.html) を通じてフィードバックを提供することもできます。

Amazon Cognito コンソールで **[Set as valid]** (有効として設定) を選択するか、API で `valid` の `FeedbackValue` 値を指定するとき、Amazon Cognito がある程度のリスクを評価したユーザーセッションを信頼することを Amazon Cognito に伝えます。Amazon Cognito コンソールで **[Set as invalid]** (無効として設定) を選択するか、API で `invalid` の `FeedbackValue` 値を指定するとき、ユーザーセッションを信頼しないこと、または Amazon Cognito が十分に高いリスクレベルを評価したとは考えないことを Amazon Cognito に伝えます。

## 通知メッセージの送信
<a name="user-pool-settings-adaptive-authentication-messages"></a>

脅威保護により、Amazon Cognito はユーザーにリスクの高いサインイン試行を通知できます。Amazon Cognito では、サインインが有効か無効かを示すリンクを選択するようユーザーに促すこともできます。Amazon Cognito はこのフィードバックを使用して、ユーザープールのリスク検出精度を向上させます。

**注記**  
Amazon Cognito は、ユーザーのアクションによって自動リスク対応 (サインインのブロック、サインインの許可、MFA をオプションに設定、または MFA を必須に設定) が生成された場合にのみ、ユーザーに通知メッセージを送信します。リクエストによっては、リスクレベルが割り当てられていても、アダプティブ認証の自動リスク対応が生成されない場合があります。このようなリクエストの場合、ユーザープールは通知を送信しません。例えば、誤ったパスワードがリスク評価とともにログに記録される場合がありますが、Amazon Cognito による対応では、アダプティブ認証ルールを適用せずに、サインインを失敗させます。

**[Automatic risk response]** (自動リスク対応) セクションで、低、中、高のリスクケースに応じて **[Notify Users]** (ユーザーに通知) を選択します。

![\[ユーザーに通知する\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-adaptive-auth.png)


Amazon Cognito は、ユーザーが E メールアドレスを検証したかどうかに関係なく、E メール通知をユーザーに送信します。

通知 E メールメッセージをカスタマイズして、これらのメッセージのプレーンテキストと HTML の両バージョンを提供できます。E メール通知をカスタマイズするには、脅威保護設定の **[アダプティブ認証メッセージ]** から **[E メールテンプレート]** を開きます。E メールテンプレートの詳細については、「[メッセージテンプレート](cognito-user-pool-settings-message-customizations.md#cognito-user-pool-settings-message-templates)」を参照してください。

# アプリケーションにおける脅威保護のためのデータ収集
<a name="user-pool-settings-viewing-threat-protection-app"></a>

Amazon Cognito [アダプティブ認証](cognito-user-pool-settings-adaptive-authentication.md)は、ユーザーのサインイン試行のコンテキスト詳細からアカウント乗っ取りを試みた場合のリスクレベルを評価します。Amazon Cognito の脅威保護がリスクをより正確に評価できるように、アプリケーションは API リクエストに*コンテキストデータ*を追加する必要があります。コンテキストデータは、ユーザーがユーザープールにどのように接続したかに関するコンテキスト情報を提供する、IP アドレス、ブラウザエージェント、デバイス情報、リクエストヘッダーなどの情報です。

このコンテキストを Amazon Cognito に送信するアプリケーションの主な責任は、ユーザープールへの認証リクエストの `EncodedData` パラメータです。このデータをリクエストに追加するには、この情報を自動的に生成する SDK を使用して Amazon Cognito を実装することも、このデータを収集する JavaScript、iOS、または Android 用のモジュールを実装することもできます。Amazon Cognito に直接リクエストを行う*クライアント専用*アプリケーションは AWS Amplify SDKs を実装する必要があります。中間サーバーまたは API コンポーネントを持つ*クライアントサーバー*アプリケーションは、別の SDK モジュールを実装する必要があります。

次のシナリオでは、認証フロントエンドが、追加の設定なしでユーザーコンテキストのデータ収集を管理します。
+ マネージドログインは、コンテキストデータを自動的に収集して脅威保護に送信します。
+ すべての AWS Amplify ライブラリには、認証方法に組み込まれたコンテキストデータ収集があります。

## Amplify を使用したクライアント専用アプリケーションでのユーザーコンテキストデータの送信
<a name="user-pool-settings-viewing-threat-protection-app-amplify"></a>

![\[Amplify アプリケーションでの脅威保護のためのデータ収集の概要。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/user-pools-asf-amplify-data-collection.png)


Amplify SDK は、Amazon Cognito で直接認証するモバイルクライアントをサポートします。この種類のクライアントは、Amazon Cognito パブリック API オペレーションに直接 API リクエストを行います。Amplify クライアントは、デフォルトで脅威保護のためのコンテキストデータを自動的に収集します。

JavaScript を使用した Amplify アプリケーションは例外です。ユーザーコンテキストデータを収集する [JavaScript モジュール](#user-pool-settings-viewing-threat-protection-app-additional-resources-js)を追加する必要があります。

通常、この設定のアプリケーションは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) や [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) などの認証されていない API オペレーションを使用します。[UserContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserContextDataType.html) オブジェクトは、これらのオペレーションのリスクをより正確に評価するのに役立ちます。Amplify SDK は、デバイスとセッション情報を `UserContextData` の `EncodedData` パラメータに追加します。

## クライアントサーバーアプリケーションでのコンテキストデータの収集
<a name="user-pool-settings-viewing-threat-protection-app-server-side"></a>

一部のアプリケーションには、ユーザー認証データを収集するフロントエンド層と、Amazon Cognito に認証リクエストを送信するアプリケーションバックエンド層があります。これは、マイクロサービスベースのウェブサーバーとアプリケーションの一般的なアーキテクチャです。これらのアプリケーションでは、パブリックコンテキストデータ収集ライブラリをインポートする必要があります。

![\[JavaScript での脅威保護のコンテキストデータを使用したサーバー側の認証の概要。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/user-pools-asf-non-amplify-data-collection.png)


通常、この設定のアプリケーションサーバーは、[AdminInitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html) や [AdminRespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminRespondToAuthChallenge.html) などの認証された API オペレーションを使用します。[ContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-ContextData) オブジェクトは、Amazon Cognito がこれらのオペレーションのリスクをより正確に評価するのに役立ちます。`ContextData` のコンテンツは、フロントエンドがサーバーに渡したエンコードされたデータと、ユーザーによる HTTP リクエストからサーバーへの追加の詳細です。HTTP ヘッダーや IP アドレスなど、これらの追加のコンテキストの詳細により、アプリケーションサーバーにユーザーの環境の特性が提供されます。

また、アプリケーションサーバーは、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) や [RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html) などの認証されていない API オペレーションでサインインする場合もあります。[UserContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html#CognitoUserPools-InitiateAuth-request-UserContextData) オブジェクトは、これらのオペレーションにおける脅威保護のセキュリティリスク分析に役立ちます。利用可能なパブリックコンテキストデータ収集ライブラリ内のオペレーションは、認証リクエストの `EncodedData` パラメータにセキュリティ情報を追加します。さらに、追加のコンテキストデータを受け入れるようにユーザープールを設定し、ユーザーのソース IP を `UserContextData` の `IpAddress` パラメータに追加します。

**クライアントサーバーアプリケーションにコンテキストデータを追加するには**

1. フロントエンドアプリケーションで、[iOS、Android、または JavaScript モジュール](#user-pool-settings-viewing-threat-protection-app-additional-resources)を使用してクライアントからエンコードされたコンテキストデータを収集します。

1. エンコードされたデータと認証リクエストの詳細をアプリケーションサーバーに渡します。

1. アプリケーションサーバーで、HTTP リクエストから、ユーザーの IP アドレス、関連する HTTP ヘッダー、リクエストされたサーバー名、リクエストされたパスを抽出します。これらの値を Amazon Cognito への API リクエストの [ContextData](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html#CognitoUserPools-AdminInitiateAuth-request-ContextData) パラメータに入力します。

1. SDK モジュールが収集したエンコードされたデバイスデータを使用して、API リクエストの `ContextData` の `EncodedData` パラメータを入力します。このコンテキストデータを認証リクエストに追加します。

## クライアントサーバーアプリケーション用のコンテキストデータライブラリ
<a name="user-pool-settings-viewing-threat-protection-app-additional-resources"></a>

### JavaScript
<a name="user-pool-settings-viewing-threat-protection-app-additional-resources-js"></a>

`amazon-cognito-advanced-security-data.min.js` モジュールは、アプリケーションサーバーに渡すことができる `EncodedData` を収集します。

`amazon-cognito-advanced-security-data.min.js` モジュールを JavaScript 設定に追加します。を、、`us-east-1`、`us-east-2`、、`eu-west-2`、または `us-west-2` `eu-west-1` AWS リージョン のリストから `<region>`に置き換えます`eu-central-1`。

```
<script src="https://amazon-cognito-assets.<region>.amazoncognito.com/amazon-cognito-advanced-security-data.min.js"></script>
```

`EncodedData` パラメータで使用できる `encodedContextData` オブジェクトを生成するには、JavaScript アプリケーションソースに以下を追加します。

```
var encodedContextData = AmazonCognitoAdvancedSecurityData.getData(_username, _userpoolId, _userPoolClientId);
```

### iOS/Swift
<a name="user-pool-settings-viewing-threat-protection-app-additional-resources-ios"></a>

コンテキストデータを生成するには、iOS アプリケーションは、[Mobile SDK for iOS](https://github.com/aws-amplify/aws-sdk-ios/tree/main) モジュール [AWSCognitoIdentityProviderASF](https://github.com/aws-amplify/aws-sdk-ios/tree/main/AWSCognitoIdentityProviderASF) を統合できます。

脅威保護のためにエンコードされたコンテキストデータを収集するには、次のスニペットをアプリケーションに追加します。

```
import AWSCognitoIdentityProviderASF

let deviceId = getDeviceId()
let encodedContextData = AWSCognitoIdentityProviderASF.userContextData(
                            userPoolId, 
                            username: username, 
                            deviceId: deviceId, 
                            userPoolClientId: userPoolClientId)
                                
/**
 * Reuse DeviceId from keychain or generate one for the first time.
 */
func getDeviceId() -> String {
    let deviceIdKey = getKeyChainKey(namespace: userPoolId, key: "AWSCognitoAuthAsfDeviceId")
    
   if let existingDeviceId = self.keychain.string(forKey: deviceIdKey) {
        return existingDeviceId
    }

    let newDeviceId = UUID().uuidString
    self.keychain.setString(newDeviceId, forKey: deviceIdKey)
    return newDeviceId
}

/**
 * Get a namespaced keychain key given a namespace and key
 */    
func getKeyChainKey(namespace: String, key: String) -> String {
    return "\(namespace).\(key)"
}
```

### Android
<a name="user-pool-settings-viewing-threat-protection-app-additional-resources-android"></a>

コンテキストデータを生成するには、Android アプリケーションは、[Mobile SDK for Android](https://github.com/aws-amplify/aws-sdk-android/tree/main) モジュール [aws-android-sdk-cognitoidentityprovider-asf](https://github.com/aws-amplify/aws-sdk-android/tree/main/aws-android-sdk-cognitoidentityprovider-asf) を統合できます。

脅威保護のためにエンコードされたコンテキストデータを収集するには、次のスニペットをアプリケーションに追加します。

```
UserContextDataProvider provider = UserContextDataProvider.getInstance();
// context here is android application context.
String encodedContextData = provider.getEncodedContextData(context, username, userPoolId, userPoolClientId);
```

# AWS WAF ウェブ ACL をユーザープールに関連付ける
<a name="user-pool-waf"></a>

AWS WAF はウェブアプリケーションファイアウォールです。 AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL) を使用すると、クラシックホスト UI、マネージドログイン、Amazon Cognito API サービスエンドポイントへの不要なリクエストからユーザープールを保護できます。ウェブ ACL を使用すると、ユーザープールが応答するすべての HTTPS ウェブリクエストをきめ細かく制御できます。 AWS WAF ウェブ ACL の詳細については、「*AWS WAF デベロッパーガイド*」の「[ウェブアクセスコントロールリスト (ウェブ ACL) の管理と使用](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)」を参照してください。

ユーザープールに関連付けられた AWS WAF ウェブ ACL がある場合、Amazon Cognito は選択した非機密ヘッダーとユーザーからのリクエストの内容を に転送します AWS WAF。 AWS WAF はリクエストの内容を検査し、ウェブ ACL で指定したルールと比較し、Amazon Cognito にレスポンスを返します。

## AWS WAF ウェブ ACLs と Amazon Cognito について知っておくべきこと
<a name="user-pool-waf-things-to-know"></a>
+ ウェブ ACL ルールは、ユーザー名、パスワード、電話番号、E メールアドレスなど、ユーザープールリクエスト内の個人を特定できる情報 (PII) と一致するように設定することはできません。このデータは利用できません AWS WAF。代わりに、IP アドレス、ブラウザエージェント、リクエストされた API オペレーションなど、ヘッダー、パス、本文のセッションデータと一致するようにウェブ ACL ルールを設定します。
+ ウェブ ACL ルールの条件は、ユーザーインタラクティブなマネージドログインページへのユーザーからの**最初**のリクエストに対してのみ、カスタムブロックレスポンスを返すことができます。後続の接続がカスタムブロックレスポンスの条件に一致すると、カスタムステータスコード、ヘッダー、リダイレクトレスポンスを返しますが、デフォルトのブロックメッセージは返しません。
+ によってブロックされたリクエスト AWS WAF は、どのリクエストタイプのリクエストレートクォータにもカウントされません。 AWS WAF ハンドラーは、API レベルのスロットリングハンドラーの前に呼び出されます。
+ ウェブ ACL を作成すると、ウェブ ACL が完全に伝達されて Amazon Cognito で使用できるようになるまでに少し時間がかかります。伝播時間は、数秒から数分までです。 は、完全に伝播される前にウェブ ACL を関連付けようと[https://docs.aws.amazon.com/waf/latest/APIReference/API_AssociateWebACL.html#API_AssociateWebACL_Errors](https://docs.aws.amazon.com/waf/latest/APIReference/API_AssociateWebACL.html#API_AssociateWebACL_Errors)すると、 AWS WAF を返します。
+ ユーザープールごとに 1 つのウェブ ACL を関連付けることができます。
+ リクエストは、 AWS WAF が検査できる範囲を超えたペイロードになる可能性があります が Amazon Cognito [からのオーバーサイズリクエストを処理する方法を設定する方法については、「 デベロッパーガイド」の「オーバーサイズリクエストコンポーネントの処理](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-oversize-handling.html)」を参照してください。 *AWS WAF * AWS WAF 
+  AWS WAF [Fraud Control アカウント乗っ取り防止 (ATP)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-atp.html) を使用するウェブ ACL を Amazon Cognito ユーザープールに関連付けることはできません。ATP 機能は、`AWS-AWSManagedRulesATPRuleSet` マネージドルールグループに含まれています。ウェブ ACL をユーザープールに関連付ける前に、ウェブ ACL がこのマネージドルールグループを使用していないことを確認してください。
+ ユーザープールに関連付けられた AWS WAF ウェブ ACL があり、ウェブ ACL のルールが CAPTCHA を提示すると、マネージドログイン TOTP 登録で回復不可能なエラーが発生する可能性があります。CAPTCHA アクションを含み、マネージドログインの TOTP には影響しないルールを作成するには、「[マネージドログイン TOTP MFA 用の AWS WAF ウェブ ACL の設定](user-pool-settings-mfa-totp.md#totp-waf)」を参照してください。

AWS WAF は、次のエンドポイントへのリクエストを検査します。

**マネージドログインとクラシックのホストされた UI**  
[ユーザープールのエンドポイントとマネージドログインのリファレンス](cognito-userpools-server-contract-reference.md) 内のすべてのエンドポイントへのリクエスト。

**公開 API オペレーション**  
アプリケーションから Amazon Cognito API へのリクエストのうち、認可に AWS 認証情報を使用しないリクエスト。これには、[InitiateAuth](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html)、[RespondToAuthChallenge](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_RespondToAuthChallenge.html)、[GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) などの API オペレーションが含まれます。の範囲内にある API オペレーションでは、 AWS 認証情報による認証 AWS WAF は必要ありません。これらは、認証されていないか、セッション文字列またはアクセストークンで承認されています。詳細については、「[認可モデル別にグループ化された API オペレーションのリスト](authentication-flows-public-server-side.md#user-pool-apis-auth-unauth)」を参照してください。

ウェブ ACL のルールを設定するには、ルールと一致するリクエストに応じて、**カウント**、**許可**、**ブロック**、または **CAPTCHA** 提示を行うルールアクションを使用できます。詳細については、「*AWS WAF デベロッパーガイド*」の「[AWS WAF のルール](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rules.html)」を参照してください。ルールアクションに応じて、Amazon Cognito からユーザーに返す応答をカスタマイズできます。

**重要**  
エラー応答をカスタマイズするオプションは、API リクエストを行う方法によって異なります。  
マネージドログインリクエストのエラーコードとレスポンス本文をカスタマイズできます。マネージドログインでは、ユーザーに解決してもらうためだけに CAPTCHA を提示できます。
Amazon Cognito [ユーザープール API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html) を使用して行うリクエストの場合は、**ブロック**応答を受信するリクエストの応答本文をカスタマイズできます。カスタムエラーコードを 400～499 の範囲で指定することもできます。
 AWS Command Line Interface (AWS CLI) と AWS SDKs は、**ブロック**または **CAPTCHA** レスポンスを生成するリクエストに`ForbiddenException`エラーを返します。

## ウェブ ACL をユーザープールに関連付ける
<a name="user-pool-waf-setting-up"></a>

ユーザープールでウェブ ACL を使用するには、 AWS Identity and Access Management (IAM) プリンシパルに次の Amazon Cognito および アクセス AWS WAF 許可が必要です。アクセス AWS WAF 許可の詳細については、「 *AWS WAF デベロッパーガイド*」の[AWS WAF 「API アクセス許可](https://docs.aws.amazon.com/waf/latest/developerguide/waf-api-permissions-ref.html)」を参照してください。

------
#### [ JSON ]

****  

```
{
	"Version":"2012-10-17",		 	 	 
	"Statement": [
		{
			"Sid": "AllowWebACLUserPool",
			"Effect": "Allow",
			"Action": [
				"cognito-idp:ListResourcesForWebACL",
				"cognito-idp:GetWebACLForResource",
				"cognito-idp:AssociateWebACL"
			],
			"Resource": [
				"arn:aws:cognito-idp:*:123456789012:userpool/*"
			]
		},
		{
			"Sid": "AllowWebACLUserPoolWAFv2",
			"Effect": "Allow",
			"Action": [
				"wafv2:ListResourcesForWebACL",
				"wafv2:AssociateWebACL",
				"wafv2:DisassociateWebACL",
				"wafv2:GetWebACLForResource"
			],
			"Resource": "arn:aws:wafv2:*:123456789012:*/webacl/*/*"
		},
		{
			"Sid": "DisassociateWebACL1",
			"Effect": "Allow",
			"Action": "wafv2:DisassociateWebACL",
			"Resource": "*"
		},
		{
			"Sid": "DisassociateWebACL2",
			"Effect": "Allow",
			"Action": [
				"cognito-idp:DisassociateWebACL"
			],
			"Resource": [
				"arn:aws:cognito-idp:*:123456789012:userpool/*"
			]
		}
	]
}
```

------

IAM アクセス許可を付与する必要がありますが、リストされているのは、対応する [API オペレーション](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html)のない許可のみのアクションです。

**ユーザープール AWS WAF の をアクティブ化し、ウェブ ACL を関連付けるには**

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

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

1. **[セキュリティ]** セクションの **[AWS WAF]** タブを選択します。

1. **[編集]** を選択します。

1. **ユーザープール AWS WAF で を使用する** を選択します。  
![\[ユーザープールを選択した AWS WAF 状態で を使用する AWS WAF ダイアログボックスのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/cup-WAF-console.png)

1. すでに作成した**AWS WAF ウェブ ACL** を選択するか、**「 でウェブ ACL AWS WAF** を作成する」を選択して、 の新しい AWS WAF セッションで作成します AWS マネジメントコンソール。

1. **[Save changes]** (変更の保存) をクリックします。

ウェブ ACL を AWS Command Line Interface または SDK のユーザープールにプログラムで関連付けるには、 AWS WAF API の [AssociateWebACL](https://docs.aws.amazon.com/waf/latest/APIReference/API_AssociateWebACL.html) を使用します。Amazon Cognito には、ウェブ ACL を関連付ける個別の API オペレーションはありません。

## AWS WAF ウェブ ACLsテストとログ記録
<a name="user-pool-waf-evaluating-and-logging"></a>

ウェブ ACL でルールアクションを**カウント**に設定すると、 はルールに一致するリクエストの数にリクエスト AWS WAF を追加します。ユーザープールでウェブ ACL をテストするには、ルールアクションを**カウント**に設定し、各ルールに一致するリクエストの量を考慮します。例えば、ルールを**ブロック**アクションに設定した場合に、通常のユーザートラフィックと判断される多数のリクエストと一致するときは、ルールの再設定が必要になる場合があります。詳細については、「*AWS WAF デベロッパーガイド*」の「[AWS WAF 保護のテストとチューニング](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)」を参照してください。

リクエストヘッダーを Amazon CloudWatch Logs ロググループ、Amazon Simple Storage Service (Amazon S3) バケット、または Amazon Data Firehose に記録する AWS WAF ように を設定することもできます。ユーザープール API で行った Amazon Cognito リクエストは、`x-amzn-cognito-client-id` と `x-amzn-cognito-operation-name` で特定できます マネージドログインのリクエストには、`x-amzn-cognito-client-id` ヘッダーのみが含まれます。詳細については、「*AWS WAF デベロッパーガイド*」の「[ウェブ ACL トラフィックのログ記録](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html)」を参照してください。

AWS WAF ウェブ ACLsは、すべてのユーザープール[機能プラン](cognito-sign-in-feature-plans.md)で使用できます。 AWS WAF のセキュリティ機能は、Amazon Cognito の脅威保護を補完します。ユーザープールで両方の機能を有効にすることができます。 AWS WAF は、ユーザープールリクエストの検査に対して別途に請求を行います。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing)」を参照してください。

ログ記録 AWS WAF リクエストデータには、ログをターゲットとするサービスによる追加料金が適用されます。詳細については、「*AWS WAF デベロッパーガイド*」の「[ウェブ ACL トラフィック情報のログ記録の料金](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html#logging-pricing)」を参照してください。

# ユーザープールの大文字と小文字の区別
<a name="user-pool-case-sensitivity"></a>

で作成した Amazon Cognito ユーザープール AWS マネジメントコンソール では、デフォルトで大文字と小文字が区別されません。ユーザープールが大文字と小文字を区別しない場合、*user@example.com* と *User@example.com* は同じユーザーを参照します。ユーザープール内のユーザー名が大文字と小文字が区別しない場合、`preferred_username` と `email` 属性でも大文字と小文字が区別されません。

大文字と小文字の区別なしは、属性の入力だけでなく出力にも適用されます。大文字と小文字を区別しないユーザープールにおいて、大文字と小文字が混在する属性値は、ユーザープールのテキスト出力で小文字に変換されます。ユーザープールのテキスト出力の例としては、[userInfo](userinfo-endpoint.md) レスポンス、ユーザークエリレスポンス ([GetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) の出力など)、[Lambda トリガー](cognito-user-pools-working-with-lambda-triggers.md)への入力イベントがあります。

ユーザープールの大文字と小文字の区別の設定を考慮するには、代替のユーザー属性に基づいてアプリコードでユーザーを識別します。ユーザー名、優先ユーザー名、または E メールアドレス属性の大文字と小文字はユーザープロファイルによって異なる場合があるため、代わりに `sub` 属性を参照してください。また、ユーザープールにイミュータブルカスタム属性を作成し、各新規ユーザープロファイルの属性に独自の一意の識別子値を割り当てることもできます。最初にユーザーを作成するときに、作成したイミュータブルカスタム属性に値を書き込むことができます。

**注記**  
ユーザープールの大文字と小文字を区別する設定に関係なく、Amazon Cognito では、SAML または OIDC ID プロバイダー (IdP) のフェデレーティッドユーザーが、大文字と小文字を区別する一意の `NameId` または `sub` クレームを渡す必要があります。一意の識別子の大文字と小文字の区別および SAML IdP の詳細については、「[SP が開始した SAML サインインを実装する](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-saml-idp-authentication)」を参照してください。

大文字と小文字を区別するユーザープールの作成  
 AWS Command Line Interface (AWS CLI) および [CreateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateUserPool.html) などの API オペレーションを使用してリソースを作成する場合は、ブール`CaseSensitive`パラメータを に設定する必要があります`false`。この設定では、大文字と小文字を区別しないユーザープールが作成されます。値を指定しないと、`CaseSensitive` はデフォルトで `true` に従います。Amazon Cognito コンソールで作成するユーザープールでは、大文字と小文字は区別されません。大文字と小文字を区別するユーザープールを生成するには、`CreateUserPool` オペレーションを使用する必要があります。2020 年 2 月 12 日以前のユーザープールでは、プラットフォームに関係なく、大文字と小文字が区別されていました。  
 AWS マネジメントコンソール の **[サインイン]** メニューおよび [DescribeUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserPoolType.html#CognitoUserPools-Type-UserPoolType-UsernameConfiguration) の `UsernameConfiguration` プロパティで、アカウント内の各ユーザープールの大文字と小文字を区別する設定を確認できます。

新しいユーザープールに移行する  
ユーザープロファイル間で競合が発生する可能性があるため、Amazon Cognito ユーザープールで大文字と小文字を区別するから大文字と小文字を区別しないに変更することはできません。代わりに、ユーザーを新しいユーザープールに移行します。ケース関連の競合を解決するには、移行コードをビルドする必要があります。このコードは、競合を検出したときに一意の新しいユーザーを返すか、サインイン試行を拒否する必要があります。大文字と小文字を区別しない新しいユーザープールで、[ユーザー移行の Lambda トリガー](user-pool-lambda-migrate-user.md) を割り当てます。 AWS Lambda 関数は、新しい大文字と小文字を区別しないユーザープールにユーザーを作成できます。ユーザーが大文字小文字を区別しないユーザープールでサインインに失敗した場合、Lambda 関数は大文字小文字を区別するユーザープールからユーザーを見つけて、複製します。また、[ForgotPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html) イベントで、ユーザーの移行 Lambda トリガーを有効化することもできます。Amazon Cognito は、サインインやパスワード回復アクションからユーザー情報とイベントメタデータを Lambda 関数に渡します。関数が大文字と小文字を区別しないユーザープールに新しいユーザーを作成する際、イベントデータを使用してユーザー名とメールアドレス間で発生する競合を管理することができます。ユーザー名と E メールアドレスが、大文字と小文字を区別するユーザープールでは一意でも、大文字と小文字を区別しないユーザープールでは同一となる場合に競合が発生します。  
Amazon Cognito ユーザープール間でユーザーの Lambda 移行トリガーを使用する方法の詳細については、 AWS ブログの[「ユーザーの Amazon Cognito ユーザープールへの移行](https://aws.amazon.com/blogs/mobile/migrating-users-to-amazon-cognito-user-pools/)」を参照してください。

# ユーザープールの削除保護
<a name="user-pool-settings-deletion-protection"></a>

管理者が誤ってユーザープールを削除しないようにするには、削除保護を有効にします。削除保護が有効になっている場合は、ユーザープールを削除する前に削除の確認を行う必要があります。でユーザープールを削除すると AWS マネジメントコンソール、削除保護を同時に無効にできます。次の画像に示すように、削除保護を無効にするプロンプトに応じて削除の意思を確認すると、Amazon Cognito がユーザープールを削除します。

![\[削除保護を無効にするプロンプトを含むユーザープールを削除するプロンプト AWS マネジメントコンソール を示す のスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/images/amazon-cognito-delete-user-pool-deactivate-deletion-protection.png)


Amazon Cognito API リクエストを使用してユーザープールを削除する場合は、まず [UpdateUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPool.html) リクエストで `DeletionProtection` を `Inactive` に変更する必要があります。削除保護を無効にしないと、Amazon Cognito は `InvalidParameterException` エラーを返します。削除保護を無効にすると、[DeleteUserPool](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DeleteUserPool.html) リクエストでユーザープールを削除できます。

Amazon Cognito は、 AWS マネジメントコンソールで新しいユーザープールの作成時に、デフォルトで**削除保護**を有効にします。`CreateUserPool` API を使用してユーザープールを作成すると、削除保護はデフォルトで無効になります。 AWS CLI または AWS SDK で作成したユーザープールでこの機能を使用するには、 `DeletionProtection`パラメータを に設定します`True`。

Amazon Cognito コンソールの **[設定]** メニューの **[削除保護]** コンテナで、削除保護ステータスをアクティブ化または非アクティブ化できます。

# 削除保護を設定するには


1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)に移動します。 AWS 認証情報の入力を求められる場合があります。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択するか、[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。

1. **[設定]** メニューを選択し、**[削除保護]** タブに移動します。**[アクティブ化]** または **[非アクティブ化]** を選択します。

1. 次のダイアログで選択を確定します。

# ユーザー存在エラー応答の管理
<a name="cognito-user-pool-managing-errors"></a>

Amazon Cognito は、ユーザープールから返されるエラーレスポンスのカスタマイズをサポートしています。カスタムエラーレスポンスは、ユーザーの作成と認証、パスワードリカバリ、および確認操作に利用できます。

ユーザープールアプリクライアントの `PreventUserExistenceErrors` 設定を使用して、ユーザーの存在に関連するエラーを有効または無効にします。Amazon Cognito ユーザープール API を使用して新しいアプリケーションクライアントを作成する場合、`PreventUserExistenceErrors` はデフォルトで `LEGACY` または無効になっています。Amazon Cognito コンソールでは、オプションの**ユーザー存在エラーの防止**が、`PreventUserExistenceErrors` を `ENABLED` とする設定としてデフォルトで選択されています。`PreventUserExistenceErrors` の設定を更新するには、次のいずれかを実行します。
+ [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UpdateUserPoolClient.html) API リクエストで `PreventUserExistenceErrors` の値を `ENABLED` と `LEGACY` との間で変更します。
+ Amazon Cognito コンソールでアプリケーションクライアントを編集し、**ユーザー存在エラーの防止**の状態を、選択 (`ENABLED`) と選択解除 (`LEGACY`) との間で変更します。

このプロパティの値が `LEGACY` である場合、ユーザーがユーザープールに存在しないユーザー名でサインインしようとすると、アプリケーションクライアントは `UserNotFoundException` エラー応答を返します。

このプロパティの値が `ENABLED` である場合、アプリケーションクライアントは、ユーザープールにユーザーアカウントが存在しないことを `UserNotFoundException` エラーを用いて開示しません。`PreventUserExistenceErrors` を `ENABLED` に設定した場合、存在しないユーザー名をリクエストすると、以下のようになります。
+ Amazon Cognito は API リクエストに対して非特定の情報で応答します。そうしない場合、その応答から有効なユーザーが存在することが開示される可能性があります。
+ Amazon Cognito は、パスワードを忘れた場合のリクエストに対して、さらに `USER_SRP_AUTH` や `CUSTOM_AUTH` などの[選択ベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-choice) (`USER_AUTH`) を*除く*認証フローによる認証リクエストに対して、一般的な認証失敗レスポンスを返します。エラーレスポンスは、ユーザー名またはパスワードが正しくないことを伝えます。
+ Amazon Cognito は、選択ベースの認証へのリクエストに対して、ユーザープールで許可されているチャレンジタイプからランダムに選択して応答します。ユーザープールは、パスキー、ワンタイムパスワード、またはパスワードチャレンジを返す場合があります。
+ Amazon Cognito のアカウント確認 API とパスワード復旧 API の動作は、シミュレートされた配信メディアにコードが送信されたことを示すレスポンスを返すか、`InvalidParameterException` エラーを返すかのいずれかです。

次の情報は、`PreventUserExistenceErrors` が `ENABLED` に設定されている場合のユーザープールオペレーションの動作を詳しく示しています。

## 認証とユーザー作成のオペレーション
<a name="cognito-user-pool-managing-errors-user-auth"></a>

エラーレスポンスは、ユーザー名パスワード認証とセキュアリモートパスワード (SRP) 認証で設定できます。カスタム認証により、返すエラーをカスタマイズすることもできます。選択ベースの認証は、`PreventUserExistenceErrors` 設定の影響を受けません。認証フローでのユーザー存在開示の詳細

**選択ベースの認証**  
`USER_AUTH` 選択ベースの認証フローの場合、Amazon Cognito は、ユーザープール設定とユーザー属性に応じて、利用可能なプライマリ認証要素からチャレンジを返します。この認証フローでは、パスワード、セキュアリモートパスワード (SRP)、WebAuthn (パスキー）、SMS ワンタイムパスワード (OTP)、または E メール OTP チャレンジを返すことができます。`PreventUserExistenceErrors` がアクティブな場合、Amazon Cognito は、存在しないユーザーに対して 1 つ以上の利用可能な認証形式を完了するためのチャレンジを発行します。`PreventUserExistenceErrors` が非アクティブな場合、Amazon Cognito は `UserNotFound` 例外を返します。

**ユーザー名およびパスワード認証**  
`PreventUserExistenceErrors` がアクティブな場合、`ADMIN_USER_PASSWORD_AUTH` 認証フロー、`USER_PASSWORD_AUTH` 認証フロー、および `USER_AUTH` の `PASSWORD` フローは、メッセージ `Incorrect username or password` とともに `NotAuthorizedException` を返します。`PreventUserExistenceErrors` が非アクティブな場合、これらのフローは `UserNotFoundException` を返します。

**セキュアリモートパスワード (SRP) ベースの認証**  
ベストプラクティスとして、E メールアドレス、電話番号、または優先ユーザー名の[エイリアス属性](user-pool-settings-attributes.md#user-pool-settings-aliases)がないユーザープールでは、`PreventUserExistenceErrors` を実装するのに `USER_SRP_AUTH` または `USER_AUTH` の `PASSWORD_SRP` フローのみを使用します。エイリアス属性を持つユーザーは、SRP 認証フローでユーザー存在が抑制されない場合があります。ユーザー名パスワード認証フロー (`ADMIN_USER_PASSWORD_AUTH`、`USER_PASSWORD_AUTH`、および `USER_AUTH` `PASSWORD` チャレンジ) は、エイリアス属性からのユーザー存在を完全に抑制します。  
アプリケーションクライアントに知られていないユーザー名を使用して誰かが SRP サインインを試みると、Amazon Cognito は、[RFC 5054](https://tools.ietf.org/html/rfc5054#section-2.5.1.3) で説明されているように、最初のステップでシミュレートされたレスポンスを返します。Amazon Cognito は、同じユーザー名とユーザープールの組み合わせに対して、同じ Salt と [UUID](cognito-terms.md#terms-uuid) 形式の内部ユーザー ID を返します。パスワードの証明を含む `RespondToAuthChallenge` API リクエストを送信すると、Amazon Cognito はユーザー名またはパスワードのいずれかが正しくない場合に一般的な `NotAuthorizedException` エラーを返します。SRP 認証の実装の詳細については、「[永続的なパスワードと安全なペイロードによるサインイン](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-srp)」を参照してください。  
検証ベースのエイリアス属性を使用していて、変更不可能なユーザー名の形式が [UUID](cognito-terms.md#terms-uuid) でない場合は、ユーザー名とパスワードの認証で汎用応答をシミュレートできます。

**カスタム認証チャレンジの Lambda トリガー**  
Amazon Cognito は、`CUSTOM_AUTH` 認証フローでサインインしようとしたユーザーのユーザー名が見つからない場合、[カスタム認証チャレンジ Lambda トリガー](user-pool-lambda-challenge.md)を呼び出します。ユーザーが存在しない場合、入力イベントには `UserNotFound` という名前のブール型パラメータが `true` の値とともに含まれます。このパラメータは、カスタム認証アーキテクチャを構成する認証チャレンジの作成、定義、検証を行う Lambda 関数にユーザープールから送信するリクエストイベントに表示されます。このインジケータを Lambda 関数のロジックで確認したら、存在しないユーザーのカスタム認証チャレンジをシミュレートできます。

**認証前の Lambda トリガー**  
Amazon Cognito は、サインインしようとしたユーザーのユーザー名が見つからない場合、[認証前トリガー](user-pool-lambda-pre-authentication.md)を呼び出します。ユーザーが存在しない場合、入力イベントには `UserNotFound` パラメータが `true` の値とともに含まれます。

ユーザーアカウントの作成に対する `PreventUserExistenceErrors` の影響について以下に説明します。ユーザー作成フローでのユーザー存在開示の詳細

**SignUp**  
`SignUp` オペレーションは、ユーザー名がすでに使用されている場合は必ず `UsernameExistsException` を返します。アプリケーションでユーザーをサインアップするときに Amazon Cognito が E メールアドレスと電話番号の `UsernameExistsException` エラーを返さないようにするには、検証ベースのエイリアス属性を使用してください。エイリアスの詳細については、「[ログイン属性のカスタマイズ](user-pool-settings-attributes.md#user-pool-settings-aliases)」を参照してください。  
Amazon Cognito が`SignUp` API リクエストを使用してユーザープール内のユーザーを検出できないようにする方法の例については、「[サインアップ時のメールアドレスと電話番号の `UsernameExistsException` エラーの防止](#cognito-user-pool-managing-errors-prevent-userexistence-errors)」を参照してください。

**インポート済みユーザー**  
`PreventUserExistenceErrors` が有効になっている場合は、インポートされたユーザーの認証中、`PasswordResetRequiredException` を返す代わりに、ユーザー名またはパスワードが正しくなかったことを示す `NotAuthorizedException` エラーが返されます。詳細については「[インポートされたユーザーにパスワードをリセットするように要求](cognito-user-pools-using-import-tool.md#cognito-user-pools-using-import-tool-password-reset)」を参照してください。

**ユーザー移行の Lambda トリガー**  
Lambda トリガーによって元のイベントコンテキストに空のレスポンスが設定された場合、Amazon Cognito は存在しないユーザーについてシミュレートされたレスポンスを返します。詳細については、「[ユーザー移行の Lambda トリガーを使用したユーザーのインポート](cognito-user-pools-import-using-lambda.md)」を参照してください。

### サインアップ時のメールアドレスと電話番号の `UsernameExistsException` エラーの防止
<a name="cognito-user-pool-managing-errors-prevent-userexistence-errors"></a>

次の例は、ユーザープールでエイリアス属性を設定するときに、重複する E メールアドレスと電話番号が `SignUp` API リクエストに応答して `UsernameExistsException` エラーを生成しないようにする方法を示しています。E メールアドレスまたは電話番号をエイリアス属性として使用してユーザープールを作成しておく必要があります。詳細については、「[ユーザープール属性](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-aliases)」の「*サインイン属性のカスタマイズ*」セクションを参照してください。

1. Jie は新しいユーザー名にサインアップし、E メールアドレス `jie@example.com` も提供します。Amazon Cognito がユーザーの E メールアドレスにコードを送信します。

   ** AWS CLI コマンドの例**

   ```
   aws cognito-idp sign-up --client-id 1234567890abcdef0 --username jie --password PASSWORD --user-attributes Name="email",Value="jie@example.com"
   ```

   **レスポンスの例**

   ```
   {
       "UserConfirmed": false, 
       "UserSub": "<subId>", 
       "CodeDeliveryDetails": {
           "AttributeName": "email", 
           "Destination": "j****@e****", 
           "DeliveryMedium": "EMAIL"
       }
   }
   ```

1. Jie は、E メールアドレスの所有権を確認するために送信されたコードを提供します。これで、ユーザーとしての登録は完了です。

   ** AWS CLI コマンドの例**

   ```
   aws cognito-idp confirm-sign-up --client-id 1234567890abcdef0 --username=jie --confirmation-code xxxxxx
   ```

1. Shirley は新しいユーザーアカウントを登録し、E メールアドレス `jie@example.com` を提供します。Amazon Cognito は `UsernameExistsException` エラーを返さず、確認コードを Jie の E メールアドレスに送信します。

   ** AWS CLI コマンドの例**

   ```
   aws cognito-idp sign-up --client-id 1234567890abcdef0 --username shirley --password PASSWORD --user-attributes Name="email",Value="jie@example.com"
   ```

   **レスポンスの例**

   ```
   {
       "UserConfirmed": false, 
       "UserSub": "<new subId>", 
       "CodeDeliveryDetails": {
           "AttributeName": "email", 
           "Destination": "j****@e****", 
           "DeliveryMedium": "EMAIL"
       }
   }
   ```

1. 別のシナリオでは、Shirley が `jie@example.com` の所有権を持っています。Shirley は Amazon Cognito が Jie の E メールアドレスに送信したコードを取得し、アカウントの確認を試みます。

   ** AWS CLI コマンドの例**

   ```
   aws cognito-idp confirm-sign-up --client-id 1234567890abcdef0 --username=shirley --confirmation-code xxxxxx
   ```

   **レスポンスの例**

   ```
   An error occurred (AliasExistsException) when calling the ConfirmSignUp operation: An account with the email already exists.
   ```

`jie@example.com` が既存のユーザーに割り当てられているにもかかわらず、Amazon Cognito は Shirley の `aws cognito-idp sign-up` リクエストにエラーを返しません。Amazon Cognito がエラーレスポンスを返す前に、Shirley は E メールアドレスの所有権を証明する必要があります。エイリアス属性を持つユーザープールでは、この動作により、パブリック `SignUp` API を使用して、特定の E メールアドレスまたは電話番号を持つユーザーが存在するかどうかを確認できなくなります。

この動作は、次の例に示すように、Amazon Cognito が既存のユーザー名の `SignUp` リクエストに対して返すレスポンスとは異なります。Shirley はこのレスポンスから、そのユーザー名 `jie` を持つユーザーが既に存在することを知っていますが、そのユーザーに関連する E メールアドレスや電話番号については知りません。

**CLI コマンドの例**

```
aws cognito-idp sign-up --client-id 1example23456789 --username jie --password PASSWORD
      --user-attributes Name="email",Value="shirley@example.com"
```

**レスポンスの例**

```
An error occurred (UsernameExistsException) when calling the SignUp operation: User already exists
```

## パスワードのリセットオペレーション
<a name="cognito-user-pool-managing-errors-password-reset"></a>

ユーザー存在エラーを防ぐと、Amazon Cognito は、ユーザーパスワードのリセット操作に対して以下の応答を返します。

**ForgotPassword**  
ユーザーが見つからない、非アクティブ化されている、またはパスワードを回復するための検証済みの配信メカニズムがない場合、Amazon Cognito はそのユーザーについてシミュレート済みの配信ミディアムを用いた `CodeDeliveryDetails` を返します。シミュレートされた配信メディアは、入力ユーザー名形式とユーザープールの検証設定によって決まります。

**ConfirmForgotPassword**  
Amazon Cognito は、存在しない、または無効になっているユーザーについて `CodeMismatchException` エラーを返します。`ForgotPassword` の使用時にコードが要求されない場合、Amazon Cognito は `ExpiredCodeException` エラーを返します。

## 確認オペレーション
<a name="cognito-user-pool-managing-errors-confirmation"></a>

ユーザー存在エラーを防ぐと、Amazon Cognito は、ユーザーの確認および検証の操作に対して以下の応答を返します。

**ResendConfirmationCode**  
Amazon Cognito は、無効化されたユーザー、または存在しないユーザーについて `CodeDeliveryDetails` を返します。Amazon Cognito は、既存ユーザーの E メールまたは電話番号に確認コードを送信します。

**ConfirmSignUp**  
 コードの有効期限が切れている場合は、`ExpiredCodeException` が返されます。Amazon Cognito は、ユーザーが承認されていない場合に `NotAuthorizedException` を返します。コードがサーバーが期待するものと一致しない場合、Amazon Cognito は `CodeMismatchException` を返します。

# ユーザープールのエンドポイントとマネージドログインのリファレンス
<a name="cognito-userpools-server-contract-reference"></a>

Amazon Cognito には、ユーザープール認証として、ユーザープール API を用いたものと、OAuth 2.0 認可サーバーを用いたものの 2 つのモデルがあります。アプリケーションのバックエンドで AWS SDK を使用して OpenID Connect (OIDC) トークンを取得する場合は、 API を使用します。ユーザープールを OIDC プロバイダーとして実装する場合は、認可サーバーを使用します。認可サーバーは、[フェデレーティッドサインイン](cognito-user-pools-identity-federation.md)、[アクセストークンスコープを使用した API および M2M 認可](cognito-user-pools-define-resource-servers.md)、[マネージドログイン](cognito-user-pools-managed-login.md)などの機能を追加します。API モデルと OIDC モデルは、ユーザープールレベルまたは[アプリケーションクライアント](user-pool-settings-client-apps.md)レベルでの設定により、それぞれ単独で使用することも、併用することもできます。このセクションでは、OIDC モデルの実装に関するリファレンスを示します。これら 2 つの認可モデルの詳細については、「[API、OIDC、マネージドログインページの認証についての理解](authentication-flows-public-server-side.md#user-pools-API-operations)」を参照してください。

ユーザープールにドメインを割り当てると、Amazon Cognito はここにリストされているパブリックウェブページをアクティブにします。ドメインは、すべてのアプリクライアントの中央アクセスポイントとして機能します。これには、ユーザーがサインアップとサインイン ([ログインエンドポイント](login-endpoint.md))、およびサインアウト ([ログアウトエンドポイント](logout-endpoint.md)) を行うことができるマネージドログインが含まれます。これらのリソースの詳細については、「[ユーザープールのマネージドログイン](cognito-user-pools-managed-login.md)」を参照してください。

これらのページには、ユーザープールがサードパーティーの SAML、OpenID Connect (OIDC)、および OAuth 2.0 ID プロバイダー (IdPs) と通信できるようにするパブリックウェブリソースも含まれています。フェデレーション ID プロバイダーを使用してユーザーをサインインさせる場合、ユーザーは、インタラクティブなマネージドログインの[ログインエンドポイント](login-endpoint.md)または OIDC の[認可エンドポイント](authorization-endpoint.md)に対してリクエストを開始する必要があります。認可エンドポイントは、ユーザーをマネージドログインページまたは IdP のサインインページにリダイレクトします。

アプリは、[Amazon Cognito ユーザープール API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html) を使用して*ローカルユーザー*をサインインすることもできます。ローカルユーザーは、外部 IdP を介したフェデレーションなしに、ユーザープールディレクトリにのみ存在します。

Amazon Cognito は、マネージドログインに加えて、Android、iOS、JavaScript などの SDK とも統合されています。SDK は、Amazon Cognito API サービスエンドポイントにユーザープール API オペレーションを実行するためのツールを提供します。サービスエンドポイントの詳細については、「[Amazon Cognito Identity エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/cognito_identity.html)」を参照してください。

**警告**  
Amazon Cognito ドメインのエンドエンティティ証明書または中間 Transport Layer Security (TLS) 証明書を固定しないでください。 は、すべてのユーザープールエンドポイントとプレフィックスドメインのすべての証明書 AWS を管理します。Amazon Cognito 証明書をサポートする信頼チェーン内の認証局 (CA) は、動的にローテーションし、更新されます。アプリを中間証明書またはリーフ証明書に固定すると、 が証明書を AWS ローテーションするときに、アプリが予告なしに失敗する可能性があります。  
代わりに、アプリケーションを利用できるすべての [Amazon ルート証明書](https://www.amazontrust.com/repository/)に固定します。詳細については、「*AWS Certificate Manager ユーザーガイド*」で「[証明書のピン留め](https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpractices.html#best-practices-pinning)」のベストプラクティスと推奨事項を参照してください。

**Topics**
+ [ユーザーインタラクティブなマネージドログインとクラシックのホストされた UI のエンドポイント](managed-login-endpoints.md)
+ [ID プロバイダーと依拠しているパーティーエンドポイント](federation-endpoints.md)
+ [OAuth 2.0 許可](federation-endpoints-oauth-grants.md)
+ [認可コード許可での PKCE の使用](using-pkce-in-authorization-code.md)
+ [マネージドログインとフェデレーションのエラーレスポンス](federation-endpoint-idp-responses.md)

# ユーザーインタラクティブなマネージドログインとクラシックのホストされた UI のエンドポイント
<a name="managed-login-endpoints"></a>

ユーザープールにドメインを追加すると、Amazon Cognito は、このセクションのマネージドログインのエンドポイントをアクティブにします。これらは、ユーザーがユーザープールの中核となる認証操作を完了できるウェブページです。これらには、パスワード管理、多要素認証 (MFA)、および属性検証用のページが含まれます。

マネージドログインを構成するウェブページは、ユーザーとのインタラクティブなユーザーセッション用のフロントエンドウェブアプリケーションです。アプリケーションは、ユーザーのブラウザでマネージドログインを呼び出す必要があります。Amazon Cognito は、この章のウェブページに対するプログラムによるアクセスをサポートしていません。JSON レスポンスを返す [ID プロバイダーと依拠しているパーティーエンドポイント](federation-endpoints.md) のフェデレーションエンドポイントは、アプリコードで直接クエリできます。[認可エンドポイント](authorization-endpoint.md)は、マネージドログインまたは IdP のサインインページにリダイレクトされます。また、ユーザーのブラウザで開く必要があります。

すべてのユーザープールエンドポイントは、IPv4 および IPv6 のソース IP アドレスからのトラフィックを受け入れます。

このガイドのトピックでは、よく使用されるマネージドログインとクラシックのホストされた UI のエンドポイントについて詳しく説明します。マネージドログインとホストされた UI の違いは外観であり、機能に差はありません。`/passkeys/add` を除き、すべてのパスは 2 つのバージョンのマネージドログインのブランディング間で共有されます。

Amazon Cognito は、ユーザープールにドメインを割り当てる際に以下のウェブページを利用できるようにします。


**マネージドログインのエンドポイント**  

| エンドポイント URL | 説明 | アクセス方法 | 
| --- | --- | --- | 
| https://ユーザープールのドメイン/login | ユーザープールのローカルユーザーとフェデレーションユーザーにサインインします。 |  [認可エンドポイント](authorization-endpoint.md)、`/logout`、と `/confirmforgotPassword` などのエンドポイントからリダイレクトします。「[ログインエンドポイント](login-endpoint.md)」を参照してください。  | 
| https://ユーザープールのドメイン/logout | ユーザープールユーザーをサインアウトします。 |  直接リンク。「[ログアウトエンドポイント](logout-endpoint.md)」を参照してください。  | 
| https://ユーザープールのドメイン/ConfirmUser | E メールリンクを選択してユーザーアカウントを検証したユーザーを確認します。 |  ユーザーが E メールメッセージ内のリンクを選択しました。  | 
| https://ユーザープールのドメイン/signup | 新規ユーザーをサインアップします。/login ページは、ユーザーが [Sign up] (サインアップ) を選択すると、/signup に移動します。 |  `/oauth2/authorize` と同じパラメータを持つ直接リンク。  | 
| https://ユーザープールのドメイン/confirm | ユーザープールがサインアップしたユーザーに確認コードを送信すると、ユーザーにコードの入力を求めます。 |  `/signup` からのリダイレクトのみ。  | 
| https://Your user pool domain/forgotPassword | ユーザーにユーザー名の入力を求め、パスワードリセットコードを送信します。/login ページは、ユーザーが [Forgot your password?] (パスワードをお忘れですか?) を選択するとユーザーを /forgotPassword に誘導します。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/managed-login-endpoints.html)  | 
| https://Your user pool domain/confirmforgotPassword | ユーザーにパスワードリセットコードと新しいパスワードの入力を求めます。/forgotPassword ページは、ユーザーが [Reset your password] (パスワードのリセット) を選択するとユーザーを /confirmforgotPassword ページに誘導します。 | /forgotPassword からのリダイレクトのみ。 | 
| https://ユーザープールのドメイン/resendcode | ユーザープールにサインアップしたユーザーに、新しい確認コードを送信します。 |  `/confirm` の **[新しいコードを送信]** リンクからのリダイレクトのみ。  | 
| https://ユーザープールドメイン/passkeys/add | 新しい[パスキー](amazon-cognito-user-pools-authentication-flow-methods.md#amazon-cognito-user-pools-authentication-flow-methods-passkey)を登録します。マネージドログインでのみ使用できます。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/managed-login-endpoints.html)  | 

**Topics**
+ [マネージドログインのサインインエンドポイント: `/login`](login-endpoint.md)
+ [マネージドログインのサインアウトエンドポイント: `/logout`](logout-endpoint.md)

# マネージドログインのサインインエンドポイント: `/login`
<a name="login-endpoint"></a>

ログインエンドポイントは認証サーバーであり、[認可エンドポイント](authorization-endpoint.md)からのリダイレクト先です。ID プロバイダーを指定しない場合、マネージドログインへのエントリポイントとなります。ログインエンドポイントへのリダイレクトを生成すると、ログインページにロードされ、ユーザーにクライアントに設定されている認証オプションが提示されます。

**注記**  
ログインエンドポイントは、マネージドログインのコンポーネントです。アプリケーションで、ログインエンドポイントにリダイレクトするフェデレーションページとマネージドログインページを呼び出します。ユーザーがログインエンドポイントに直接アクセスすることはベストプラクティスではありません。

## GET/ログイン
<a name="get-login"></a>

`/login` エンドポイントは、ユーザーの最初のリクエストの `HTTPS GET` のみをサポートします。アプリは Chrome や Firefox などのブラウザでページを呼び出します。[認可エンドポイント](authorization-endpoint.md) から `/login` にリダイレクトすると、最初のリクエストで指定したすべてのパラメータが渡されます。ログインエンドポイントは authorize エンドポイントのすべてのリクエストパラメータをサポートします。ログインエンドポイントに直接アクセスすることもできます。ベストプラクティスとしては、すべてのユーザーのセッションを `/oauth2/authorize` から開始してください。

**例 – ユーザーにサインインするよう促す**

この例では、ログイン画面が表示されます。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/login?
                response_type=code&
                client_id=ad398u21ijw3s9w3939&
                redirect_uri=https://YOUR_APP/redirect_uri&
                state=STATE&
                scope=openid+profile+aws.cognito.signin.user.admin
```

**例 – 応答**  
認証サーバーは認可コードとステートを伴ってアプリにリダイレクトします。サーバーは、コードとステートをフラグメントではなく、クエリ文字列のパラメータで返す必要があります。

```
HTTP/1.1 302 Found
                    Location: https://YOUR_APP/redirect_uri?code=AUTHORIZATION_CODE&state=STATE
```

## ユーザーが開始したサインインリクエスト
<a name="post-login"></a>

ユーザーは、`/login` エンドポイントをロードした後で、ユーザー名とパスワードを入力して **[サインイン]** を選択できます。これを行うと、`GET` リクエストと同じヘッダーリクエストパラメータと、ユーザー名、パスワード、およびデバイスのフィンガープリントを含むリクエスト本文で、`HTTPS POST` リクエストが生成されます。

# マネージドログインのサインアウトエンドポイント: `/logout`
<a name="logout-endpoint"></a>

`/logout` エンドポイントは、リダイレクションエンドポイントです。ユーザーをサインアウトし、アプリケーションクライアントの認可サインアウト URL または `/login` エンドポイントにリダイレクトする必要があります。`/logout` エンドポイントへの GET リクエストで使用可能なパラメータは、Amazon Cognito マネージドログインのユースケースに合わせて調整されます。

ログアウトエンドポイントは、顧客とのインタラクティブなユーザーセッション用のフロントエンドウェブアプリケーションです。アプリケーションは、このエンドポイントと他のマネージドログインのエンドポイントを、ユーザーのブラウザで呼び出す必要があります。

ユーザーをマネージドログインにリダイレクトして再度サインインさせるには、リクエストに `redirect_uri` パラメータを追加します。`redirect_uri` パラメータを含む `logout` リクエストには、`client_id`、`response_type`、`scope` などの [ログインエンドポイント](login-endpoint.md) への後続のリクエスト用のパラメータも含める必要があります。

選択したページにユーザーをリダイレクトするには、アプリクライアントに**許可されているサインアウト URL** を追加します。`logout` エンドポイントへのユーザーのリクエストに、`logout_uri` および `client_id` パラメーターを追加します。`logout_uri` の値が、**許可されているサインアウト URL** の 1 つである場合、Amazon Cognito はユーザーをその URL にリダイレクトします。

SAML 2.0 IdP のシングルログアウト (SLO) を使用すると、Amazon Cognito は、まずユーザーを IdP 設定で定義した SLO エンドポイントにリダイレクトします。IdP がユーザーを `saml2/logout` にリダイレクトすると、Amazon Cognito はリクエストから `redirect_uri` または `logout_uri` へのリダイレクトをもう 1 回返します。詳細については、「[シングルサインアウトで SAML ユーザーをサインアウトする](cognito-user-pools-saml-idp-sign-out.md)」を参照してください。

ログアウトエンドポイントは、OIDC またはソーシャル ID プロバイダー (IdP) からユーザーにサインアウトしません。外部 IdP を使用してセッションからユーザーをサインアウトするには、そのプロバイダーのサインアウトページにユーザーを誘導します。

## GET /logout
<a name="get-logout"></a>

`/logout` エンドポイントは `HTTPS GET` のみをサポートします。ユーザープールクライアントは通常、このリクエストをシステムブラウザ経由で行います。ブラウザは通常、Android では Custom Chrome Tab、iOS では Safari View Control です。

### リクエストパラメータ
<a name="get-logout-request-parameters"></a>

*client\$1id*  
アプリのアプリクライアント ID。アプリクライアント ID を取得するには、ユーザープールにアプリを登録する必要があります。詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。  
必須。

*logout\$1uri*  
*logout\$1uri* パラメータを使用して、ユーザーをカスタムサインアウトページにリダイレクトします。この値を、ユーザーがサインアウトした後にユーザーをリダイレクトするアプリクライアントの**[sign-out URL]** (サインアウト URL) に設定します。*logout\$1uri* は、*client\$1id* パラメータでのみ使用してください。詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。  
*logout\$1uri* パラメータを使用して、ユーザーを別のアプリクライアントのサインインページにリダイレクトすることもできます。他のアプリクライアントのサインインページを、アプリクライアントで**許可されたコールバック URL** として設定します。`/logout` エンドポイントへのリクエストで、*logout\$1uri* パラメータの値を URL エンコードされたサインインページに設定します。  
Amazon Cognito では、`/logout` エンドポイントへのリクエストに *logout\$1uri* または *redirect\$1uri* パラメータのいずれかが必要です。*logout\$1uri* パラメータは、ユーザーを別のウェブサイトにリダイレクトします。`/logout` エンドポイントへのリクエストに *logout\$1uri* パラメータと *redirect\$1uri* パラメータの両方が含まれている場合、Amazon Cognito は *logout\$1uri* パラメータのみを使用し、*redirect\$1uri* パラメータをオーバーライドします。

*`nonce`*  
(オプション) リクエストに追加できるランダムな値。指定したノンス値は、Amazon Cognito が発行する ID トークンに含まれます。リプレイ攻撃を防ぐために、アプリは ID トークンの `nonce` クレームを検査し、生成したものと比較することができます。`nonce` クレームの詳細については、「[OpenID Connect standard](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation)」(OpenID Connect 標準) の「*ID token validation*」(ID トークンの検証) を参照してください。

**redirect\$1uri**  
*redirect\$1uri* パラメータを使用して、ユーザーをサインインページにリダイレクトし、認証を行います。その値を、サインインした後にユーザーをリダイレクトするアプリクライアントの**[Allowed callback URL]** (許可されたコールバック URL) に設定します。`/login` エンドポイントに渡す *client\$1id*、*scope*、*state*、*response\$1type* パラメータを追加します。  
Amazon Cognito では、`/logout` エンドポイントへのリクエストに *logout\$1uri* または *redirect\$1uri* パラメータのいずれかが必要です。ユーザーを `/login` エンドポイントにリダイレクトして再認証し、トークンをアプリケーションに渡すには、*redirect\$1uri* パラメータを追加します。`/logout` エンドポイントへのリクエストに *logout\$1uri* パラメータと *redirect\$1uri* パラメータの両方が含まれている場合、Amazon Cognito は *redirect\$1uri* パラメータをオーバーライドし、*logout\$1uri* パラメータのみを処理します。

*response\$1type*  
ユーザーがサインインした後に Amazon Cognito から受信する OAuth 2.0 レスポンス。`code` と `token` は、*response\$1type* パラメータの有効な値です。  
*redirect\$1uri* パラメータを使用する場合は必須です。

*state*  
アプリケーションがリクエストに *state* パラメータを追加すると、Amazon Cognito は、`/oauth2/logout` エンドポイントはユーザーをリダイレクトする際に、その値をアプリケーションに返します。  
この値をリクエストに追加して [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) 攻撃から保護します。  
`state` パラメータの値を、URL でエンコードされた JSON 文字列に設定することはできません。この形式に一致する文字列を `state` パラメータで渡すには、文字列を base64 にエンコードし、アプリケーション内でデコードします。  
*redirect\$1uri* パラメータを使用する場合は強くお勧めします。

*scope*  
*redirect\$1uri* パラメータを使用してサインアウトした後に Amazon Cognito にリクエストする OAuth 2.0 スコープ。Amazon Cognito は、`/logout` エンドポイントへのリクエストの *scope* パラメータを使用してユーザーを `/login` エンドポイントにリダイレクトします。  
*redirect\$1uri* パラメータを使用する場合は任意。*scope* パラメータを含めない場合、Amazon Cognito は *scope* パラメータを使用してユーザーを `/login` エンドポイントにリダイレクトします。Amazon Cognito がユーザーをリダイレクトし、`scope` に自動的にデータを入力する場合、パラメータには、アプリクライアントに対して許可されているすべてのスコープが含まれます。

### リクエストの例
<a name="get-logout-request-sample"></a>

**例: ログアウトしてユーザーをクライアントにリダイレクトする**

Amazon Cognito は、リクエストに `logout_uri` と `client_id` が含まれている場合、他のすべてのリクエストパラメータを無視して、値が `logout_uri` である URL にユーザーセッションをリダイレクトします。この URL は、アプリケーションクライアントの承認済みサインアウト URL である必要があります。

次は、サインアウトと `https://www.example.com/welcome` へのリダイレクトのリクエスト例です。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/logout?
  client_id=1example23456789&
  logout_uri=https%3A%2F%2Fwww.example.com%2Fwelcome
```

**例 – ログアウトして別のユーザーとしてサインインするよう指示する**

リクエストに `logout_uri` が省略されているが、認可エンドポイントへの正しい形式のリクエストを構成するパラメータが指定されている場合、Amazon Cognito はユーザーをマネージドサインインにリダイレクトします。ログアウトエンドポイントは、元のリクエストのパラメータをリダイレクト先に追加します。

ログアウトリクエストに追加する他のパラメータは、[リクエストパラメータ](#get-logout-request-parameters)のリストに含める必要があります。例えば、ログアウトエンドポイントは、`identity_provider` パラメータまたは `idp_identifier` パラメータを使用した自動 IdP リダイレクトをサポートしていません。ログアウトエンドポイントへのリクエストの `redirect_uri` パラメータは、サインアウト URL ではなく、認可エンドポイントにパススルーするサインイン後の URL です。

次に示すのは、ユーザーをサインアウトしてサインインページにリダイレクトし、サインイン後に認可コードを `https://www.example.com` に提供するリクエストの例です。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/logout?
  response_type=code&
  client_id=1example23456789&
  redirect_uri=https%3A%2F%2Fwww.example.com&
  state=example-state-value&
  nonce=example-nonce-value&
  scope=openid+profile+aws.cognito.signin.user.admin
```

# ID プロバイダーと依拠しているパーティーエンドポイント
<a name="federation-endpoints"></a>

*フェデレーションエンドポイント*は、ユーザープールで使用される認証標準のいずれかの目的を果たすユーザープールエンドポイントです。これには、ID プロバイダーと依拠しているパーティーの両方として、ユーザープールロール用の SAML ACS URLs、OIDC 検出エンドポイント、サービスエンドポイントが含まれます。フェデレーションエンドポイントは、認証フローを開始し、IdP から認証の証拠を受け取り、クライアントにトークンを発行します。これらは IdP、アプリケーション、管理者とインタラクションを行いますが、ユーザーとはインタラクションを行いません。

このページの後に続くページ全体のトピックには、ユーザープールにドメインを追加したときに利用可能になる OAuth 2.0 および OIDC プロバイダーエンドポイントに関する詳細が記載されています。次のチャートは、すべてのフェデレーションエンドポイントのリストです。

[ユーザープールドメイン](cognito-user-pools-assign-domain.md)の例は以下のとおりです。

1. プレフィックスドメイン: `mydomain.auth.us-east-1.amazoncognito.com`

1. カスタムドメイン: `auth.example.com`


**ユーザープールのフェデレーションエンドポイント**  

| エンドポイント URL | 説明 | アクセス方法 | 
| --- | --- | --- | 
| https://ユーザープールのドメイン/oauth2/authorize | ユーザーをマネージドログインにリダイレクトするか、IdP でサインインするようにリダイレクトします。 | ユーザー認証を開始するためにカスタマーブラウザで呼び出されます。「[認可エンドポイント](authorization-endpoint.md)」を参照してください。 | 
| https://ユーザープールのドメイン/oauth2/token | 認可コードまたはクライアント認証情報リクエストに基づいてトークンを返します。 | トークンを取得するようにアプリケーションからリクエストされました。「[トークンエンドポイント](token-endpoint.md)」を参照してください。 | 
| https://ユーザープールのドメイン/oauth2/userInfo | OAuth 2.0 のスコープとアクセストークンのユーザー ID に基づいてユーザー属性を返します。 | ユーザープロファイルを取得するようにアプリケーションからリクエストされました。「[userInfo エンドポイント](userinfo-endpoint.md)」を参照してください。 | 
| https://ユーザープールのドメイン/oauth2/revoke | 更新トークンと関連するアクセストークンを取り消します。 | トークンを取り消すようにアプリケーションからリクエストされました。「[エンドポイントの取り消し](revocation-endpoint.md)」を参照してください。 | 
| https://cognito-idp.リージョン.amazonaws.com/ユーザープール ID/.well-known/openid-configuration | ユーザープールの OIDC アーキテクチャのディレクトリ。[1](#cognito-federation-oidc-discovery-note) | ユーザープール発行者のメタデータを見つけるようにアプリケーションからリクエストされました。 | 
| https://cognito-idp.リージョン.amazonaws.com/ユーザープール ID/.well-known/jwks.json | Amazon Cognito トークンの検証に使用できるパブリックキー。[2](#cognito-federation-oidc-jwks-note) | JWT を検証するようにアプリケーションからリクエストされました。 | 
| https://ユーザープールドメイン/oauth2/idpresponse | ソーシャル ID プロバイダーは、認可コードを使用してユーザーをこのエンドポイントにリダイレクトする必要があります。Amazon Cognito は、フェデレーションユーザーを認証する際に、このコードをトークンに引き換えます。 | OIDC IdP サインインから IdP クライアントのコールバック URL としてリダイレクトされます。 | 
| https://ユーザープールドメイン/saml2/idpresponse | SAML 2.0 ID プロバイダーと統合するためのアサーションコンシューマーサービス (ACS) の URL。 | SAML 2.0 IdP から ACS URL として、または IdP が開始したサインインの発信元ポイントとしてリダイレクトされます[3](#cognito-federation-idp-init-note)。 | 
| https://ユーザープールのドメイン/saml2/logout | SAML 2.0 ID プロバイダーと統合するための[シングルログアウト](cognito-user-pools-saml-idp-sign-out.md#cognito-user-pools-saml-idp-sign-out.title) (SLO) の URL。 | シングルログアウト (SLO) URL として SAML 2.0 IdP からリダイレクトされました。POST バインディングのみを受け入れます。 | 

1 `openid-configuration`ドキュメントは、エンドポイントを OIDC および OAuth2 仕様に準拠させるための追加情報を反映するために、随時更新される場合があります。

2 `jwks.json` JSON ファイルは、新しいパブリックトークン署名キーを反映するために、随時更新される場合があります。

3 IdP が開始した SAML サインインの詳細については、「」を参照してください[IdP が開始した SAML サインインを実装する](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-SAML-session-initiation-idp-initiation)。

OpenID および OAuth 標準の詳細については、「[OpenID 1.0](http://openid.net/specs/openid-connect-core-1_0.html)」および「[OAuth 2.0](https://tools.ietf.org/html/rfc6749)」を参照してください。

**Topics**
+ [リダイレクトエンドポイントと認可エンドポイント](authorization-endpoint.md)
+ [トークン発行者エンドポイント](token-endpoint.md)
+ [ユーザー属性エンドポイント](userinfo-endpoint.md)
+ [トークン取り消しエンドポイント](revocation-endpoint.md)
+ [IdP SAML アサーションエンドポイント](saml2-idpresponse-endpoint.md)

# リダイレクトエンドポイントと認可エンドポイント
<a name="authorization-endpoint"></a>

`/oauth2/authorize` エンドポイントは、2 つのリダイレクト先をサポートするリダイレクトエンドポイントです。URL に `identity_provider` または `idp_identifier` のパラメータを含めると、ユーザーはその ID プロバイダー (IdP) のサインインページにそのままリダイレクトされます。それ以外の場合は、リクエストに含まれるものと同じ URL パラメータを持つ [ログインエンドポイント](login-endpoint.md) にリダイレクトされます。

認可エンドポイントは、マネージドログインまたは IdP サインインページのどちらかにリダイレクトされます。このエンドポイントにおけるユーザーセッションの送信先は、ユーザーがブラウザで直接操作する必要があるウェブページです。

認可エンドポイントを使用するには、ユーザープールに以下のユーザープールの詳細に関する情報を提供するパラメータを使用して、ユーザーのブラウザを `/oauth2/authorize` で呼び出します。
+ サインインするアプリクライアント。
+ 終了させたいコールバック URL。
+ ユーザーのアクセストークンでリクエストする OAuth 2.0 スコープ。
+ サインインに使用するサードパーティーの IdP (任意)。

また、Amazon Cognito が受信クレームの検証に使用する `state` および `nonce` パラメータを提供することもできます。

## GET `/oauth2/authorize`
<a name="get-authorize"></a>

`/oauth2/authorize` エンドポイントは `HTTPS GET` のみをサポートします。アプリは通常、このリクエストをユーザーのブラウザで開始します。`/oauth2/authorize` エンドポイントへのリクエストは、HTTPS でのみ行うことができます。

OpenID Connect (OIDC) 標準における認可エンドポイントの定義の詳細については、「[Authorization Endpoint](http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthorizationEndpoint)」(認可エンドポイント) を参照してください。

### リクエストパラメータ
<a name="get-authorize-request-parameters"></a>

**`response_type`**  
必須。  
レスポンスのタイプ。`code` または `token` を指定する必要があります。  
`response_type` が `code` のリクエストに成功すると、認可コード付与を返します。認可コード付与とは、Amazon Cognito がリダイレクト URL に追加する `code` パラメータです。アプリは [トークンエンドポイント](token-endpoint.md) と、アクセス、ID、更新の各トークンとコードを交換することができます。セキュリティ上のベストプラクティスとして、またユーザーに更新トークンを受け取るには、アプリで認可コード付与を使用します。  
`response_type` が `token` のリクエストに成功すると、暗黙的な付与を返します。暗黙的な付与とは、Amazon Cognito がリダイレクト URL に追加する ID とアクセストークンのことです。暗黙的な付与は、トークンと潜在的な識別情報をユーザーに公開するため、安全性が低くなります。アプリクライアントの設定で、暗黙的な付与のサポートを無効にできます。

**`client_id`**  
必須。  
アプリクライアント ID。  
`client_id` の値は、リクエストを行うユーザープール内のアプリクライアントの ID である必要があります。アプリクライアントは、Amazon Cognito ローカルユーザーまたは少なくとも 1 つのサードパーティー IdP によるサインインをサポートしている必要があります。

**`redirect_uri`**  
必須。  
Amazon Cognito がユーザーを認証した後、認証サーバーによってブラウザがリダイレクトされる URL です。  
リダイレクト Uniform Resource Identifier (URI) には次の属性が必要です。  
+ 絶対 URI である。
+ URI を事前にクライアントに登録しておく必要があります。
+ フラグメントコンポーネントが含まれていない。
「[OAuth 2.0 - リダイレクトエンドポイント](https://tools.ietf.org/html/rfc6749#section-3.1.2)」を参照してください。  
Amazon Cognito では、テスト目的のコールバック URL として設定できる `http://localhost` を除き、リダイレクト URI に HTTPS を使用することが必要です。  
Amazon Cognito では、`myapp://example` のようなアプリのコールバック URL もサポートしています。

**`state`**  
オプション、推奨。  
アプリがリクエストに *state* パラメータを追加すると、Amazon Cognito は`/oauth2/authorize` エンドポイントはユーザーをリダイレクトする際に、その値をアプリに返します。  
この値をリクエストに追加して [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) 攻撃から保護します。  
`state` パラメータの値を、URL でエンコードされた JSON 文字列に設定することはできません。この形式に一致する文字列を `state` パラメータで渡すには、文字列を base64 にエンコードし、アプリケーション内でデコードします。

**`identity_provider`**  
オプション。  
このパラメータを追加して、マネージドログインをバイパスし、ユーザーをプロバイダーのサインインページにリダイレクトします。*identity\$1provider* パラメータの値はユーザープールに表示される ID プロバイダー (IdP) の名前です。  
+ ソーシャルプロバイダーの場合、*identity\$1provider* 値として `Facebook`、`Google`、`LoginWithAmazon`、`SignInWithApple` を使用できます。
+ Amazon Cognito ユーザープールの場合、値 `COGNITO` を使用します。
+ SAML 2.0 および OpenID Connect (OIDC) ID プロバイダー (IdP) の場合は、ユーザープールで IdP に割り当てた名前を使用します。

**`idp_identifier`**  
オプション。  
このパラメータを追加して、*identity\$1provider* 名の代替名を持つプロバイダーにリダイレクトします。Amazon Cognito コンソールの **[ソーシャルプロバイダーと外部プロバイダー**] メニューから、SAML 2.0 と OIDC IdP の識別子を入力できます。

**`scope`**  
オプション。  
クライアントに関連付けられているシステム予約されたスコープ、またはカスタムスコープの組み合わせにすることができます。スコープはスペースで区切る必要があります。システム予約されたスコープは `openid`、`email`、`phone`、`profile`、および `aws.cognito.signin.user.admin` です。使用されるスコープは、いずれもクライアントに関連付けられている必要があり、関連付けられていなければ、ランタイム時に無視されます。  
クライアントがスコープをリクエストしない場合、認証サーバーはクライアントに関連付けられているすべてのスコープを使用します。  
ID トークンは `openid` スコープがリクエストされた場合にのみ返されます。Amazon Cognito ユーザープールに対してアクセストークンを使用できるのは、`aws.cognito.signin.user.admin` スコープがリクエストされている場合のみです。`phone`、`email`、および `profile` スコープは、`openid` スコープがリクエストされた場合にのみリクエストできます。これらのスコープは ID トークン内でクレームを記述します。

**`code_challenge_method`**  
オプション。  
チャレンジの生成に使用したハッシュプロトコル。[PKCE RFC](https://tools.ietf.org/html/rfc7636) では S256 および plain の 2 つのメソッドが定義されていますが、Amazon Cognito 認証サーバーでは S256 のみがサポートされています。

**`code_challenge`**  
オプション。  
`code_verifier` から生成した Proof of Key Code Exchange (PKCE) チャレンジ。詳細については、「[認可コード許可での PKCE の使用](using-pkce-in-authorization-code.md)」を参照してください。  
`code_challenge_method` パラメータを指定した場合にのみ必須です。

**`nonce`**  
オプション。  
リクエストに追加できるランダムな値。指定したノンス値は、Amazon Cognito が発行する ID トークンに含まれます。リプレイ攻撃を防ぐために、アプリは ID トークンの `nonce` クレームを検査し、生成したものと比較することができます。`nonce` クレームの詳細については、「[OpenID Connect standard](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation)」(OpenID Connect 標準) の「*ID token validation*」(ID トークンの検証) を参照してください。

**`lang`**  
オプション。  
ユーザーインタラクティブページを表示する言語。マネージドログインページはローカライズできますが、ホストされた UI (クラシック) ページはローカライズできません。詳細については、「[マネージドログインのローカリゼーション](cognito-user-pools-managed-login.md#managed-login-localization)」を参照してください。

**`login_hint`**  
オプション。  
認可サーバーに渡すユーザー名プロンプト。ユーザーからユーザー名、E メールアドレス、または電話番号を収集し、送信先プロバイダーがユーザーのサインイン名を事前に入力できるようにできます。`oauth2/authorize` エンドポイントに `login_hint` パラメータを送信し、`idp_identifier` または `identity_provider` パラメータを送信しない場合、マネージドログインはユーザー名フィールドにヒント値を入力します。また、このパラメータを [ログインエンドポイント](login-endpoint.md) に渡し、ユーザー名値を自動的に入力することもできます。  
認可リクエストが OIDC IdPs、Amazon Cognito はそのサードパーティーオーソライザーにリクエストに`login_hint`パラメータを追加します。ログインヒントを SAML、Apple、Login With Amazon、Google、または Facebook (Meta) IdPs に転送することはできません。

**`prompt`**  
オプション。  
既存のセッションの認証動作を制御する OIDC パラメータ。クラシックのホストされた UI ではなく、マネージドログインのブランディングバージョンでのみ使用できます。OIDC 仕様の詳細については、「[認証リクエスト](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest)」を参照してください。値 `none` と `login` は、ユーザープールの認証動作に影響します。  
ユーザーがサードパーティプロバイダーによる認証を選択した場合、Amazon Cognito は、`prompt` のすべての値 (`none` を除く) を IdP に転送します。これは、ユーザーがアクセスする URL に `identity_provider` パラメータまたは `idp_identifier` パラメータが含まれている場合、または認可サーバーがユーザーを[ログインエンドポイント](login-endpoint.md)にリダイレクトし、ユーザーが使用可能なボタンから IdP を選択した場合に当てはまります。  
**プロンプトパラメータ値**    
`prompt=none`  
Amazon Cognito は、有効な認証済みセッションを持つユーザーの認証をサイレントに継続します。このプロンプトを使用すると、ユーザーはユーザープール内の異なるアプリケーションクライアント間でサイレント認証を行うことができます。ユーザーがまだ認証されていない場合、認可サーバーは `login_required` エラーを返します。  
`prompt=login`  
Amazon Cognito では、既存のセッションがある場合でも、ユーザーに再認証を求めます。ユーザーの ID を再検証する場合は、この値を送信します。既存のセッションを持つ認証済みユーザーは、そのセッションを無効にすることなく、サインインに戻ることができます。既存のセッションを持つユーザーが再度サインインすると、Amazon Cognito は新しいセッション Cookie をユーザーに割り当てます。このパラメータは IdP に転送することもできます。このパラメータを受け入れる IdP は、ユーザーに新しい認証試行もリクエストします。  
`prompt=select_account`  
この値はローカルサインインには影響せず、IdP にリダイレクトするリクエストで送信する必要があります。認可リクエストに含めると、このパラメータは IdP リダイレクト先の URL パスに `prompt=select_account` を追加します。このパラメータを IdP がサポートしている場合、ユーザーはログインに使用するアカウントを選択するよう求められます。  
`prompt=consent`  
この値はローカルサインインには影響せず、IdP にリダイレクトするリクエストで送信する必要があります。認可リクエストに含めると、このパラメータは IdP リダイレクト先の URL パスに `prompt=consent` を追加します。このパラメータを IdP がサポートしている場合、IdP は、ユーザープールへのリダイレクト前に、ユーザーの同意をリクエストします。
リクエストから `prompt` パラメータを省略すると、マネージドログインはデフォルトの動作に従います。ブラウザに有効なマネージドログインセッション Cookie がない限り、ユーザーはサインインする必要があります。`prompt` の複数の値をスペース文字で区切って組み合わせることができます (例: `prompt=login consent`)。

**`resource`**  
オプション。  
`aud` クレーム内のアクセストークンにバインドするリソースの識別子。このパラメータを含めると、Amazon Cognito は値が URL であることを確認し、結果のアクセストークンのオーディエンスを、リクエストされたリソースに設定します。ユーザープールの[リソースサーバー](cognito-user-pools-define-resource-servers.md)は、URL 形式の識別子、または任意の URL を使用してリクエストできます。このパラメータの値は、`https://`、`http://localhost`、またはカスタム URL スキーム (`myapp://` など) で始める必要があります。  
リソースバインディングは [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) で定義されています。リソースサーバーとリソースバインディングの詳細については、「[リソースバインディング](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding)」を参照してください。

## 例: 認証コード付与
<a name="sample-authorization-code-grant"></a>

これは、認可コード付与のリクエストの例です。

次のリクエストは、ユーザーが `redirect_uri` 送信先でアプリケーションに渡す認可コードを取得するセッションを開始します。このセッションでは、ユーザー属性用スコープと、Amazon Cognito セルフサービス API オペレーションへのアクセス用スコープをリクエストします。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin
```

Amazon Cognito 認証サーバーは、認可コードとステートを伴ってリダイレクトしアプリに戻ります。認可コードは 5 分間有効です。

```
HTTP/1.1 302 Found
Location: https://www.example.com?code=a1b2c3d4-5678-90ab-cdef-EXAMPLE11111&state=abcdefg
```

## 例: PKCE を使用した認証コード付与
<a name="sample-authorization-code-grant-with-pkce"></a>

このフロー例では、[PKCE](using-pkce-in-authorization-code.md#using-pkce-in-authorization-code.title) を使用して認証コード付与を実行します。

このリクエストでは、`code_challenge` パラメータを追加します。トークンのコード交換を完了するには、`/oauth2/token` エンドポイントへのリクエストに `code_verifier` パラメータを含める必要があります。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin&
code_challenge_method=S256&
code_challenge=a1b2c3d4...
```

認可サーバーは、認証コードと状態をアプリケーションにリダイレクトします。アプリケーションは認証コードを処理し、トークンと交換します。

```
HTTP/1.1 302 Found
Location: https://www.example.com?code=a1b2c3d4-5678-90ab-cdef-EXAMPLE11111&state=abcdefg
```

## 例: `prompt=login` で再認証を要求する
<a name="sample-authorization-code-with-prompt-login"></a>

次のリクエストでは、既存のセッションがある場合でも、ユーザーに再認証を求める `prompt=login` パラメータを追加します。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin&
prompt=login
```

認可サーバーは、[ログインエンドポイント](login-endpoint.md)にリダイレクトし、再認証を要求します。

```
HTTP/1.1 302 Found Location: https://mydomain.auth.us-east-1.amazoncognito.com/login?response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com&state=abcdefg&scope=openid+profile+aws.cognito.signin.user.admin&prompt=login
```

## 例: `prompt=none` によるサイレント認証
<a name="sample-authorization-code-with-prompt-none"></a>

次のリクエストでは、ユーザーが有効なセッションを持っているかどうかをサイレントに確認する `prompt=none` パラメータを追加します。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin&
prompt=none
```

有効なセッションが存在しない場合、認可サーバーはリダイレクト URI にエラーを返します。

```
HTTP/1.1 302 Found Location: https://www.example.com?error=login_required&state=abcdefg
```

有効なセッションが存在する場合、認可サーバーは認証コードを返します。

```
HTTP/1.1 302 Found Location: https://www.example.com?code=AUTHORIZATION_CODE&state=abcdefg
```

## 例: リソースバインディングによる認証コード付与
<a name="sample-authorization-code-with-resource-binding"></a>

次のリクエストは、アクセストークンを特定のリソースサーバーにバインドする `resource` パラメータを追加します。結果としてのアクセストークンは、それが認証済みユーザーのリクエストのオーディエンスであることを、ターゲット API で検証するための条件を作成します。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=solar-system-data-api.example.com/asteroids.add&
resource=https://solar-system-data-api.example.com
```

認可サーバーは、`aud` クレームとして `https://solar-system-data-api.example.com` を持つアクセストークンを生成する認可コードを返します。

```
HTTP/1.1 302 Found Location: https://www.example.com?code=AUTHORIZATION_CODE&state=abcdefg
```

## 例: `openid` スコープなしのトークンの (暗黙的) 付与
<a name="sample-token-grant-without-openid-scope"></a>

このフロー例では、暗黙的な付与を生成し、JWT をユーザーのセッションに直接返します。

次のリクエストでは、認可サーバーに対して暗黙的な付与を求めます。ユーザープロファイルのセルフサービスオペレーションを認可するアクセストークン内のスコープをリクエストします。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=token&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin
```

認可サーバは、アクセストークンのみをアプリケーションにリダイレクトします。`openid` スコープがリクエストされなかったため、Amazon Cognito は ID トークンを返しません。また、Amazon Cognito はこのフローで更新トークンを返しません。

```
HTTP/1.1 302 Found
Location: https://example.com/callback#access_token=eyJra456defEXAMPLE&token_type=bearer&expires_in=3600&state=STATE
```

## 例: `openid` スコープ付きトークンの (暗黙的) 付与
<a name="sample-token-grant-with-openid-scope"></a>

このフロー例では、暗黙的な付与を生成し、トークンをユーザーのブラウザに返します。

次のリクエストでは、認可サーバーに対して暗黙的な付与を求めます。ユーザー属性とセルフサービスオペレーションへのアクセスを認可するアクセストークン内のスコープをリクエストします。

```
GET
https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize? 
response_type=token& 
client_id=1example23456789& 
redirect_uri=https://www.example.com& 
state=abcdefg&
scope=aws.cognito.signin.user.admin+openid+profile
```

認可サーバーは、アクセストークンと ID トークンをアプリケーションにリダイレクトします (`openid` スコープが含まれていたため)。

```
HTTP/1.1 302 Found
Location: https://www.example.com#id_token=eyJra67890EXAMPLE&access_token=eyJra12345EXAMPLE&token_type=bearer&expires_in=3600&state=abcdefg
```

## 否定応答の例
<a name="get-authorize-negative"></a>

Amazon Cognito はリクエストを拒否する場合があります。否定リクエストには、HTTP エラーコードと、リクエストパラメータの修正に使用できる説明が付属しています。否定応答の例を次に示します。
+ `client_id` と `redirect_uri` が有効であるが、リクエストパラメータが正しくフォーマットされていない場合、認証サーバーはエラーをクライアントの `redirect_uri` にリダイレクトし、URL パラメータにエラーメッセージを追加します。形式が正しくない場合の例を以下に示します。
  + リクエストには `response_type` パラメータが含まれていません。
  + 認可リクエストは `code_challenge` パラメータを提供しましたが、`code_challenge_method` パラメータは提供していません。
  + `code_challenge_method` パラメータの値が `S256` でありません。

  以下は、形式が正しくないリクエスト例に対する応答です。

  ```
  HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request
  ```
+ クライアントが `response_type` で `code` または `token` をリクエストしたが、これらのリクエストのアクセス許可を持っていないという場合は、以下にあるように、Amazon Cognito 認可サーバーが `unauthorized_client` をクライアントの `redirect_uri` に返します。

  ```
  HTTP 1.1 302 Found Location: https://client_redirect_uri?error=unauthorized_client
  ```
+  クライアントが無効、不明、または有効ではない形式のスコープをリクエストする場合は、以下にあるように、Amazon Cognito 認可サーバーが `invalid_scope` をクライアントの `redirect_uri` に返します。

  ```
  HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_scope
  ```
+ サーバーで予期しないエラーが発生した場合は、認証サーバーがクライアントの `redirect_uri` に `server_error` を返します。HTTP 500 エラーはクライアントに送信されないので、ユーザーのブラウザにエラーが表示されません。認可サーバーは次のエラーを返します。

  ```
  HTTP 1.1 302 Found Location: https://client_redirect_uri?error=server_error
  ```
+ Amazon Cognito がサードパーティー ID プロバイダーとのフェデレーションを通じて認証するときは、以下のような接続問題が発生する場合があります。
  + IdP からトークンをリクエストしているときに接続タイムアウトが発生した場合、認証サーバーは以下のようにエラーをクライアントの `redirect_uri` にリダイレクトします。

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Timeout+occurred+in+calling+IdP+token+endpoint
    ```
  + ID トークン検証のための `jwks_uri` エンドポイントの呼び出し時に接続タイムアウトが発生する場合、認証サーバーは以下のようにエラーをクライアントの `redirect_uri` にリダイレクトします。

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=error_description=Timeout+in+calling+jwks+uri
    ```
+ サードパーティー IdP による認証がなされた場合、プロバイダーはエラー応答を返すことがあります。これは、設定エラーのほか、次のような理由が原因である可能性があります。
  + 他のプロバイダーからエラーレスポンスを受け取った場合、認証サーバーは以下のようにエラーをクライアントの `redirect_uri` にリダイレクトします。

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=[IdP name]+Error+-+[status code]+error getting token
    ```
  + Google からエラーレスポンスを受け取った場合、認証サーバーは以下のようにエラーをクライアントの `redirect_uri` にリダイレクトします。

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Google+Error+-+[status code]+[Google-provided error code]
    ```
+ Amazon Cognito が外部 IdP への接続中に通信プロトコルで例外を検出した場合、認証サーバーは次のいずれかのメッセージでエラーをクライアントの `redirect_uri` にリダイレクトします。
  + 

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Connection+reset
    ```
  + 

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Read+timed+out
    ```

# トークン発行者エンドポイント
<a name="token-endpoint"></a>

`/oauth2/token` の OAuth 2.0 [トークンエンドポイント](https://www.rfc-editor.org/rfc/rfc6749#section-3.2)は、認証コードとクライアント認証情報の付与フローを完了するアプリケーションに JSON ウェブトークン (JWT) を発行します。これらのトークンは、ユーザープールによる認証の最終結果です。これには、ユーザー (ID トークン）、ユーザーのアクセスレベル (アクセストークン）、サインインセッションを継続するユーザーの権限 (更新トークン) に関する情報が含まれます。OpenID Connect (OIDC) 依拠しているパーティライブラリは、このエンドポイントへのリクエストとこのエンドポイントからの応答ペイロードを処理します。トークンは、検証可能な認証証拠、プロファイル情報、バックエンドシステムへのアクセスメカニズムを提供します。

ユーザープール OAuth 2.0 認可サーバーは、トークンエンドポイントから以下のタイプのセッションに JSON ウェブトークン (JWT) を発行します。

1. 認可コード付与のリクエストを完了したユーザー。コードの引き換えに成功すると、ID、アクセス、更新の各トークンが返されます。

1. クライアント認証情報の付与を完了したマシンツーマシン (M2M) セッション。クライアントシークレットによる認可が成功すると、アクセストークンが返されます。

1. 以前にサインインして、更新トークンを受け取っていたユーザー。更新トークン認証は、新しい ID トークンとアクセストークンを返します。
**注記**  
マネージドログインまたはフェデレーションを通じて認証コード付与を使用してサインインするユーザーは、トークンエンドポイントからトークンを常に更新できます。API オペレーションの `InitiateAuth` と `AdminInitiateAuth` でサインインし、[記憶されているデバイス](amazon-cognito-user-pools-device-tracking.md)がユーザープールでアクティブで*ない*ときにトークンエンドポイントでトークンを更新できるユーザー。記憶されたデバイスがアクティブな場合は、アプリケーションクライアントで[関連する API または SDK トークン更新オペレーション](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-api)を使用してトークンを更新します。

ユーザープールにドメインを追加すると、トークンエンドポイントが公開されます。HTTP POST リクエストを受け入れます。アプリケーションのセキュリティを最適化するには、認可コードのサインインイベントで PKCE を使用します。PKCE は、認可コードを渡すユーザーが、認証したユーザーと同じであることを確認します。PKCE の詳細については、[IETF RFC 7636](https://datatracker.ietf.org/doc/html/rfc7636) を参照してください。

ユーザープールのアプリケーションクライアントと付与タイプ、クライアントシークレット、許可されているスコープ、クライアント ID の詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。M2M 認可、クライアント認証情報の付与、アクセストークンスコープによる認可の詳細については、「[スコープ、M2M、リソースサーバー](cognito-user-pools-define-resource-servers.md)」を参照してください。

アクセストークンからユーザーに関する情報を取得するには、それを [userInfo エンドポイント](userinfo-endpoint.md) または [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) API リクエストに渡します。アクセストークンには、これらのリクエストに適したスコープが含まれている必要があります。

## トークンエンドポイントへの POST リクエストをフォーマットする
<a name="post-token"></a>

`/oauth2/token` エンドポイントは `HTTPS POST` のみをサポートします。このエンドポイントはユーザーインタラクティブではありません。トークンリクエストは、アプリケーションの [OpenID Connect (OIDC) ライブラリ](https://openid.net/developers/certified-openid-connect-implementations/)を使用して処理されます。

トークンエンドポイントは `client_secret_basic` と `client_secret_post` をサポートしています。OIDC 仕様の詳細については、「[クライアント認証](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication)」を参照してください。OpenID Connect 仕様のトークンエンドポイントの詳細については、「[トークンエンドポイント](http://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint)」を参照してください。

### ヘッダーのリクエストパラメータ
<a name="post-token-request-parameters"></a>

リクエストのヘッダーで、以下のパラメータをトークンエンドポイントに渡すことができます。

**`Authorization`**  
クライアントがシークレットで発行された場合、クライアントは、認可ヘッダー内の `client_id` および `client_secret` を `client_secret_basic` HTTP 認可として渡す必要があります。また、`client_id` と `client_secret` を `client_secret_post` 認可としてリクエスト本文に含めることもできます。  
認可ヘッダー文字列は [Basic](https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side) `Base64Encode(client_id:client_secret)` です。次の例は、アプリケーションクライアント `djc98u3jiedmi283eu928` のクライアントシークレット `abcdef01234567890` が付いた認可ヘッダーで、文字列 `djc98u3jiedmi283eu928:abcdef01234567890` の Base64 エンコードされたバージョンを使用するものです。  

```
Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
```

**`Content-Type`**  
このパラメータの値を `'application/x-www-form-urlencoded'` に設定します。

### 本文のリクエストパラメータ
<a name="post-token-request-parameters-in-body"></a>

トークンエンドポイントへのリクエスト本文で `x-www-form-urlencoded` 形式を使用してリクエストできるパラメータは、以下のとおりです。

**`grant_type`**  
*必須。*  
リクエストする OIDC 付与のタイプ。  
`authorization_code`、`refresh_token`、または `client_credentials` を指定する必要があります。以下の条件下で、トークンエンドポイントに対してカスタムスコープのアクセストークンをリクエストできます。  
+ アプリケーションクライアント設定で、リクエストされたスコープを有効にしました。
+ クライアントシークレットを使用してアプリケーションクライアントを設定しました。
+ アプリケーションクライアントでクライアント認証情報の付与を有効にします。
トークンエンドポイントは、`grant_type` が `authorization_code` である場合にのみ、更新トークンを返します。

**`client_id`**  
*オプション。`Authorization` ヘッダーでアプリケーションクライアント ID を指定する場合は、必須ではありません。*  
ユーザープール内のアプリクライアントの ID。ユーザーを認証したものと同じアプリケーションクライアントを指定します。  
クライアントがパブリックで、シークレットがない場合、または `client_secret_post` 認可で `client_secret` を使用している場合は、このパラメータを指定する必要があります。

**`client_secret`**  
*オプション。`Authorization` ヘッダーでクライアントシークレットを指定する場合や、アプリケーションクライアントにシークレットがない場合は、必須ではありません。*  
アプリケーションクライアントにシークレットがある場合は、`client_secret_post` 認可用のアプリケーションクライアントシークレット。

**`scope`**  
*オプション*。  
アプリケーションクライアントに関連付けられている任意のスコープの組み合わせを指定できます。Amazon Cognito は、リクエストされたアプリケーションクライアントで許可されていないリクエスト内のスコープを無視します。このリクエストパラメータを指定しない場合、認可サーバーは、アプリケーションクライアント設定で有効にしたすべての認可スコープを含むアクセストークン `scope` クレームを返します。リクエストされたアプリケーションクライアントで許可されているスコープとして、標準スコープ、リソースサーバーからのカスタムスコープ、`aws.cognito.signin.user.admin` ユーザーセルフサービススコープのいずれかをリクエストできます。

**`redirect_uri`**  
*オプション。クライアント認証情報の付与には必須ではありません。*  
`/oauth2/authorize` で `authorization_code` を取得するために使用されたものと同じ `redirect_uri` である必要があります。  
`grant_type` が `authorization_code` である場合、このパラメータを指定する必要があります。

**`refresh_token`**  
*オプション。ユーザーが既に更新トークンを持っていて、新しい ID トークンとアクセストークンを取得する場合にのみ使用します。*  
ユーザーのセッション用に新しいアクセストークンと ID トークンを生成するには、`refresh_token` の値を、リクエストされたアプリケーションクライアントが発行した有効な更新トークンに設定します。  
[更新トークンのローテーション](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation)がアクティブな場合は、新しい ID トークンおよびアクセストークンとともに新しい更新トークンを返します。それ以外の場合は、ID トークンとアクセストークンのみを返します。元のアクセストークンが [API リソースにバインド](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding)されていた場合、新しいアクセストークンは、リクエストされた API URL を `aud` クレーム内に保持します。

**`code`**  
*オプション。認証コード付与でのみ必須です。*  
認証コード付与からの認証コード。認可リクエストに `authorization_code` の `grant_type` が含まれている場合は、このパラメータを指定する必要があります。

**`aws_client_metadata`**  
*オプション*。  
[Machine to Machine (M2M)](cognito-user-pools-define-resource-servers.md) 認可フローで、[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)に渡す情報。アプリケーションはセッションに関するコンテキスト情報を収集し、このパラメータで渡すことができます。URL エンコードされた JSON 形式で `aws_client_metadata` を渡すと、Amazon Cognito はそれをトリガー Lambda 関数への入力イベントに含めます。トークン生成前トリガーイベントバージョンまたはグローバル Lambda トリガーバージョンは、バージョン 3 以降に設定する必要があります。Amazon Cognito は認証コードとクライアント認証情報の M2M フローでこのエンドポイントへのリクエストを受け入れますが、ユーザープールは、クライアント認証情報リクエストのトークン生成前トリガーにのみ `aws_client_metadata` を渡します。

**`code_verifier`**  
オプション。最初の認可リクエストで `code_challenge_method` パラメータと `code_challenge` パラメータを指定した場合のみ必須です。  
[PKCE](using-pkce-in-authorization-code.md) を使用した認証コード付与リクエストで、アプリケーションが計算した `code_challenge` の発行元である生成済みコード検証子。

## トークン用の認可コードの交換
<a name="post-token-positive-exchanging-authorization-code-for-tokens"></a>

次のリクエストは、認証コード付与による認証後に ID、アクセストークン、更新トークンを正常に生成します。リクエストは、クライアントシークレットを `client_secret_basic` の形式で `Authorization` ヘッダーに渡します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token&
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=authorization_code&
client_id=1example23456789&
code=AUTHORIZATION_CODE&
redirect_uri=com.myclientapp://myclient/redirect
```

レスポンスは、追加のメタデータとともに、新しい ID、アクセストークン、更新トークンをユーザーに発行します。

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "refresh_token": "eyJj3example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## 基本認可によるクライアント認証情報
<a name="exchanging-client-credentials-for-an-access-token-in-request-body"></a>

M2M アプリケーションからの次のリクエストは、クライアント認証情報の付与をリクエストします。クライアント認証情報にはクライアントシークレットが必要であるため、リクエストはアプリケーションクライアント ID とシークレットから派生した `Authorization` ヘッダーを使用して認可されます。リクエストにより、リクエストされた 2 つのスコープを持つアクセストークンが生成されます。リクエストには、IP アドレス情報を提供するクライアントメタデータと、付与対象であるユーザーに発行されたトークンも含まれます。Amazon Cognito は、クライアントメタデータをトークン生成前の Lambda トリガーに渡します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token >
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=client_credentials&
client_id=1example23456789&
scope=resourceServerIdentifier1%2Fscope1%20resourceServerIdentifier2%2Fscope2&
&aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D
```

Amazon Cognito は、次の入力イベントをトークン生成前の Lambda トリガーに渡します。

```
{
    version: '3',
    triggerSource: 'TokenGeneration_ClientCredentials',
    region: 'us-east-1',
    userPoolId: 'us-east-1_EXAMPLE',
    userName: 'ClientCredentials',
    callerContext: {
        awsSdkVersion: 'aws-sdk-unknown-unknown',
        clientId: '1example23456789'
    },
    request: {
        userAttributes: {},
        groupConfiguration: null,
        scopes: [
           'resourceServerIdentifier1/scope1',
           'resourceServerIdentifier2/scope2'
        ],
        clientMetadata: {
            'onBehalfOfToken': 'eyJra789ghiEXAMPLE',
            'ClientIpAddress': '192.0.2.252'
        }
    },
    response: { claimsAndScopeOverrideDetails: null }
}
```

レスポンスはアクセストークンを返します。クライアント認証情報の付与は、Machine to Machine (M2M) 認可用であり、アクセストークンのみを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json
{
    "access_token": "eyJra1example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## POST 本文認可によるクライアント認証情報
<a name="post-token-positive-exchanging-client-credentials-for-an-access-token-in-request-body"></a>

次のクライアント認証情報の付与リクエストには、リクエスト本文に `client_secret` パラメータが含まれ、`Authorization` ヘッダーは含まれていません。このリクエストでは、`client_secret_post` 認可構文を使用しています。リクエストにより、リクエストされたスコープを持つアクセストークンが生成されます。リクエストには、IP アドレス情報を提供するクライアントメタデータと、付与対象であるユーザーに発行されたトークンも含まれます。Amazon Cognito は、クライアントメタデータをトークン生成前の Lambda トリガーに渡します。

```
POST /oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
X-Amz-Target: AWSCognitoIdentityProviderService.Client credentials request
User-Agent: USER_AGENT
Accept: /
Accept-Encoding: gzip, deflate, br
Content-Length: 177
Referer: http://auth.example.com/oauth2/token
Host: auth.example.com
Connection: keep-alive

grant_type=client_credentials&
client_id=1example23456789&
scope=my_resource_server_identifier%2Fmy_custom_scope&
client_secret=9example87654321&
aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D
```

Amazon Cognito は、次の入力イベントをトークン生成前の Lambda トリガーに渡します。

```
{
    version: '3',
    triggerSource: 'TokenGeneration_ClientCredentials',
    region: 'us-east-1',
    userPoolId: 'us-east-1_EXAMPLE',
    userName: 'ClientCredentials',
    callerContext: {
        awsSdkVersion: 'aws-sdk-unknown-unknown',
        clientId: '1example23456789'
    },
    request: {
        userAttributes: {},
        groupConfiguration: null,
        scopes: [
           'resourceServerIdentifier1/my_custom_scope'
        ],
        clientMetadata: {
            'onBehalfOfToken': 'eyJra789ghiEXAMPLE',
            'ClientIpAddress': '192.0.2.252'
        }
    },
    response: { claimsAndScopeOverrideDetails: null }
}
```

レスポンスはアクセストークンを返します。クライアント認証情報の付与は、Machine to Machine (M2M) 認可用であり、アクセストークンのみを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Date: Tue, 05 Dec 2023 16:11:11 GMT
x-amz-cognito-request-id: 829f4fe2-a1ee-476e-b834-5cd85c03373b

{
    "access_token": "eyJra12345EXAMPLE",
    "expires_in": 3600,
    "token_type": "Bearer"
}
```

## PKCE による認証コード付与
<a name="post-token-positive-exchanging-authorization-code-grant-with-pkce-for-tokens"></a>

次のリクエスト例では、[PKCE](using-pkce-in-authorization-code.md) を使用した認証コード付与リクエストに `code_challenge_method` パラメータと `code_challenge` パラメータが含まれた認可リクエストを完了します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=authorization_code&
client_id=1example23456789&
code=AUTHORIZATION_CODE&
code_verifier=CODE_VERIFIER&
redirect_uri=com.myclientapp://myclient/redirect
```

レスポンスは、アプリケーションによる正常な PKCE 検証から ID、アクセストークン、更新トークンを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "refresh_token": "eyJj3example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## 更新トークンのローテーションなしのトークン更新
<a name="post-token-positive-exchanging-a-refresh-token-for-tokens"></a>

次のリクエスト例では、更新トークンの[ローテーション](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation)が非アクティブなアプリケーションクライアントに更新トークンを提供します。アプリケーションクライアントにはクライアントシークレットがあるため、リクエストは `Authorization` ヘッダーを提供します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token >
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=refresh_token&
client_id=1example23456789&
refresh_token=eyJj3example
```

レスポンスは、新しい ID トークンとアクセストークンを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## 更新トークンのローテーションによるトークン更新
<a name="post-token-positive-refresh-token-rotation"></a>

次のリクエスト例では、[更新トークンのローテーション](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation)がアクティブなアプリケーションクライアントに更新トークンを提供します。アプリケーションクライアントにはクライアントシークレットがあるため、リクエストは `Authorization` ヘッダーを提供します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token >
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=refresh_token&
client_id=1example23456789&
refresh_token=eyJj3example
```

レスポンスは、新しい ID、アクセス、更新トークンを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "refresh_token": "eyJj4example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## 否定応答の例
<a name="post-token-negative"></a>

不正な形式のリクエストは、トークンエンドポイントからエラーを生成します。トークンリクエストがエラーを生成したときのレスポンス本文の一般的なマップは、以下のとおりです。

```
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8

{
"error":"invalid_request|invalid_client|invalid_grant|unauthorized_client|unsupported_grant_type"
}
```

**`invalid_request`**  
リクエストに必須パラメータが含まれていない、サポートされていないパラメータ値 (`unsupported_grant_type` 以外) が含まれている、または正しい形式ではありません。たとえば、`grant_type` が `refresh_token` であるが、`refresh_token` が含まれていない、などです。

**`invalid_client`**  
クライアントの認証に失敗しました。たとえば、クライアントが認可ヘッダーに `client_id` と `client_secret` を含めたが、その `client_id` と `client_secret` を持つクライアントが存在しない場合です。

**`invalid_grant`**  
更新トークンが失効しています。  
認可コードが既に消費されているか、存在しません。  
アプリクライアントにはリクエストされたスコープ内すべての[属性](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html)への読み取りアクセス権はありません。例えば、アプリが `email` スコープをリクエストすると、アプリクライアントは `email` 属性の読み取りはできますが、`email_verified` は読み取れません。

**`unauthorized_client`**  
クライアントがコード付与フローまたはトークンの更新を許可されていません。

**`unsupported_grant_type`**  
`grant_type` が `authorization_code`、`refresh_token`、または `client_credentials` 以外の場合に返されます。

# ユーザー属性エンドポイント
<a name="userinfo-endpoint"></a>

OIDC がユーザー属性を含む ID トークンを発行する場合、OAuth 2.0 は `/oauth2/userInfo` エンドポイントを実装します。認証されたユーザーまたはクライアントは、`scopes` クレームを含むアクセストークンを受け取ります。このクレームは、認可サーバーが返す属性を決定します。アプリケーションが `userInfo` エンドポイントにアクセストークンを提示すると、認可サーバーは、アクセストークンスコープによって設定された境界内にあるユーザー属性を含む応答本文を返します。アプリケーションは、少なくとも `openid` スコープクレームを持つ有効なアクセストークンを保持している限り、`userInfo` エンドポイントからユーザーに関する情報を取得できます。

`userInfo` エンドポイントは OpenID Connect (OIDC) [userInfo エンドポイント](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)です。[トークントークンエンドポイント](token-endpoint.md)が発行したアクセストークンをサービスプロバイダーが提示すると、ユーザー属性で応答します。ユーザーのアクセストークンのスコープは、userInfo エンドポイントがレスポンスで返すユーザー属性を定義します。`openid` スコープはアクセストークンクレームのいずれかである必要があります。

Amazon Cognito は、[https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) などのユーザープール API リクエストに応答してアクセストークンを発行します。スコープが含まれていないため、userInfo エンドポイントはこれらのアクセストークンを受け入れません。代わりに、トークンエンドポイントからアクセストークンを提示する必要があります。

OAuth 2.0 サードパーティーの ID プロバイダー (IdP) は、userInfo エンドポイントもホストしています。ユーザーがその IdP で認証すると、Amazon Cognito は、IdP `token` エンドポイントと認可コードを表示せずに交換します。ユーザープールは IdP アクセストークンを渡して、IdP `userInfo` エンドポイントからのユーザー情報の取得を認可します。

ユーザーのアクセストークンのスコープは、認証リクエストの `scopes` リクエストパラメータ、または[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)が追加するスコープによって決まります。アクセストークンをデコードし、`scope` クレームを調べることで、それらに含まれるアクセスコントロールのスコープを確認できます。以下は、`userInfo` エンドポイントから返されるデータに影響を与えるスコープの組み合わせです。予約済みの Amazon Cognito スコープ `aws.cognito.signin.user.admin` は、このエンドポイントから返されるデータには影響しません。アクセストークンのスコープの例と `userInfo` レスポンスへの影響

**`openid`**  
アプリケーションクライアントが読み取れるすべてのユーザー属性を含むレスポンスを返します。

**`openid profile`**  
ユーザー属性として、`name`、`family_name`、`given_name`、`middle_name`、`nickname`、`preferred_username`、`profile`、`picture`、`website`、`gender`、`birthdate`、`zoneinfo`、`locale`、`updated_at` を返します。また、[カスタム属性](user-pool-settings-attributes.md#user-pool-settings-custom-attributes)も返します。各属性への読み取りアクセス権を持たないアプリケーションクライアントの場合、このスコープへのレスポンスは、アプリケーションクライアントが読み取りアクセス権を持つ仕様内のすべての属性となります。

**`openid email`**  
基本的なプロファイル情報と、`email` 属性および `email_verified` 属性を返します。

**`openid phone`**  
基本的なプロファイル情報と、`phone_number` 属性および `phone_number_verified` 属性を返します。

## GET /oauth2/userInfo
<a name="get-userinfo"></a>

アプリケーションは、ブラウザ経由ではなく、このエンドポイントへのリクエストを直接生成します。

詳細については、OpenID Connect (OIDC) 仕様の「[UserInfo エンドポイント](http://openid.net/specs/openid-connect-core-1_0.html#UserInfo)」を参照してください。

**Topics**
+ [GET /oauth2/userInfo](#get-userinfo)
+ [ヘッダーのリクエストパラメータ](#get-userinfo-request-header-parameters)
+ [例 – リクエスト](#get-userinfo-positive-exchanging-authorization-code-for-userinfo-sample-request)
+ [例 – 肯定応答](#get-userinfo-response-sample)
+ [否定応答の例](#get-userinfo-negative)

## ヘッダーのリクエストパラメータ
<a name="get-userinfo-request-header-parameters"></a>

**`Authorization: Bearer <access_token>`**  
認可ヘッダーフィールド内でアクセストークンを渡します。  
必須。

## 例 – リクエスト
<a name="get-userinfo-positive-exchanging-authorization-code-for-userinfo-sample-request"></a>

```
GET /oauth2/userInfo HTTP/1.1
Content-Type: application/x-amz-json-1.1
Authorization: Bearer eyJra12345EXAMPLE
User-Agent: [User agent]
Accept: */*
Host: auth.example.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
```

## 例 – 肯定応答
<a name="get-userinfo-response-sample"></a>

```
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Content-Length: [Integer]
Date: [Timestamp]
x-amz-cognito-request-id: [UUID]
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Server: Server
Connection: keep-alive
{
    "sub": "[UUID]",
    "email_verified": "true",
    "custom:mycustom1": "CustomValue",
    "phone_number_verified": "true",
    "phone_number": "+12065551212",
    "email": "bob@example.com",
    "username": "bob"
}
```

OIDC クレームのリストについては、「[スタンダードクレーム](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)」を参照してください。現在、Amazon Cognito は、`email_verified` と `phone_number_verified` の値を文字列として返します。

## 否定応答の例
<a name="get-userinfo-negative"></a>

### 例 – 不正なリクエスト
<a name="get-userinfo-negative-400"></a>

```
HTTP/1.1 400 Bad Request
WWW-Authenticate: error="invalid_request",
error_description="Bad OAuth2 request at UserInfo Endpoint"
```

**`invalid_request`**  
リクエストに必須パラメータが含まれていないか、サポートされていないパラメータ値が含まれているか、または正しい形式ではありません。

### 例 – 不正なトークン
<a name="get-userinfo-negative-401"></a>

```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="Access token is expired, disabled, or deleted, or the user has globally signed out."
```

**`invalid_token`**  
アクセストークンの有効期限が切れているか、失効しているか、正しい形式ではないか、または無効です。

# トークン取り消しエンドポイント
<a name="revocation-endpoint"></a>

セッションで更新トークンを保持するユーザーは、ブラウザ Cookie のようなものが与えられます。更新トークンが有効である限り、既存のセッションを更新できます。ID トークンまたはアクセストークンの有効期限が切れた後にサインインするようにユーザーに促す代わりに、アプリケーションは、更新トークンを使用して新しい有効なトークンを取得できます。ただし、ユーザーのセッションを終了する必要があると外部で判断することや、ユーザーが現在のセッションを忘れたりすることがあります。その時点で、セッションを維持できなくなるように、その更新トークンを取り消せます。

`/oauth2/revoke` エンドポイントは、指定した更新トークンを使用して Amazon Cognito が最初に発行したユーザーのアクセストークンを取り消します。また、このエンドポイントは、更新トークン自体、および同じ更新トークンからの後続のアクセストークンと ID トークンのすべても取り消します。エンドポイントがトークンを取り消した後、取り消されたトークンを使用して Amazon Cognito トークンが認証する API にアクセスすることはできません。

## POST/oauth2/revoke
<a name="post-revoke"></a>

`/oauth2/revoke` エンドポイントは `HTTPS POST` のみをサポートします。ユーザープールクライアントは、システムブラウザ経由ではなくこのエンドポイントに直接リクエストを送信します。

### ヘッダーのリクエストパラメータ
<a name="revocation-request-parameters"></a>

**`Authorization`**  
アプリケーションクライアントにクライアントシークレットがある場合、アプリケーションは、その `client_id` および `client_secret` をベーシック HTTP 認可を介して認可ヘッダーに渡す必要があります。シークレットは[ベーシック](https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side) `Base64Encode(client_id:client_secret)` です。

**`Content-Type`**  
常に `'application/x-www-form-urlencoded'` にする必要があります。

#### 本文のリクエストパラメータ
<a name="revocation-request-parameters-body"></a>

**`token`**  
(必須) クライアントが取り消す対象の更新トークンです。このリクエストは、Amazon Cognito がこの更新トークンで発行したすべてのアクセストークンも無効にします。  
必須。

**`client_id`**  
(オプション) 取り消す対象のトークンのアプリケーションクライアント ID。  
クライアントがパブリックでありシークレットがない場合は必須です。

## 取り消しリクエストの例
<a name="revoke-sample-request"></a>

この取り消しリクエストは、クライアントシークレットを持たないアプリケーションクライアントの更新トークンを取り消します。リクエスト本文内の `client_id` パラメータに注意してください。

```
POST /oauth2/revoke HTTP/1.1
Host: mydomain.auth.us-east-1.amazoncognito.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
token=2YotnFZFEjr1zCsicMWpAA&
client_id=1example23456789
```

この取り消しリクエストは、クライアントシークレットを*持つ*アプリケーションクライアントの更新トークンを取り消します。エンコードされたクライアント ID とクライアントシークレットを含むが、リクエスト本文内に `client_id` を含まない `Authorization` ヘッダーに注意してください。

```
POST /oauth2/revoke HTTP/1.1
Host: mydomain.auth.us-east-1.amazoncognito.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=2YotnFZFEjr1zCsicMWpAA
```

## 取り消しエラーレスポンス
<a name="revoke-sample-response"></a>

正常なレスポンスには空のボディが含まれています。エラーレスポンスは、`error` フィールドを持つ JSON オブジェクトで、`error_description` フィールドがある場合もあります。

**エンドポイントエラー**
+ リクエストにトークンが存在しない場合、またはアプリケーションクライアントに対して機能が無効化されている場合に、HTTP 400 とエラー `invalid_request` が返されます。
+ Amazon Cognito が取り消しリクエストで送信したトークンが更新トークンでない場合は、HTTP 400 とエラー `unsupported_token_type` が発生します。
+ クライアントの認証情報が有効でない場合、HTTP 401 とエラー `invalid_client` が発生します。
+ トークンが取り消されている、またはクライアントが無効なトークンを送信した場合は、HTTP 200 OK が発生します。

# IdP SAML アサーションエンドポイント
<a name="saml2-idpresponse-endpoint"></a>

`/saml2/idpresponse` は SAML アサーションを受け取ります。サービスプロバイダーが開始した (SP が開始した) サインインでは、アプリケーションはこのエンドポイントと直接インタラクションを行いません。SAML 2.0 ID プロバイダー (IdP) は、SAML 応答を使用してユーザーをここにリダイレクトします。SP が開始したサインインの場合、`saml2/idpresponse` へのパスをアサーションコンシューマーサービス (ACS) の URL として IdP を設定します。セッション開始の詳細については、「[Amazon Cognito ユーザープールでの SAML セッション開始](cognito-user-pools-SAML-session-initiation.md)」を参照してください。

IdP が開始したサインインでは、SAML 2.0 プロバイダーでユーザーをサインインした後に、アプリケーションでこのエンドポイントへのリクエストを呼び出します。ユーザーがブラウザで IdP でサインインすると、アプリケーションは SAML アサーションを収集し、このエンドポイントに送信します。HTTPS 経由で `HTTP POST` リクエストの本文に SAML アサーションを送信する必要があります。`POST` リクエストの本文は `SAMLResponse` パラメータと `Relaystate` パラメータである必要があります。詳細については、「[IdP が開始した SAML サインインを実装する](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-SAML-session-initiation-idp-initiation)」を参照してください。

`saml2/idpresponse` エンドポイントは、最大 100,000 文字長の SAML アサーションを受け入れることができます。

## POST `/saml2/idpresponse`
<a name="saml2-idpresponse-endpoint-post"></a>

IdP が開始したサインインで `/saml2/idpresponse` エンドポイントを使用するには、ユーザーのセッションに関する情報をユーザープールに提供するパラメータを含む POST リクエストを生成します。
+ サインインするアプリケーションクライアント。
+ 終了する対象のコールバック URL。
+ ユーザーのアクセストークンでリクエストする OAuth 2.0 スコープ。
+ サインインリクエストを開始した IdP。

### IdP が開始したリクエスト本文のパラメータ
<a name="saml2-idpresponse-endpoint-post-request"></a>

*SAMLResponse*  
ユーザープール内の有効なアプリケーションクライアントと IdP 設定に関連付けられた IdP からの Base64 でエンコードされた SAML アサーション。

*RelayState　*  
`RelayState` パラメータには、`oauth2/authorize` エンドポイントに本来であれば渡すリクエストパラメータが含まれます。これらのパラメータの詳細については、「[認可エンドポイント](authorization-endpoint.md)」を参照してください。    
*response\$1type*  
OAuth 2.0 付与タイプ。  
*client\$1id*  
アプリクライアント ID。  
*redirect\$1uri*  
Amazon Cognito がユーザーを認証した後、認証サーバーによってブラウザがリダイレクトされる URL です。  
*identity\$1provider*  
ユーザーをリダイレクトする ID プロバイダーの名前。  
*idp\$1identifier*  
ユーザーをリダイレクトする ID プロバイダーの識別子。  
*scope*  
ユーザーが認可サーバーにリクエストする OAuth 2.0 スコープ。

### 肯定応答を含むリクエストの例
<a name="saml2-idpresponse-endpoint-post-example"></a>

**例 - POST リクエスト**  
次のリクエストは、アプリケーションクライアント `1example23456789` の IdP `MySAMLIdP` からのユーザーに対する認可コードの付与に対するものです。ユーザーは、認可コードを使用して `https://www.example.com` にリダイレクトします。認証コードは、OAuth 2.0 スコープ `openid`、`email`、`phone` を持つアクセストークンなどのトークンと交換できます。

```
POST /saml2/idpresponse HTTP/1.1
User-Agent: USER_AGENT
Accept: */*
Host: example.auth.us-east-1.amazoncognito.com
Content-Type: application/x-www-form-urlencoded

SAMLResponse=[Base64-encoded SAML assertion]&RelayState=identity_provider%3DMySAMLIdP%26client_id%3D1example23456789%26redirect_uri%3Dhttps%3A%2F%2Fwww.example.com%26response_type%3Dcode%26scope%3Demail%2Bopenid%2Bphone
```

**例 – 応答**  
前のリクエストに対するレスポンス？の例を次に示します。

```
HTTP/1.1 302 Found
Date: Wed, 06 Dec 2023 00:15:29 GMT
Content-Length: 0
x-amz-cognito-request-id: 8aba6eb5-fb54-4bc6-9368-c3878434f0fb
Location: https://www.example.com?code=[Authorization code]
```

# OAuth 2.0 許可
<a name="federation-endpoints-oauth-grants"></a>

Amazon Cognito ユーザープール OAuth 2.0 認可サーバーは、3 種類の OAuth 2.0 [認可付与](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3)に対応してトークンを発行します。ユーザープール内の各アプリクライアントに、サポートされる許可タイプを設定できます。*暗黙的*付与または*認可コード*付与と同じアプリケーションクライアントで、*クライアント認証情報*付与を有効にすることはできません。暗黙的コード付与と認可コード付与のリクエストは、[認可エンドポイント](authorization-endpoint.md) で開始され、クライアント認証情報付与のリクエストは [トークンエンドポイント](token-endpoint.md) で開始されます。

**認可コード付与**  
認証リクエストが成功すると、認可サーバーは、`code` パラメータの認可コードをコールバック URL のパラメータに追加します。次に、[トークンエンドポイント](token-endpoint.md) と、アクセス、ID、更新トークンのコードを交換することができます。認可コード付与をリクエストするには、リクエストで `response_type` を `code` に設定します。リクエスト例については、「[例: 認証コード付与](authorization-endpoint.md#sample-authorization-code-grant)」を参照してください。Amazon Cognito は、認証コード付与で [Proof Key for Code Exchange (PKCE)](using-pkce-in-authorization-code.md) をサポートしています。  
認可コード付与は、最も安全な認可付与の形式です。トークンの内容がユーザーに直接表示されることはありません。代わりに、ユーザーのトークンを取得して安全に保管する責任はアプリにあります。Amazon Cognito では、認可コード付与が 3 種類のトークン (ID、アクセス、更新) すべてを認可サーバーから取得する唯一の方法です。Amazon Cognito ユーザープール API による認証から 3 種類のトークンをすべて取得することもできますが、API は `aws.cognito.signin.user.admin` 以外のスコープを持つアクセストークンを発行しません。

**暗黙の許可**  
認証リクエストが成功すると、認可サーバーは `access_token` パラメータのアクセストークンと、`id_token` パラメータの ID トークンを、コールバック URL に追加します。暗黙的な許可では、[トークンエンドポイント](token-endpoint.md) に追加の操作は必要ありません。暗黙的な許可をリクエストするには、リクエストで `response_type` を `token` に設定します。暗黙的な許可では、ID とアクセストークンのみが生成されます。リクエスト例については、「[例: `openid` スコープなしのトークンの (暗黙的) 付与](authorization-endpoint.md#sample-token-grant-without-openid-scope)」を参照してください。  
暗黙的な許可は、レガシーの認可付与方法です。認可コード付与とは異なり、ユーザーはトークンを傍受して検査できます。暗黙的な許可によるトークンの配信を防ぐには、認可コード付与のみをサポートするようにアプリクライアントを設定します。

**クライアント認証情報**  
クライアント認証情報は、マシン間アクセスに対する認可のみを付与します。クライアント認証情報許可を受けるには、[認可エンドポイント](authorization-endpoint.md) をバイパスして、[トークンエンドポイント](token-endpoint.md) に直接リクエストを生成してください。アプリクライアントにはクライアントシークレットが必要で、クライアント認証情報許可のみをサポートする必要があります。リクエストが成功すると、認可サーバーがアクセストークンを返します。  
クライアント認証情報許可からのアクセストークンは、OAuth 2.0 スコープを含む認可メカニズムです。通常、トークンには、アクセス保護された API に対する HTTP 操作を許可するカスタムスコープクレームが含まれます。詳細については、「[スコープ、M2M、リソースサーバー](cognito-user-pools-define-resource-servers.md)」を参照してください。  
クライアント認証情報付与は、 AWS 請求書にコストを追加します。詳細については、「[Amazon Cognito の料金](https://aws.amazon.com/cognito/pricing)」を参照してください。

**更新トークン**  
更新トークンの付与は、[トークンエンドポイント](token-endpoint.md) から直接リクエストできます。この付与は、有効な更新トークンと引き換えに、新しい ID トークンとアクセストークンを返します。

これらの付与とその実装の詳細については、「*AWS Security Blog*」の「[How to use OAuth 2.0 in Amazon Cognito: Learn about the different OAuth 2.0 grants](https://aws.amazon.com/blogs/security/how-to-use-oauth-2-0-in-amazon-cognito-learn-about-the-different-oauth-2-0-grants/)」を参照してください。

# 認可コード許可での PKCE の使用
<a name="using-pkce-in-authorization-code"></a>

Amazon Cognito は、認可コード付与で Proof Key for Code Exchange (PKCE)をサポートしています。PKCE は、パブリッククライアント向けの OAuth 2.0 認可コード付与の拡張機能です。PKCE は、傍受された認可コードの引き換えから保護します。

## Amazon Cognito での PKCE の使用方法
<a name="how-pkce-works"></a>

PKCE で認証を開始するには、アプリケーションが一意の文字列値を生成する必要があります。この文字列は、最初の認可付与をリクエストするクライアントと、トークンの認可コードを交換するクライアントとを比較するために Amazon Cognito が使用するシークレット値であるコード検証子です。

アプリケーションは、コード検証文字列に SHA256 ハッシュを適用し、結果を base64 にエンコードする必要があります。ハッシュされた文字列をリクエスト本文の `code_challenge` パラメータとして [認可エンドポイント](authorization-endpoint.md) に渡します。アプリケーションが認可コードとトークンを交換する場合、[トークンエンドポイント](token-endpoint.md) へのリクエスト本文に `code_verifier` パラメータとしてプレーンテキストのコード検証文字列を含める必要があります。Amazon Cognito は、コード検証子に対して同じハッシュアンドエンコードオペレーションを実行します。Amazon Cognito は、コード検証子が認可リクエストで受け取ったものと同じコードチャレンジをもたらすと判断した場合のみ、ID トークン、アクセストークン、および更新トークンを返します。

**PKCE を使用して認可付与フローを実装するには**

1. [Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/home)を開きます。プロンプトが表示されたら、 AWS 認証情報を入力します。

1. **[User Pools]** (ユーザープール) を選択します。

1. リストから既存のユーザープールを選択、または[ユーザープールを作成](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html)します。ユーザープールを作成する場合は、ウィザード中にアプリケーションクライアントのセットアップとマネージドログインの設定を求められます。

   1. 新しいユーザープールを作成する場合は、ガイド付きセットアップ中にアプリケーションクライアントをセットアップし、マネージドログインを設定します。

   1. 既存のユーザープールを設定する場合で、[ドメイン](cognito-user-pools-assign-domain.md)と[パブリックアプリケーションクライアント](user-pool-settings-client-apps.md)がない場合は、これらを追加します。

1. PKCE のコードチャレンジを作成するには、ランダムな英数字文字列、通常は Universally Unique Identifier ([UUID](cognito-terms.md#terms-uuid)) を生成します。この文字列は、リクエストで [トークンエンドポイント](token-endpoint.md) に送信する `code_verifier` パラメータの値です。

1. SHA256 アルゴリズムを使用して `code_verifier` 文字列をハッシュします。ハッシュ操作の結果を base64 にエンコードします。この文字列は、リクエストで [認可エンドポイント](authorization-endpoint.md) に送信する `code_challenge` パラメータの値です。

   次の Python 例では、`code_verifier` を生成し、`code_challenge` を計算します。

   ```
   #!/usr/bin/env python3
   
   import secrets
   from base64 import urlsafe_b64encode
   from hashlib import sha256
   from string import ascii_letters
   from string import digits
   
   # use the secrets module for cryptographically strong random values
   alphabet = ascii_letters + digits
   code_verifier = ''.join(secrets.choice(alphabet) for _ in range(128))
   code_verifier_hash = sha256(code_verifier.encode()).digest()
   code_challenge = urlsafe_b64encode(code_verifier_hash).decode().rstrip('=')
   
   print(f"code challenge: {code_challenge}")
   print(f"code verifier: {code_verifier}")
   ```

   Python スクリプトからの出力例を次に示します。

   ```
   code challenge: Eh0mg-OZv7BAyo-tdv_vYamx1boOYDulDklyXoMDtLg
   code verifier: 9D-aW_iygXrgQcWJd0y0tNVMPSXSChIc2xceDhvYVdGLCBk-JWFTmBNjvKSdOrjTTYazOFbUmrFERrjWx6oKtK2b6z_x4_gHBDlr4K1mRFGyE8yA-05-_v7Dxf3EIYJH
   ```

1. PKCE を使用した認証コード付与リクエストで、マネージドログインのサインインを完了します。URL の例を次に示します。

   ```
   https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com&code_challenge=Eh0mg-OZv7BAyo-tdv_vYamx1boOYDulDklyXoMDtLg&code_challenge_method=S256
   ```

1. 認可 `code` を収集し、トークンエンドポイントを持つトークンと引き換えます。リクエストの例を次に示します。

   ```
   POST /oauth2/token HTTP/1.1
   Host: mydomain.auth.us-east-1.amazoncognito.com
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 296
   
   redirect_uri=https%3A%2F%2Fwww.example.com&
   client_id=1example23456789&
   code=7378f445-c87f-400c-855e-0297d072ff03&
   grant_type=authorization_code&
   code_verifier=9D-aW_iygXrgQcWJd0y0tNVMPSXSChIc2xceDhvYVdGLCBk-JWFTmBNjvKSdOrjTTYazOFbUmrFERrjWx6oKtK2b6z_x4_gHBDlr4K1mRFGyE8yA-05-_v7Dxf3EIYJH
   ```

1. 応答を確認します。ID トークン、アクセストークン、更新トークンが含まれます。Amazon Cognito ユーザープールトークン使用の詳細については、「[ユーザープール JSON ウェブトークン (JWT) の理解](amazon-cognito-user-pools-using-tokens-with-identity-providers.md)」を参照してください。

# マネージドログインとフェデレーションのエラーレスポンス
<a name="federation-endpoint-idp-responses"></a>

マネージドログインまたはフェデレーティッドサインインからエラーが返されることがあります。認証がエラーで終了する原因となる条件は次のとおりです。
+ ユーザープールでは実行できない操作を、ユーザーが実行する。
+ Lambda トリガーが想定どおりの構文で応答しない。
+ ID プロバイダー (IdP) がエラーを返す。
+ Amazon Cognito は、ユーザーが提供した属性情報を検証できませんでした。
+ IdP は、必須の属性に対応するクレームを送信しませんでした。

Amazon Cognito はエラーを検出すると、以下のいずれかの方法でエラーを通知します。

1. Amazon Cognito は、リクエストパラメータにエラーを含むリダイレクト URL を送信します。

1. Amazon Cognito はマネージドログインのエラーを表示します。

Amazon Cognito がリクエストパラメータに追加するエラーの形式は次のとおりです。

```
https://<Callback URL>/?error_description=error+description&error=error+name
```

ユーザーが操作を実行できないときにエラー情報を送信できるようにする場合は、URL *と*テキスト、またはページのスクリーンショットをキャプチャするようにリクエストしてください。

**注記**  
Amazon Cognito エラーの説明は固定文字列ではないため、固定のパターンや形式に依存するロジックは使用しないでください。

**OIDC とソーシャル ID プロバイダーのエラーメッセージ**  
ID プロバイダー (IdP) は、エラーを返すことがあります。OIDC または OAuth 2.0 IdP が標準に準拠したエラーを返すと、Amazon Cognito はユーザーをコールバック URL にリダイレクトし、プロバイダーのエラーレスポンスをエラーリクエストパラメータに追加します。Amazon Cognito は、既存のエラー文字列にプロバイダー名と HTTP エラーコードを追加します。

次の URL は、エラーを返した IdP から Amazon Cognito へのリダイレクトの例です。

```
https://www.amazon.com/?error_description=LoginWithAmazon+Error+-+400+invalid_request+The+request+is+missing+a+required+parameter+%3A+client_secret&error=invalid_request
```

Amazon Cognito はプロバイダーから受け取ったもののみを返すため、ユーザーにはこの情報のサブセットが表示される場合があります。

IdP による初回ログインで問題が発生すると、IdP はすべてのエラーメッセージをユーザーに直接配信します。Amazon Cognito は、ユーザーセッションを検証するリクエストを IdP に生成すると、エラーメッセージをユーザーに中継します。Amazon Cognito は、以下のエンドポイントからの OAuth および OIDC IdP のエラーメッセージを中継します。

`/token`  
Amazon Cognito が IdP の認可コードをアクセストークンと交換します。

`/.well-known/openid-configuration`  
Amazon Cognito は発行者のエンドポイントへのパスを検出します。

`/.well-known/jwks.json`  
ユーザーの JSON ウェブトークン (JWT) を検証するために、Amazon Cognito は IdP がトークンの署名に使用する JSON ウェブキー (JWK) を検出します。

Amazon Cognito は HTTP エラーを返す可能性のある SAML 2.0 プロバイダーへのアウトバウンドセッションを開始しないため、SAML 2.0 IdP とのセッション中のユーザーエラーには、この形式のプロバイダーエラーメッセージは含まれません。