Cognitoの認証設計では、求める操作フローが標準仕様に収まるか、アプリ側で何を補う必要があるかを確認しておきたいところです。

無操作ログアウト、再認証、パスワード再設定など、6つの要件について結論と対応方法をまとめます。対象は、独自の画面からCognitoユーザープールのAPIを利用するWebアプリケーションです。

6つの要件と対応方法

各要件の結論は次のとおりです。仕様の根拠と追加実装の条件は、同じ番号の章に記載しています。

要件	結論	対応方法
1. 無操作ログアウト・即時失効	トークンの有効期限・失効操作だけでは満たせない	アプリで操作時刻・失効状態を管理し、業務APIで拒否する
2. 画面ロック・作業保持	アプリ側の実装が必要	ロック状態と作業データを管理し、解除時の本人認証にCognitoを使う
3. SMSなしのパスワード再確認	SMS MFAに進む標準フローではSMSが送られる	再認証方式を見直すか、配送制御を追加する
4. 再設定コードだけの事前検証	標準APIではコードと新パスワードが両方必要	最終送信時に検証する。事前検証が必須なら別フローを設計する
5. ユーザー名の入力・保存情報なしでパスキー認証	標準の認証開始APIには`USERNAME`が必須	保存情報があれば入力を省略できるが、APIへの指定は省略できない
6. パスキー認証後、旧パスワードなしで変更	設定済みユーザーは`ChangePassword`で旧パスワードが必要	管理APIを使う場合は、本人確認・操作認可をアプリで実装する

利用できる認証方式や組み合わせは、機能プラン・MFA・アプリクライアントの設定によって異なります。以下はCognito標準の認証フローを前提とし、外部IDプロバイダーや独自WebAuthn実装は扱いません。
AWS公式：認証フロー

1. 無操作ログアウト・即時失効

無操作期限と失効状態は、アプリ側で管理し、保護対象のAPIで確認します。

無操作期限は「最後の操作から何分経ったか」で判定します。JWTの有効期限を短くしても、同じ動作にはなりません。期限の判定はサーバー側で行います。
OWASP：アイドルタイムアウト

また、Cognitoでトークンを失効させても、JWTの署名・有効期限だけを検証するAPIでは、その失効を検出できません。失効後のアクセスを止めるには、API側でも拒否する仕組みが必要です。
AWS公式：トークンの失効

例えば、サーバーセッションに最終操作時刻・期限・失効状態を持たせ、業務処理の前に確認します。定期ポーリングを「操作」に含めるか、認可結果のキャッシュによって拒否が遅れないかも、この構成で確認する点です。

2. 画面ロック・作業保持

ロックと作業保持はアプリで実装し、解除時の本人認証にCognitoを使います。

画面を隠すだけではAPIの直接呼び出しを防げないため、サーバー側でもロック状態を確認して業務APIを拒否します。入力中のデータの保存・復元も、Cognitoの認証とは別の処理です。
OWASP：リクエストごとの認可チェック

解除時には、再認証したユーザーが元のセッションのユーザーと一致することと、セッションが有効なことを確認します。期限切れ・失効済みなら、古いセッションを復活させず、再ログイン後に作業を復元する構成にします。

作業データには、保存先・保持期間・復元できるユーザーを別途定めます。作業を残すために、セッションの期限まで延ばす必要はありません。

3. SMSなしのパスワード再確認

パスワード確認後にSMS_MFAへ進む標準フローでは、SMSが送信されます。

AdminInitiateAuthはパスワード照合専用のAPIではありません。コード入力画面を表示しないだけでは、SMS送信を止められません。
AWS公式：AdminInitiateAuth
SMS MFAの認証手順

配送を制御する方法にCustom SMS senderがあります。ただし、設定するとユーザープールのすべてのSMSをLambdaで処理するため、通常ログインや登録確認、パスワード再設定の配送も管理対象になります。
AWS公式：Custom SMS sender

AdminInitiateAuthのClientMetadataはこのトリガーに渡されません。「再確認用」というフラグを付けるだけでは、用途別に配送を切り替えられない点にも注意が必要です。
AWS公式：ClientMetadata

SMSの配送を抑えても、MFAが完了したことにはなりません。対象操作にパスワード確認だけで十分かを決めたうえで、再認証方式の変更か、配送制御の追加かを選びます。

4. パスワード再設定コードの事前検証

Cognitoの標準フローでは、再設定コードだけを先に検証できません。 ConfirmForgotPasswordには、確認コードと新パスワードの両方が必要です。
AWS公式：ConfirmForgotPassword

画面を分けることはできます。ForgotPasswordでコードを送った後、コードを保持して次の画面へ進み、新パスワードと一緒に送信する流れです。

この場合、コードの誤りがわかるのは最後の送信時です。「コードが正しいことを確認してから次の画面へ進む」という要件には、そのままでは対応できません。

事前検証が必須なら、アプリ独自のOTP（ワンタイムコード）で本人確認し、成功後にサーバーからAdminSetUserPasswordをPermanent: trueで呼ぶ別フローが考えられます。Cognitoの再設定コードを単独検証する方法ではありません。
AWS公式：AdminSetUserPassword

独自OTPでは、安全な生成・保存、有効期限、試行制限、一回限りの使用、検証結果と変更対象の結び付けをアプリで実装します。アカウントの存在を推測させない応答、変更通知、既存セッションの扱いも必要です。
OWASP：パスワード再設定

5. ユーザー名なしのパスキー認証

Cognito標準のUSER_AUTHフローでは、パスキー認証でもUSERNAMEが必要です。
AWS公式：InitiateAuth

画面での入力を省けるかは、サインインに使うユーザー名やメールアドレスをアプリが取得できるかで変わります。

ユーザー名などの取得方法	画面での入力	APIへの`USERNAME`指定
Cookieなどの保存情報から取得できる	省略できる	必要。保存値を渡す
取得できず、利用者に入力してもらう	必要	必要。入力値を渡す

AWS公式：認証処理の例

これはパスキー一般ではなく、Cognito標準フローの制約です。

6. パスキー認証後のパスワード変更

パスワード設定済みのユーザーは、パスキーで再認証してもChangePasswordで旧パスワードを省略できません。
AWS公式：ChangePassword

旧パスワードの要否は、ユーザーの状態と利用するAPIで変わります。

ユーザーの状態・利用API	旧パスワード	呼び出しの認可
パスワード設定済みで`ChangePassword`	必要	本人のアクセストークン
パスワード未設定・パスワードレス認証のみで`ChangePassword`	省略可能	本人のアクセストークン
サーバーから`AdminSetUserPassword`	不要	IAM権限。利用者の操作認可はアプリ側

ChangePasswordのアクセストークンにはaws.cognito.signin.user.adminスコープが必要です。旧パスワードなしで確定変更する構成では、サーバーからAdminSetUserPasswordをPermanent: trueで呼びます。
AWS公式：ChangePassword
AdminSetUserPassword

管理APIを呼ぶ前に、直近のパスキー認証の成功をサーバーで確認し、現在のセッション・変更対象のユーザー・パスワード変更操作に結び付けます。検証結果には有効期限を設け、使い回しを防ぎます。
OWASP：重要な操作での再認証

クライアントが送る「認証済み」フラグや変更対象のユーザー名だけを信頼して、管理APIを呼んではいけません。IAMが許可するのは管理APIの実行であり、利用者が誰のパスワードを変更してよいかはアプリで判断します。
OWASP：認可

まとめ

今回の6点は、アプリ側で状態を管理する要件と、Cognitoの入力項目・認証フローに制約がある要件に分かれます。

要件が標準仕様に合わない場合は、画面・操作フローを調整するか、追加実装で補うかの判断が必要です。例えば、再設定コードの検証を最終送信時にまとめられれば、事前検証用の独自OTPは不要です。

採用前に通常ログインだけでなく、ロック解除・再認証・パスワード再設定まで確認すると、追加実装の範囲を見積もれます。その実装・運用負担も含めて、Cognitoを使うか、別の認証サービスを選ぶかを比較したいところです。