背景
Cognito + API Gateway + Lambdaで認証付きAPIをコンソールで構築する際、2026年時点の新UIで最も詰まりやすいポイントが、クライアントシークレットの自動付与でした。
1. 新UIの「アプリケーションを作成」はUser PoolとClientを同時生成する
旧UI: User Pool作成 → App Client作成（別々）
新UI: 「アプリケーションを作成」の1ウィザードで両方同時に作成
旧UIの「ユーザープールを作成」ボタンは廃止され、User PoolとApp Clientをまとめて作る設計に変わっています。ただしこの一体化が、次のハマりどころを生みます。
2. 「従来のウェブアプリケーション」を選ぶとシークレットが自動付与される
アプリケーションタイプ: 従来のウェブアプリケーション
→ クライアントシークレットが自動で付与される
シークレットありのクライアントでCLIからinitiate-authを実行すると、以下のエラーになります。
SECRET_HASH was not received
対処: シークレットが必要ないテスト用途では、アプリケーションタイプに「シングルページアプリケーション (SPA)」を選びます。この選択肢だとシークレットなしでクライアントが作成され、CLIから直接ユーザー名・パスワードで認証するテストフローが組めます。
3. Cognito Authorizerを設定すればLambda側は認証コード不要
claims = (
event.get("requestContext", {})
.get("authorizer", {})
.get("claims", {})
)
return {
"email": claims.get("email"),
"sub": claims.get("sub"),
"token_use": claims.get("token_use"),
}
API Gatewayに Cognito Authorizer を設定すると、JWTの検証はAPI Gateway側で完結し、Lambdaが呼ばれた時点で認証済みであることが保証されます。Lambda側はrequestContext.authorizer.claimsから検証済みの情報を取り出すだけでよく、JWT検証ロジックを自前で書く必要がありません。
4. Authorizerの「トークンのソース」はデフォルト空欄
トークンのソース: Authorization （デフォルトは空欄・必ず入力する）
新UIのCognito Authorizer作成画面では、トークンをどのヘッダーから受け取るかの設定が初期状態で空欄になっています。これを入力し忘れると、全リクエストが問答無用で401になり、原因の特定に時間がかかります。
5. Lambdaに渡すのは IdToken、AccessToken ではない
IdToken: ユーザー認証用（email/subなどのユーザー情報を含む）← これを使う
AccessToken: Cognito API アクセス用（sub/scopeなどを含む）
initiate-authのレスポンスには複数のトークンが含まれますが、API GatewayのCognito Authorizerに渡すべきはIdTokenです。AccessTokenを渡すと403エラーになります。また、AuthorizationヘッダーにはBearerプレフィックスを付けず、raw JWTをそのまま指定する点も見落としがちです。
まとめ
新UIの「アプリケーションを作成」フローはクライアントシークレットの扱いに要注意で、CLIテスト用途ではSPAタイプでの別クライアント作成が実質必須でした。Authorizerのトークンソース設定と合わせて、この2点が新UI特有のハマりどころです。FORCE_CHANGE_PASSWORD状態からの永続パスワード設定手順は元記事にまとめています。