Web アプリやモバイルアプリに会員ログインをつける仕事を任されて、Cognito を調べはじめると「ユーザープール」と「アイデンティティプール」という似た名前の部品が出てきます。IAM や IAM Identity Center は分かっていても、アプリの利用者を相手にする場合の考え方は別です。この記事では、2 つの部品を「誰かを確かめる」と「AWS を使わせる」という 2 つの問いに分けて整理します。
この記事の結論
- Cognito は Web・モバイルアプリ向けの ID 基盤で、「誰か」と「何をしてよいか」という 2 つの問いに、別々の部品で答えます。
- ユーザープールは利用者のディレクトリです。登録・サインイン・MFA を担い、JWT（ID・アクセス・リフレッシュの 3 種）を発行します。
- アイデンティティプールは、信頼したトークンを STS 経由の一時的で権限の絞られた AWS 認証情報に交換します。ゲスト向けの認証情報も出せます。
- 2 つは独立しています。ユーザープールだけで API を守れ、利用者の端末から AWS を直接呼ばせるときだけ両方をつなぎます。
- 社員が AWS を使う入口は Identity Center、アプリの利用者は Cognito、と対象で使い分けます。
Amazon Cognito とは何か｜アプリの利用者のための ID 基盤
Amazon Cognito は、Web・モバイルアプリの利用者のサインインと、アクセス権の付与を引き受けるマネージドサービスです。パスワードの保管、サインインの判定、MFA のような面倒で間違えると事故になる部分を、自前で作らずに済ませるのが目的です。
ここで先に押さえたいのは、Cognito が答える問いが 2 つあることです。
| 問い | 中身 | 担当する部品 |
|---|---|---|
| あなたは誰か | 利用者を登録し、サインインを確かめる（認証） | ユーザープール |
| あなたは何をしてよいか | 利用者に AWS のリソースを使う権限を渡す（認可の一部） | アイデンティティプール |
名前が似ているので混同されますが、片方は「本人確認とトークンの発行」、もう片方は「トークンを AWS の認証情報に替える」で、出てくるものも違います。この違いを最初に押さえると、以降の話が整理できます。
なお、認証基盤そのものは AWS が運用するマネージドですが、どの利用者にどの権限を渡すかというポリシーの設計や、トークンの扱い方は利用者側の責任です。これは AWS の責任共有モデルの考え方どおりで、「クラウド内のセキュリティは利用者」という分担は Cognito でも変わりません。
2つの部品
ユーザープールは誰か確かめ、アイデンティティプールはAWS を使わせる
ユーザープール
誰か確かめる
- 出すもの：JWTID・アクセス・リフレッシュの 3 種
- 主な機能登録・サインイン・MFA
- 向く場面会員ログイン、自前 API をトークンで守る
アイデンティティプール
AWS を使わせる
- 出すもの：一時的な認証情報STS 経由で期限つき
- 主な機能トークンの交換、ゲスト向けの設定
- 向く場面端末から S3 などを直接使わせる
ユーザープールとは何か｜台帳・サインイン・トークンの発行
ユーザープールは、アプリの利用者のディレクトリ（台帳）です。新規登録、サインイン、パスワードの再設定、MFA といった、ログインまわりの機能がひとまとまりになっています。ログイン画面を自前で作りたくない場合は、Cognito が用意するホスト型のログイン画面を使い、OAuth 2.0 の仕組みで外部の IdP と連携することもできます。公式のドキュメントでは、この画面が現在「managed login」という呼び方でも併記されています。
発行される 3 つのトークン
サインインに成功すると、ユーザープールは JWT（JSON Web Token）を発行します。公式ドキュメントでは、次の 3 種類が説明されています。
| トークン | 用途 |
|---|---|
| ID トークン | 利用者が誰か（名前やメールなどの属性）をアプリに伝える |
| アクセストークン | API などに「この利用者の代わりに呼んでいる」と示す |
| リフレッシュトークン | 上の 2 つの有効期限が切れたとき、再ログインなしで新しく取り直す |
ここでの要点は、ユーザープールが出すのは「トークン」であって、AWS の認証情報ではないことです。JWT をそのまま持っていても、S3 や DynamoDB を直接呼べるわけではありません。トークンは、受け取った側（自前の API や API Gateway など）が検証して、「確かにこのユーザープールが認めた利用者だ」と判断するために使います。
ソーシャルログインの場合も同じです。Google などの外部 IdP でサインインしても、ユーザープールが間に入って、アプリ側には同じ形のトークンとして返せます。アプリは IdP ごとの違いを意識せず、トークンの扱いだけを実装すれば済みます。
CHECK 1ここまでの確認
利用者がサインインに成功したあと、ID トークンやアクセストークンを発行するのはどの部品か?
答えと解説
答え: 1. ユーザープール
ユーザープールは利用者の台帳であり、サインインの成否を判断して JWT を発行します。「ユーザープールとは何か」の章を読み直してください。
アイデンティティプールとは何か｜トークンを一時的な AWS 認証情報に替える
アイデンティティプールは、「確かめられた利用者」に AWS を使わせるための部品です。ユーザープールや外部 IdP が出したトークンを受け取り、それを信頼できるものとして、STS 経由で一時的な AWS 認証情報に交換します。
この仕組みの利点は、アプリに長期のアクセスキーを埋め込まずに済むことです。端末の中に置いたキーは、取り出されれば誰でも使えます。一時的な認証情報なら、期限が来れば使えなくなり、渡す権限も IAM ロールで絞れます。
権限は IAM ロールで絞る
渡される認証情報の権限は、アイデンティティプールに紐づけた IAM ロールのポリシーで決まります。たとえば、利用者ごとに S3 の自分専用の場所だけに書き込めるようにしたいときは、ポリシーの中で利用者の ID を表す変数を使い、プレフィックスを利用者ごとに限定します。IAM ポリシーの書き方そのものは IAM とは の延長にあたる話です。
ゲストにも出せる
アイデンティティプールは、サインインしていないゲスト向けに、さらに権限の小さい認証情報を出す設定もできます。ログイン前の画面で何かを AWS に送る必要があるときなどに使いますが、許可するかどうかは設計の判断です。ゲストに渡す権限は、最小限にとどめる前提で考えます。
CHECK 2ここまでの確認
アプリが利用者の端末から S3 を直接呼ぶために、有効期限のある認証情報を渡す部品はどれか?
答えと解説
答え: 2. アイデンティティプール
アイデンティティプールは、信頼したトークンを STS の一時的な認証情報に交換します。ユーザープールが出すのは AWS の認証情報ではなく、トークンです。「アイデンティティプールとは何か」の章を参照してください。
2 つはどう組み合わせるか｜アプリ → ユーザープール → アイデンティティプール → AWS の流れ
2 つの部品は独立していて、使うのは片方だけでも構いません。つなぐときの流れは次のとおりです。
- 利用者がアプリでサインインする
- ユーザープールが本人を確かめ、JWT を発行する
- アプリがその JWT をアイデンティティプールに渡す
- アイデンティティプールが STS から一時的な認証情報を受け取って返す
- アプリはその認証情報で、S3 や DynamoDB などを呼ぶ
つなぐ流れ
サインインから AWS の呼び出しまで5 つの駅を通る
-
サインイン
利用者がアプリで
-
JWT を発行
ユーザープール
-
トークンを渡す
アイデンティティプールへ
-
一時認証情報
STS が発行
-
AWS を呼ぶ
S3・DynamoDB
ユーザープールだけで足りるとき
自前の API やバックエンドを、トークンで守るだけの構成では、アイデンティティプールは要りません。たとえば、会員だけが呼べる API を作る場合は、ユーザープールで登録・サインイン・MFA を扱い、発行された JWT を API Gateway などで検証します。利用者の端末が AWS を直接呼ぶわけではないので、AWS の認証情報を渡す必要がないからです。
両方をつなぐとき
端末のアプリから、S3 へ直接アップロードしたい、といった場面では、アイデンティティプールが必要になります。サーバーを経由せず、利用者ごとに範囲を絞った認証情報を端末に持たせられるからです。ただし、経由させる設計のほうが管理しやすい場合も多いので、「直接呼ばせる必要が本当にあるか」を先に考えます。
| 目的 | 構成 |
|---|---|
| 会員だけが自前の API を呼べるようにする | ユーザープール＋トークンの検証 |
| 端末から S3 などを直接使わせる | ユーザープール＋アイデンティティプール |
| ログイン前のゲストに最小限の権限を渡す | アイデンティティプール（ゲスト） |
CHECK 3ここまでの確認
自前のバックエンドをトークンで守るだけなら、どの構成で足りるか?
答えと解説
答え: 2. ユーザープールだけで足りる
2 つのプールは独立しています。AWS のリソースを利用者の端末から直接呼ばせないなら、トークンを検証するだけで済み、アイデンティティプールは要りません。「組み合わせ」の章を読み直してください。
IAM・Identity Center とはどこが違うのか｜社員向けと利用者向け
Cognito と似た名前の仕組みが IAM Identity Center ですが、対象としている人が違います。
対象で選ぶ
誰が使うかで入口が決まる
使う人と場面
入口
使う人と場面: 社員が AWS を使う
入口: IAM Identity Center
使う人と場面: アプリの利用者がログインする
入口: Cognito ユーザープール
使う人と場面: アプリの利用者が AWS を直接使う
入口: アイデンティティプール
- 社員（組織で働く人）が AWS アカウントに入る入口は、IAM Identity Center です。権限は許可セットで配ります。詳しくは IAM Identity Center とは にあります。
- 自社のアプリを使うお客様や会員のサインインは、Cognito のユーザープールです。
- そのお客様に AWS のリソースを直接使わせるときだけ、アイデンティティプールが加わります。
IAM ユーザーは AWS アカウントの中の権限主体で、アプリの会員の台帳として使うものではありません。会員が増えるたびに IAM ユーザーを作ると、管理も権限の設計も破綻します。「アプリの利用者は Cognito」と覚えておけば、迷うことは減ります。
CHECK 4ここまでの確認
社員が複数の AWS アカウントにサインインする入口を束ねるのは、どちらか?
答えと解説
答え: 2. IAM Identity Center
Identity Center は社員（ワークフォース）向け、Cognito はアプリの利用者向けです。対象で使い分けます。「違い」の章を読み直してください。
実務で最初に確認すること
導入前に、次の 3 つを確かめておくと、後で設計をやり直さずに済みます。
- トークンの検証先はどこか。 自前のバックエンドか、API Gateway か。誰がトークンを検証するのかを決めます。検証されないトークンは、ただの文字列です。
- ソーシャルログインは必要か。 必要なら、どの IdP と連携するか、利用者の属性をどう対応づけるかを決めます。
- ゲストに権限を渡す必要があるか。 必要がなければ、アイデンティティプールのゲスト許可は切っておきます。
料金や無料枠の数値は変わるので、この記事には書きません。見積もりの段階で、公式の料金ページを確認してください。
Cloudory 執筆者（AWS 認定 全冠）
「ユーザープールは誰かを確かめ、アイデンティティプールは AWS を使わせる」。この 2 行を言えれば、Cognito の話の大半は整理できます。次は、権限の設計そのものを扱う 権限設計の記事 側の記事も読み、渡す権限をどう絞るかまで考えてみてください。
まとめ
- Cognito は、アプリの利用者のための ID 基盤で、「誰か」と「何をしてよいか」を別々の部品で扱います。
- ユーザープールは台帳とサインイン、JWT の発行を担います。AWS の認証情報は出しません。
- アイデンティティプールは、トークンを一時的な AWS 認証情報に替えます。権限は IAM ロールで絞ります。
- 2 つは独立しており、API をトークンで守るだけならユーザープールで足ります。
- 社員は Identity Center、アプリの利用者は Cognito、と対象で選びます。
参照ソース
- Amazon Cognito とは（AWS 公式ドキュメント） — ユーザープールとアイデンティティプールの定義、使い分け、2 つをつなぐ流れの根拠（2026-11 時点の記述）
- ユーザープールのトークンの利用（AWS 公式ドキュメント） — ID・アクセス・リフレッシュの 3 種類のトークンと用途の根拠
- AWS の責任共有モデル（AWS 公式） — 認証基盤の運用は AWS、ポリシーとトークンの扱いは利用者、という分担の根拠
