翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 認証フロー
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 によるサインイン
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)
## 永続的なパスワードによるサインイン
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\_USER\_PASSWORD\_AUTH) を使用してサインインします]** を選択します。サーバー側のアプリケーションでプレーンパスワードサインインを許可するには、アプリケーションクライアントを編集し、**[サーバー側の管理者認証情報 (ALLOW\_ADMIN\_USER\_PASSWORD\_AUTH) を使用してサインインします]** を選択します。
ユーザー名とパスワードを使用して[選択ベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)を有効にするには、それを許可するようにアプリケーションクライアントを設定します。アプリケーションクライアントを編集し、**[選択ベースのサインイン: ALLOW\_USER\_AUTH]** を選択します。
選択ベースの認証フローでパスワード認証が使用可能であることを確認するには、**[サインイン]** メニューに移動し、**[選択ベースのサインインのオプション]** セクションを確認します。**[使用できる選択肢]** に **[パスワード]** が表示されている場合は、プレーンパスワード認証でサインインできます。**[パスワード]** オプションには、プレーンパスワード認証や 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) などの追加の必須チャレンジを使用して、成功したリクエストに応答します。
------
## 永続的なパスワードと安全なペイロードによるサインイン
ユーザープールのユーザー名パスワードによるサインイン方法の別の形式として、セキュアリモートパスワード (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\_USER\_SRP\_AUTH) を使用してサインインします]** を選択します。
ユーザー名と SRP を使用した[選択ベースの認証](authentication-flows-selection-sdk.md#authentication-flows-selection-choice)を有効にするには、アプリケーションクライアントを編集し、**[選択ベースのサインイン: ALLOW\_USER\_AUTH]** を選択します。
選択ベースの認証フローで 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) などの別の必要なチャレンジを発行します。
------
## ワンタイムパスワードによるパスワードなしのサインイン
パスワードは紛失したり盗まれたりする場合があります。ユーザーが検証済みの 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\_CHALLENGE](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\_USER\_AUTH]** を選択します。
**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 パスキーを使用したパスワードなしのサインイン
パスキーは安全で、ユーザーの負担は比較的少なくて済みます。パスキーサインインでは、ユーザーが認証に使用できる外部デバイスである *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)」を参照してください。
### パスキーとは
パスキーを使用すると、複雑なパスワードを覚えたり、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 でパスキー認証を実装する方法
パスキーは、**ライト**を除くすべての[機能プラン](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\_USER\_AUTH]** を選択します。
**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
ユーザー名パスワードフローでサインインを完了したユーザーに対して、E メールメッセージ、SMS メッセージ、またはコード生成アプリケーションのワンタイムパスワードを使用した追加の検証を求めるように設定できます。MFA は、ワンタイムパスワードによるパスワードレスサインインとは異なります。ただし、ユーザープール `MULTI_FACTOR_WITH_USER_VERIFICATION`で を `FactorConfiguration`として設定すると、ユーザー検証付きのパスキーは MFA 要件を満たすことができます`WebAuthnConfiguration`。パスワードベースのフローの場合、ユーザープールの MFA はチャレンジレスポンスモデルであり、ユーザーは最初にパスワードを知っていることを示し、次に登録された第 2 要素デバイスにアクセスできることを示します。
**実装リソース**
+ [ユーザープールに MFA を追加します](user-pool-settings-mfa.md)
## 更新トークン
認証情報を再入力せずにユーザーがサインインしたままにする場合、*更新トークン*は、アプリケーションがユーザーのセッションを維持するためのツールとなります。アプリケーションは、更新トークンをユーザープールに提示し、新しい ID トークンやアクセストークンと交換できます。トークンの更新により、サインインしているユーザーが引き続きアクティブであることの確認、更新された属性情報の取得、ユーザーの介入なしのアクセスコントロール権限の更新を行うことができます。
**実装リソース**
+ [更新トークン](amazon-cognito-user-pools-using-the-refresh-token.md)
## カスタム認証
ここに記載していない、ユーザーの認証方法を設定することもできます。そのためには、Lambda トリガーによる*カスタム認証*を使用します。一連の Lambda 関数により、Amazon Cognito はチャレンジを発行し、ユーザーに回答を求める質問を行い、回答が正確であることを確認し、別のチャレンジを発行すべきかどうかを判断します。質問と回答には、セキュリティの質問、CAPTCHA サービスへのリクエスト、外部 MFA サービス API へのリクエスト、またはこれらすべてが順に含まれます。
**実装リソース**
+ [カスタム認証チャレンジの Lambda トリガー](user-pool-lambda-challenge.md)
### カスタム認証フロー
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)に記載されています。
### カスタム認証フローとチャレンジ
アプリはカスタム認証フローを開始するために、`InitiateAuth` を `CUSTOM_AUTH` として `Authflow` を呼び出すことができます。カスタム認証フローで、3 つの Lambda トリガーがチャレンジとレスポンスの検証を制御します。
+ `DefineAuthChallenge` Lambda トリガーは、以前のチャレンジとレスポンスのセッション配列を入力として使用します。そして、次のチャレンジ名と、ユーザーが認証済みで、トークンを付与できるかどうかを示すブール値を生成します。この Lambda トリガーは、チャレンジを通じてユーザーのパスを制御するステートマシンです。
+ `CreateAuthChallenge` Lambda トリガーは、チャレンジ名を入力として使用し、チャレンジとパラメータを生成してレスポンスを評価します。`DefineAuthChallenge` が次のチャレンジとして `CUSTOM_CHALLENGE` を返すと、認証フローは、`CreateAuthChallenge` を呼び出します。`CreateAuthChallenge`Lambda トリガーは、チャレンジメタデータパラメータで次のタイプのチャレンジを渡します。
+ `VerifyAuthChallengeResponse` Lambda 関数は、レスポンスを評価し、レスポンスが有効であるかどうかを示すブール値を返します。
カスタム認証フローでは、SRP パスワードの検証や SMS を介した MFA などの、内部定義されたチャレンジを組み合わせて使用することもできます。CAPTCHA や秘密の質問などのカスタムチャレンジを使用できます。
### カスタム認証フローにおける SRP パスワードの検証の使用
カスタム認証フローに 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)」を参照してください。
## ユーザー移行の認証フロー
ユーザー移行用 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)」を参照してください。