← AWSサービスの内部原理 コース
130. IDプールはトークンをSTSの一時認証情報に両替する — 拡張フローとロールマッピング
IdPが発行したトークンがIDプールに入り、ロールが選ばれ、STSの一時認証情報になって出てくる——この一直線の変換パイプラインを図で追っていきます。
① IDプールの正体は「フェデレーテッドIDの両替所」
アプリのユーザーサインイン済み or ゲスト
IdPが証明したトークン/アサーションを持ち込む
IDプールfederated identitiesの目録=両替所
一時的なAWS認証情報AWSを触るための鍵
- 「An Amazon Cognito identity pool is a directory of federated identities that you can exchange for AWS credentials.」(公式)
- 「Identity pools generate temporary AWS credentials for the users of your app, whether they've signed in or you haven't identified them yet.」(公式)
- 認証暗号編で見たSTSの一時認証情報3点セット(アクセスキー・シークレットキー・セッショントークン)が、ここで手に入る「鍵」の正体。骨格は同じで、入口がIAMユーザーではなく外部IdPのトークンになっただけ。
IDプールは認証の場所ではなく、外部IdPが発行した証明を「AWSを触るための一時認証情報」に両替する所。ゲストにも認証済みユーザーにも鍵を出せる。
② 拡張(簡略化)フロー — 2ステップでIDプールに丸投げ
アプリ
① GetId(証明トークンを提示)
IDプールアイデンティティIDを発行
② GetCredentialsForIdentity(identity ID + 同じ証明)
IDプール(裏側)IAMロール選択 + AssumeRoleWithWebIdentity相当
③ この認証情報でAWS APIに署名
一時的なAWS認証情報有効期間1時間
- Order of operations: GetId → GetCredentialsForIdentity(公式)
- 「The AWS credentials from enhanced authentication are valid for one hour.」— 拡張フローの認証情報の有効期間は1時間(公式)。
- 「Your application doesn't need to make additional API requests to AWS STS.」— アプリは自分でSTSを叩かなくてよい(公式)。ロール選択のロジックをクライアントに埋め込む必要もない。
- 「This operation is functionally equivalent to calling GetOpenIdToken, then AssumeRoleWithWebIdentity」(公式)
拡張フローはGetId→GetCredentialsForIdentityの2ステップのみ。ロール選択もSTS呼び出しもIDプールが肩代わりし、返ってくる認証情報は1時間有効。
③ 基本(classic)フロー — 開発者が自分でSTSを叩く3ステップ
アプリ
① GetId
IDプールidentity IDを返す
② GetOpenIdToken
IDプールIDプール発行トークンを返す
③ AssumeRoleWithWebIdentity(そのトークンを提示)
AWS STS一時的なAWS認証情報
- Order of operations: GetId → GetOpenIdToken → AssumeRoleWithWebIdentity(公式)
- 「The AssumeRoleWithWebIdentity request in the classic workflow grants your app a greater ability to request credentials for any AWS Identity and Access Management role that you have configured with a sufficient trust policy. You can also request a custom role session duration.」(公式)
- 重要な制約: ロールマッピングを使うIDプールでは基本フローは使えない。GetOpenIdTokenを試みるとエラー文字列「Basic (classic) flow is not supported with RoleMappings, please use enhanced flow.」が返る(公式)。
- ベストプラクティス: 「When you create a new identity pool, don't activate basic (classic) authentication by default」(公式)。
基本フローはGetId→GetOpenIdToken→AssumeRoleWithWebIdentityの3ステップで、STSを自分で呼ぶぶん柔軟(任意ロール・カスタムセッション長)。ただしロールマッピングを使うIDプールでは使えない。
④ 入口の形はIdPごとに違うが、出口は同じAWS認証情報
ユーザープール→ IDトークン
OIDC→ IDトークン
SAML 2.0→ SAMLアサーション
ソーシャル→ アクセストークン
クレームをAssumeRoleWithWebIdentityリクエストに変換
IDプール両替所
一時的なAWS認証情報どのIdPでも同じ形
- 公式のProvider / Authentication artifact表: Amazon Cognito user pool→ID token、OpenID Connect (OIDC)→ID token、SAML 2.0→SAML assertion、Social provider→Access token。
- 「Amazon Cognito customizes user claims from SAML, OAuth, and OIDC providers into an AssumeRoleWithWebIdentity API request for short-term credentials.」(公式)
渡すものの形(IDトークン/SAMLアサーション/アクセストークン)はIdPで変わるが、両替後に得るのは常に同じAWS認証情報。IDプールが差異を吸収する。
⑤ 認証済み/ゲストの分岐は信頼ポリシーのamr条件で決まる
IDプール発行トークンamrクレーム(多値)
ロールの信頼ポリシーが判定
信頼ポリシーaud=このIDプール かつ amrにauthenticatedを含むか
認証済み用ロールYes: 広めの権限
ゲスト用ロールNo: 最小権限
- 信頼ポリシーはForAnyValue:StringLikeで「cognito-identity.amazonaws.com:amr: authenticated」を判定(公式のトラストポリシー例)。amrは「one of the array members of the multi-value amr claim ... has the value authenticated」の多値クレーム。
- aud条件で「そのIDプール宛のトークンか(StringEqualsでIDプールIDと一致するか)」も同時に制限する(公式)。
- 「Set up different IAM roles for your application: one for unauthenticated users, and one for authenticated users.」(公式・authentication-flow.htmlより)。デフォルトロールは「These roles have effectively no permissions granted(実質的に権限ゼロ)」で作られるので自分で絞る。
- basicsLink: 判定条件がIAMユーザーのARNからフェデレーテッドなトークンのamrクレームに変わっただけで、信頼ポリシーの骨格は認証暗号編と同じ。ゲスト用ロールの存在は最小権限原則の一例。
認証済みかゲストかは、信頼ポリシーがamrクレームにauthenticatedが含まれるかで判定する。信頼ポリシーの仕組みは既習のまま、判定材料がトークンのクレームに変わっただけ。
⑥ 認証済みユーザーのロールの決め方 — トークンベースとルールベース
認証済みユーザーロール決定方式
トークンベースcognito:preferred_role / cognito:roles
ルールベースEquals/NotEqual/StartsWith/Contains
そのロールを引き受けpreferred_role=最良Precedence
最初に一致したロール上から順に評価、最初の一致が勝つ
- cognito:preferred_roleは「the role from the group with the best (lowest) Precedence value」。単一ロールならそれ、複数で最良が定まらなければこのクレームは設定されない(公式)。cognito:rolesは「a comma-separated string containing a set of allowed role ARNs」。
- 一致順序: 「Rules are evaluated in order, and the IAM role for the first matching rule is used」「The first matching rule takes precedence.」(公式)。NotEqualでクレーム自体が存在しない場合、そのルールは評価されない。どれも一致しなければRole resolution設定(既定の認証済みロールを使う/リクエストを拒否)に従う。
- 上限: 「For each user pool or other authentication provider that you configure for an identity pool, you can create up to 25 rules. This limit is not adjustable.」— IdPごと最大25ルール、調整不可(公式)。
- 注意: 「If the claim that you are mapping to a role can be modified by the end user, any end user can assume your role」— エンドユーザーが書き換えられるクレームを昇格ロールに紐づけてはいけない(公式)。
- basicsLink: 「上から順・最初に一致したものが勝つ」というルール評価は、IAMポリシー評価編で見た評価順序のミニチュア版。トークンベースのcognito:roles(許可集合の中から選ぶ)も、最小権限原則で「渡してよいロールの範囲」を先に絞る発想。
認証済みのロールは、IDトークンのクレームをそのまま使うトークンベースか、クレーム値を順に判定して最初の一致を採るルールベースで決める。ルールはIdPごとに最大25個で、評価順序の考え方は既習のIAMポリシー評価と同じ。