← AWSサービスの内部原理 コース
126. Cognitoは2つの別の仕事を1つの名前で売っている — ユーザープール(誰か)とIDプール(AWSへの切符)
「Cognito」という1つの名前の裏で、まったく別の2つのサービス——「あなたが誰かを証明する窓口」と「その証明をAWSの一時認証情報に両替する窓口」——が動いていることを、公式の定義と2本の矢印で図に追っていきます。
① 「Cognito」という名前が隠している分割線
「Cognito」という1つの名前
ユーザープールUser Pool
「誰であるか」を証明する窓口IDプールIdentity Pool
証明をAWSの一時認証情報に両替する窓口「Cognitoが分からない」の正体は、たいてい「1つの名前の下に別々の2サービスがあると気づいていない」こと。まず引くべきは、認証を担う箱と、認可の世界へ橋渡しする箱を分ける線です。
② ユーザープール=「ユーザーの台帳」であり、アプリから見ればOIDCのIdP
ユーザープールa user directory for web/mobile app authentication and authorization
認証の結果として JWT を発行
サインアップ
サインイン
MFA
Lambdaトリガー
IDトークン
アクセストークン
リフレッシュトークン
ユーザープールは「誰であるか」を証明する台帳で、成功の証拠として JWT(ID/アクセス/リフレッシュの3枚)を発行する。アプリにとっては、ただのOIDCのIdPに見える——ここまでにAWSの認証情報は一切出てきません。
③ IDプール=「証明をAWSの一時認証情報に両替する両替所」
ユーザープールトークン
SAML assertion
OIDCトークン
ソーシャル(Google等)
内部でSTSを呼ぶ
IDプールa directory of federated identities that you can exchange for AWS credentials
AssumeRoleWithWebIdentityトークン→IAMロールを引き受ける
一時的なAWS認証情報temporary AWS credentials
→ S3/DynamoDBへの署名付きリクエストIDプールはトークンを受け取り、内部でSTSの AssumeRoleWithWebIdentity を叩いて一時的なAWS認証情報に「両替」する。入口はユーザープールに限らず、SAML・OIDC・ソーシャルも直接受け付ける——だからこの箱は「Cognitoのユーザー台帳」とは独立して使えます。
④ ゲスト(未認証)にも切符は出る
IDプールは未サインインでもcredentialsを配れるwhether they've signed in or you haven't identified them yet
サインインで昇格
未認証(ゲスト)仮の切符・狭い権限のIAMロール
認証済み本人向けの切符・属性で選ぶロール
「切符を出す」のに本人確認は必須ではない——IDプールはゲストにも狭い権限の一時認証情報を配れる。これがユーザープール(認証が前提の台帳)との決定的な性格の違いです。
⑤ 2つの箱をつなぐ1本の矢印——JWTが入力になる
公式の対比User pools = OIDC IdP for SSO apps / Identity pools = AWS identity provider for IAM authorization
IDトークン(JWT)が入力になる
ユーザープール誰か?を証明→JWTを発行
IDプールAWS認証情報へ両替→STSで一時credentials
両者は「認証(誰か)→ 認可の切符(IAM)」という順で連結できる。ユーザープールの出したJWTがIDプールの入力になる、この1本の矢印がCognitoの全体像。次からのレッスンは、左の箱(JWT・3トークン・SRP・Hosted UI)と右の箱(STS交換・ロールマッピング)に分かれて深掘りしていきます。