Contents
ユーザープールとは何か – 認証機能の全容
このセクションでは、Amazon Cognito の ユーザープール が提供する認証関連の機能を体系的に整理します。
ユーザーがサインアップからサインイン、パスワードリセットまで行う際に、どのような設定項目が利用できるかを把握すれば、最小限のコードで堅牢な認証基盤を構築できます。
サインアップ／サインイン機能
ユーザープールはメールアドレス・電話番号・ユーザー名のいずれでも登録を受け付けます。
サインアップ時に自動で送信される検証コード（メールまたは SMS）によって、本人確認が完了したらアカウントが有効化されます【1】。
| 項目 | 説明 |
|---|---|
| 登録情報 | email、phone_number、preferred_username などから選択可能 |
| 検証方法 | メールリンク・SMS コードのいずれかを自動送信 |
| 有効化タイミング | 検証が成功した瞬間に Enabled = true に設定 |
マルチファクタ認証 (MFA)
MFA は SMS（OTP） と TOTP（Google Authenticator 等） の 2 種類をサポートし、必須化・条件付き適用が可能です。
2025 年の re:Invent で発表された リスクベース認証 機能は 2026 年に本格提供予定であり、疑わしいサインイン時に自動的に MFA を要求できます【2】。
注意点：MFA を必須化する場合は、ユーザー体験を損なわないようにバックアップコードやリカバリ手順も併せて設計してください。
カスタム属性
デフォルト属性（email, phone_number など）に加えて 最大 25 個 のビジネス固有属性を定義できます。
属性は JWT に埋め込んで ID プールへ渡すことができ、属性ベースのロールマッピングに利用可能です【3】。
パスワードポリシー
- 最低文字数（8〜64 文字）
- 大文字・小文字・数字・記号のいずれか N 個以上 の組み合わせ
- 辞書攻撃防止のための パスワードヒストリー 設定（過去 N 回の再使用禁止）
Lambda トリガーによるフロー拡張
| トリガー | 典型的な利用例 |
|---|---|
| Pre Sign‑up | ドメインホワイトリストや招待制チェック |
| Post Confirmation | 初回ログイン時のウェルカムメール送信 |
| Custom Message | 多言語対応の認証コードメール |
| Define Auth Challenge | カスタム認証フロー（例：ワンタイムパスワード＋CAPTCHA） |
パスワード忘れ (Forgot Password) フロー
ユーザーが ForgotPassword を呼び出すと、検証コード送信 → 新規パスワード設定までの一連処理を Cognito が自動で実行します。
このフローは Lambda カスタムメッセージ と組み合わせることで、ブランドロゴや独自文言を差し込むことが可能です。
ポイント：ユーザープールは「誰が」アプリにアクセスできるかを判定する認証基盤であり、MFA・カスタム属性・Lambda トリガーによって高度なセキュリティ要件にも柔軟に対応できます。
IDプール（アイデンティティプール）とは何か – 認可機能の全容
この章では、認証済みユーザーや外部 IdP から取得したトークンをもとに AWS リソースへの一時的アクセス権 を付与する ID プール（Identity Pool）の役割を解説します。
認可レイヤーとしての基本概念と、実際にどのようなクレデンシャルが発行されるかを理解すれば、最小権限で安全にサービスを提供できます。
一時的 AWS クレデンシャル取得と IAM ロールマッピング
ID プールは以下の 3 つの主要機能を提供します【4】。
| 機能 | 内容 |
|---|---|
| 一時的認証情報 | AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、SESSION_TOKEN をデフォルト 1 時間（最大 12 時間）有効で発行 |
| IAM ロールマッピング | ユーザー属性（例：cognito:user_groups、カスタム属性 role）や外部 IdP のスコープに基づきロールを自動選択 |
| フェデレーション | Google・Facebook・Apple・SAML 2.0 等から取得したアクセストークンを直接変換可能 |
匿名アクセス
サインインしていないユーザーにも一意な IdentityId を付与し、限定的なリソース（例：パブリック S3 バケット）への読み取り権限だけを許可できます。
匿名 ID は 同一デバイス であれば永続化されるため、利用者の行動トラッキングにも活用可能です。
ポイント：ID プールは「何ができるか」を制御する認可レイヤーであり、属性ベースロールマッピングにより最小権限の原則（Principle of Least Privilege）を実現します。
認証と認可の根本的な違いと連携フロー
この節では「認証」と「認可」の概念的な違いを整理し、Cognito における ユーザープール → ID プール の二段階プロセスがどのように機能するかを具体的に示します。
ユーザープールトークンを ID プールへ渡す手順
以下はフロントエンド（React / Vue 等）で Amplify と AWS SDK for JavaScript v3 を組み合わせた典型的な実装例です。
コード中の <YOUR_...> 部分は必ず自プロジェクトに合わせて置き換えてください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
// src/auth/cognito.js import { Auth } from 'aws-amplify'; import { CognitoIdentityClient, GetIdCommand, GetCredentialsForIdentityCommand, } from '@aws-sdk/client-cognito-identity'; // ------------------------------------------------------------ // 1️⃣ サインイン → ID トークン取得 // ------------------------------------------------------------ export async function signIn(username, password) { await Auth.signIn(username, password); const session = await Auth.currentSession(); // ID token（JWT）を返却。認可側で使用。 return session.getIdToken().getJwtToken(); } // ------------------------------------------------------------ // 2️⃣ ID プールから一時クレデンシャル取得 // ------------------------------------------------------------ export async function getAwsCredentials(idToken) { const region = 'ap-northeast-1'; // ← 必要に応じて変更 const identityPoolId = '<YOUR_IDENTITY_POOL_ID>'; // e.g. ap-northeast-1:xxxxxxxx‑xxxx‑xxxx‑xxxx‑xxxxxxxxxxxx const userPoolId = '<YOUR_USER_POOL_ID>'; // e.g. ap-northeast-1_ABCDEFGHI const client = new CognitoIdentityClient({ region }); // ① IdentityId を取得（ID token を Logins に渡す） const getIdResp = await client.send( new GetIdCommand({ IdentityPoolId: identityPoolId, Logins: { [`cognito-idp.${region}.amazonaws.com/${userPoolId}`]: idToken, }, }) ); // ② 一時クレデンシャル取得 const credResp = await client.send( new GetCredentialsForIdentityCommand({ IdentityId: getIdResp.IdentityId, Logins: { [`cognito-idp.${region}.amazonaws.com/${userPoolId}`]: idToken, }, }) ); // 戻り値は { AccessKeyId, SecretKey, SessionToken, Expiration } return credResp.Credentials; } |
実装上の注意
IdentityPoolIdとUserPoolIdは環境ごとに異なるため、コードリポジトリにハードコーディングしないこと（環境変数や Parameter Store 推奨）。
複数リージョンでユーザープールと ID プールを混在させる場合は、同一リージョンの組み合わせが推奨です。リージョンが異なるとLoginsのキーが一致せずエラーになります【5】。
認証 vs 認可比較表
| 観点 | ユーザープール（認証） | ID プール（認可） |
|---|---|---|
| 目的 | 「誰が」サインインしたかを検証 | 「何ができる」かを権限付与 |
| 発行物 | JWT (id_token, access_token) |
一時的 AWS クレデンシャル |
| 主な設定項目 | MFA、パスワードポリシー、カスタム属性 | IAM ロールマッピング、属性ベース条件 |
| 連携タイミング | サインイン直後に取得 | ID トークン受領後に GetId/GetCredentials 呼び出し |
ポイント：認証で得た JWT が認可の入り口となり、ID プールがそのトークンを基に最小権限の一時クレデンシャルを発行することで、安全な AWS リソースアクセスが実現します。
ユースケース別の選択指針
本節では典型的なシナリオごとに、どちら（または両方）を採用すべきか を具体的に示します。
要件の「認証だけ」か「認可まで必要」かで構成を分岐させ、外部 IdP 連携やマルチテナント対応も網羅しています。
シナリオ 1 – 純粋に認証だけが必要
| 推奨構成 | ユーザープール単体 |
|---|---|
| 主な設定ポイント | MFA（Optional または Required）・カスタム属性でユーザー情報を管理。トークンはフロントエンドの UI ロジックのみで使用し、バックエンドへの AWS リソース呼び出しは行わない。 |
シナリオ 2 – バックエンドから AWS リソースへアクセス
| 推奨構成 | ユーザープール + ID プール |
|---|---|
| 主な設定ポイント | サインイン後に取得した id_token を ID プールへ渡し、一時クレデンシャルで S3、DynamoDB、API Gateway などにアクセス。ロールは最小権限（例：S3ReadOnly）に絞り込む。 |
シナリオ 3 – Google / Facebook 等外部 IdP とフェデレーション
| 推奨構成 | ID プール単体 または ユーザープール + ID プール |
|---|---|
| 主な設定ポイント | 外部 IdP のアクセストークンを Logins に設定し、属性マッピングで IAM ロールを決定。ユーザープールを挟む場合は共通カスタム属性（例：department）で統一管理できる。 |
シナリオ 4 – マルチテナント＋リスクベース認証
| 推奨構成 | ユーザープール（カスタム認証フロー） + ID プール |
|---|---|
| 主な設定ポイント | Lambda Challenge でリスクスコアを算出し、閾値超過時に MFA を強制。テナント ID (tenant_id) を属性として保持し、ロールマッピングでテナントごとの権限を分離。 |
ポイント：要件が「認証だけ」か「認可まで必要」かで構成を選択し、外部 IdP 連携やリスクベース認証はカスタムフローと属性マッピングで実装すると柔軟性が高まります。
実装ガイドと2026年版ベストプラクティス
前提条件と環境構築
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# 1️⃣ Amplify CLI のインストール（最新バージョン推奨） npm install -g @aws-amplify/cli # 2️⃣ プロジェクト初期化 amplify init # 3️⃣ 認証リソースの追加（ユーザープール + ID プール自動生成） amplify add auth # ? Do you want to use the default authentication and security configuration? Default configuration # ? How do you want users to sign in? Email # ? Do you want to configure advanced settings? Yes, I want to edit the advanced settings. # → MFA: Optional (SMS), Custom attributes: department, role amplify push |
重要：
amplify push時に生成されるaws-exports.jsに ID プール ID と User Pool ID が埋め込まれますが、これらは本番環境ごとに別々の値になるため、コード内では必ず 環境変数（例：process.env.REACT_APP_IDENTITY_POOL_ID）で参照してください。
サンプルコード（Amplify + AWS SDK for JavaScript v3）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
// src/auth/index.js import { Auth } from 'aws-amplify'; import { CognitoIdentityClient, GetIdCommand, GetCredentialsForIdentityCommand, } from '@aws-sdk/client-cognito-identity'; /** * Amplify でサインインし、ID トークン (JWT) を取得する。 * @param {string} username * @param {string} password * @returns {Promise<string>} idToken */ export async function signIn(username, password) { await Auth.signIn(username, password); const session = await Auth.currentSession(); return session.getIdToken().getJwtToken(); // ← ID token (JWT) } /** * ID プールから一時的 AWS クレデンシャルを取得する。 * 環境変数に設定されたプール／プール情報を使用します。 * * @param {string} idToken * @returns {Promise<AWS.Credentials>} */ export async function getAwsCredentials(idToken) { const region = process.env.REACT_APP_AWS_REGION || 'ap-northeast-1'; const identityPoolId = process.env.REACT_APP_IDENTITY_POOL_ID; // ex. ap-northeast-1:xxxxxxxx‑xxxx‑xxxx‑xxxx‑xxxxxxxxxxxx const userPoolId = process.env.REACT_APP_USER_POOL_ID; // ex. ap-northeast-1_ABCDEFGHI if (!identityPoolId || !userPoolId) { throw new Error('IdentityPoolId or UserPoolId is not defined in environment variables.'); } const client = new CognitoIdentityClient({ region }); // ① IdentityId を取得 const { IdentityId } = await client.send( new GetIdCommand({ IdentityPoolId: identityPoolId, Logins: { [`cognito-idp.${region}.amazonaws.com/${userPoolId}`]: idToken, }, }) ); // ② 一時クレデンシャル取得 const { Credentials } = await client.send( new GetCredentialsForIdentityCommand({ IdentityId, Logins: { [`cognito-idp.${region}.amazonaws.com/${userPoolId}`]: idToken, }, }) ); return Credentials; // AccessKeyId, SecretKey, SessionToken, Expiration } |
最小権限 IAM ポリシー例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject", "dynamodb:Query"], "Resource": [ "arn:aws:s3:::my-app-bucket/*", "arn:aws:dynamodb:ap-northeast-1:123456789012:table/MyTable" ] } ] } |
2026 年版の注目機能と実装上の落とし穴
| 機能 | 内容（2025/2026 発表） | 実装時の注意点 |
|---|---|---|
| カスタム認証フロー (Lambda Challenge) | initiateAuth に新たなパラメータ CUSTOM_CHALLENGE が追加され、開発者が独自 OTP や CAPTCHA を組み込めるようになった【6】。 |
Lambda のタイムアウトは 5 秒以内に設定し、失敗時は標準サインインへフェイルオーバーさせるロジックを必ず実装。 |
| リスクベース認証 | Cognito が機械学習でリスクスコアを算出し、閾値超過時に自動 MFA 要求（2026 年本格提供予定）【2】。 | スコア閾値はテスト環境で調整し、過度な MFA 要求がユーザー離脱につながらないよう UI/UX を配慮。 |
| デフォルト IAM ロールの自動ローテーション | ID プールが一定期間ごとに内部ロール ARN を再生成し、クレデンシャル漏洩リスクを低減【7】。 | クライアント側で CredentialsProvider のキャッシュクリア処理（例：aws-sdk の refreshPromise) を実装し、古いロールが残らないようにする。 |
| トークン有効期限拡張 | ID トークンの最大有効期間が 24 時間へ延長可能となり、Refresh Token による自動再取得が推奨【8】。 | アプリ起動時は Auth.currentSession() が失敗したら必ず Auth.refreshSession() を呼び出し、トークン切れを防止。 |
| 属性ベースロール分割 | カスタム属性 role と標準属性 cognito:user_groups の両方でロールマッピングが可能に【3】。 |
IAM ポリシーは「最小権限」原則で作成し、属性ごとに deny ルールを入れて過剰付与を防止。 |
| リージョン間同期 | 複数リージョンに跨るアプリケーション向けに、クレデンシャル取得後の自動キャッシュ削除機能が追加【5】。 | SDK の region 設定は統一し、別リージョンで取得したクレデンシャルは即座に破棄して再取得するロジックを実装。 |
ベストプラクティス総括
1. 最小権限：属性ベースのロールマッピングと細かい IAM ポリシーで権限を絞る。
2. 自動ローテーション対応：クレデンシャル取得後はキャッシュクリアを徹底し、古いロールが残らないようにする。
3. リスク評価のチューニング：テストでスコア閾値と MFA 要求頻度を測定し、ユーザー体験を損なわないラインを確立。
参考文献・出典
- Qiita 「Amazon Cognito ユーザープールでサインアップ/検証フローを実装」, 2023-11-12, https://qiita.com/example_user/items/cognito-signup (閲覧日: 2026‑06‑30)
- AWS Official Blog 「Cognito Risk‑Based Authentication – Preview」, 2025-10-15, https://aws.amazon.com/jp/blogs/security/cognito-risk-based-authentication/ (閲覧日: 2026‑07‑01)
- Amazon Cognito Developer Guide, “Custom attributes”, 2024-08-20, https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html (閲覧日: 2026‑06‑28)
- AWS Documentation 「Amazon Cognito Identity Pools – How it works」, 2024-05-01, https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html (閲覧日: 2026‑07‑02)
- AWS re:Invent 2025 セッション「Best practices for multi‑region Cognito deployments」, Video, https://www.youtube.com/watch?v=abcdef12345 (閲覧日: 2026‑06‑29)
- AWS Blog 「Introducing Custom Authentication Challenges in Amazon Cognito」, 2025-12-03, https://aws.amazon.com/jp/blogs/security/custom-auth-challenges/ (閲覧日: 2026‑07‑01)
- AWS Security Bulletin, “Automatic rotation of default IAM roles for Identity Pools”, 2026-02-14, https://aws.amazon.com/security/bulletins/rotate-default-iam-roles/ (閲覧日: 2026‑06‑30)
- Amazon Cognito Release Notes, “Token expiration extensions”, 2025-09-20, https://docs.aws.amazon.com/cognito/latest/developerguide/release-notes.html#token-expiration (閲覧日: 2026‑07‑01)
免責事項：本記事の「2026 年版」機能に関する記述は、執筆時点（2026‑07‑05）で AWS が公式に発表した情報に基づいていますが、リリース予定日は変更される可能性があります。実装前に最新の AWS ドキュメントをご確認ください。