Amazon Cognitoとは ― ユーザープールとIDプール

自分で作ったWebアプリやスマホアプリに、会員登録とログインの機能を付けたい。そのときAWSで使えるのが、Amazon Cognitoです。サインインを受け持つだけでなく、サインインした利用者に、AWSのリソースを使う一時的な権限を渡すこともできます。

Cognitoは、役割の違う2つの機能でできています。利用者が誰かを確認するのがユーザープールです。どのAWSのリソースを使えるかを決めるのがIDプールです。2つは別々に使うことも、組み合わせて使うこともできます。

トークンで利用者を確認する考え方はOAuthの記事、権限の仕組みはIAMの記事で説明しています。

IAMは、AWSのアカウントの中の識別情報を管理するサービスです。管理する相手は、AWSを操作する社員や開発者、AWSを呼び出すアプリです。Cognitoが管理するのは、自分が作ったアプリを使う利用者です。

ユーザープールに登録した利用者は、IAMのユーザーではありません。そのため、利用者がAWSのリソースを直接使うときは、IDプールがIAMロールの一時的な認証情報を渡します。そのロールの権限は、IAMのポリシーで決めます。

ユーザープールは、アプリの利用者の名簿です。利用者は、ユーザー名とパスワードやパスキーなどでサインインします。サインインに成功すると、ユーザープールはIDトークン・アクセストークン・リフレッシュトークンの3つを返します。

利用者が自分でアカウントを作るサインアップも、ユーザープールが受け持ちます。サインアップを有効にすると、インターネット上の誰でもアカウントを作れるようになります。公開アプリでなければ、管理者だけが利用者を追加する設定にします。

サインインの画面は、自分で作ることも、Cognitoが用意するマネージドログインのページを使うこともできます。このページには、サインアップ・サインイン・多要素認証・パスワードの再設定の画面があります。多要素認証の方法には、SMSのメッセージや、時刻をもとにしたワンタイムパスワードがあります。ページへの攻撃は、AWS WAFのWeb ACLをユーザープールに付けて防ぎます。

3つのトークンの違い

3つのトークンは、使い道が違います。IDトークンとアクセストークンは、JWTという形式のデータです。JWTは、OAuthの記事のOpenID Connectの節でも、IDトークンの形式として説明しています。

JWTの中身は、誰でも読めて、書き換えることもできます。そのため、トークンを受け取ったアプリやAPIは、署名をユーザープールの公開鍵で検証します。書き換えられたトークンは、署名が合わずに検証に失敗します。

APIを呼ぶときは、アクセストークンをリクエストに付けて送ります。API Gatewayの記事で説明したとおり、トークンの検証をAPI Gatewayに任せることもできます。

GoogleやAppleのアカウントでサインインする

ユーザープールは、外部のIdPでのサインインも受け付けます。IdPは、利用者の認証を受け持つサービスのことです。Google・Facebook・Amazon・AppleのアカウントでのサインインにはOAuth 2.0を使います。

企業の認証基盤とは、SAMLやOpenID Connectで連携できます。どのIdPでサインインしても、アプリが受け取るのはユーザープールが発行した同じ形式のトークンです。1つのIdPの認証で複数のサービスを使う仕組みは、多要素認証の記事でシングルサインオンとして説明しています。

サインアップやサインインの途中に、独自の処理を追加することもできます。このときは、CognitoがLambdaの関数を呼び出します。

IDプールは、信頼できるIdPが発行したトークンを受け取ります。IDプールは、受け取ったトークンをIAMロールの一時的なAWSの認証情報に変換して返します。アプリはその認証情報で、S3やDynamoDBのAPIを直接呼び出します。

受け取れるトークンは、ユーザープールのIDトークンだけではありません。GoogleやAppleなどのトークンや、SAMLのアサーションも受け取れます。そのため、ユーザープールを置かずに、IDプールだけを使う構成もとれます。

どのIAMロールを渡すかを決める

IDプールには、ログインした利用者用のロールと、ログインしていない利用者用のロールを設定できます。ログインしていない利用者は、ゲストとして扱われます。AWSのドキュメントは、ゲストのロールに、ログインした利用者より狭い権限を与えるよう勧めています。

利用者ごとにロールを選ぶこともできます。たとえば、IDトークンの中の情報やユーザープールのグループで、渡すロールを切り替えます。どのロールにも、最小権限の原則に沿ったポリシーを付けます。

ロールの信頼ポリシーには、自分のIDプールだけがそのロールを使えるという条件を入れます。この条件が無い信頼ポリシーは、IAMが保存を受け付けません。

AWSが勧める拡張フローでは、IDプールがアプリに代わって、AWS STSにロールの引き受けを依頼します。AWS STSは、IAMロールの一時的な認証情報を発行するサービスです。こうして渡される認証情報は、1時間で期限が切れます。

2つのプールを組み合わせると、ログインした利用者のアプリからS3を直接使えます。アプリが持つAWSの認証情報は、IDプールが渡した、期限のあるものだけです。AWSのアクセスキーをアプリに入れておく必要はありません。

①と②では、アプリがユーザープールでサインインし、3つのトークンを受け取ります。③と④では、アプリがIDトークンをIDプールに渡し、一時的な認証情報を受け取ります。⑤では、その認証情報で署名したリクエストをS3に送ります。

S3がリクエストを許可するかどうかは、IDプールが選んだIAMロールのポリシーで決まります。ロールの権限は、そのロールを受け取る利用者の全員に同じように適用されます。利用者ごとに範囲を分けたいときは、ポリシーの条件と変数を使います。

ユーザープールは「この利用者は誰か」に答えます。IDプールは「どのAWSのリソースを使えるか」に答えます。AWSのリソースを利用者のアプリから直接使わないなら、ユーザープールだけで十分です。

次の図でアプリでやりたいことを選ぶと、使うプール・受け取るもの・理由が切り替わります。

ユーザープールの料金は、その月にサインインなどをした利用者の数で決まります。この数を、月間アクティブユーザーと呼びます。IDプールの利用には、追加の料金がかかりません。

ユーザープールには、Lite・Essentials・Plusの3つのプランがあります。新しく作るユーザープールの既定はEssentialsです。上のプランほど使える機能が増えます。Plusには、不審なサインインを防ぐ機能があります。

LiteとEssentialsには、月10,000人までの無料利用枠があります。対象は、ユーザープールに直接サインインする利用者と、ソーシャルのIdPでサインインする利用者です。この無料利用枠は、AWSを使い始めて12か月がたっても終わりません。SAMLやOpenID Connectの外部のIdPでサインインした利用者は、プランによらず月50人までが無料です。

以上の仕組みは、2026年10月30日にAWSの料金ページで確認したものです。AWSの料金の考え方は料金の記事にまとめています。単価は、Cognitoの料金ページで確認してください。

• AWS「What is Amazon Cognito?」（定義、2つのプールの役割と比較、組み合わせ方）
• AWS「Authenticating users with Amazon Cognito user pools」（サインアップ、サインイン、外部のIdP、マネージドログイン）
• AWS「Understanding user pool JSON web tokens (JWTs)」と、その下のIDトークン・アクセストークン・リフレッシュトークンのページ（中身と有効期限）、APIリファレンス「CreateUserPoolClient」（有効期限の既定値）
• AWS「Verifying JSON web tokens」（署名の確かめ方）
• AWS「Amazon Cognito identity pools」（IDプールの役割、受け取れるトークン、ゲストのアクセス）
• AWS「Identity pools authentication flow」（認証情報を受け取る流れ、AWS STSとの関係、1時間の有効期限）
• AWS「IAM roles」（ログインした利用者とゲストのロール、信頼ポリシー）
• AWS「User pool feature plans」と「Amazon Cognito pricing」（プラン、料金の決まり方、無料利用枠。2026-10-30確認）