Cognitoのユーザープールと、IDプール。認証と認可で整理したら混乱が消えた

おはようございます、YASUです。

以前、API Gatewayの認証でCognitoオーソライザーを取り上げましたが、DVAの勉強を進めると、Cognitoには「ユーザープール」と「IDプール」という、名前のよく似た2つの仕組みが出てきます。これがどうにも混同しやすく、模擬試験でも選択肢を取り違えました。今日はその違いを、1つの軸で整理します。

結論

ユーザープールは「あなたは誰か」を確認する認証の仕組み、IDプールは「あなたにAWSの何を使わせるか」を決める認可の仕組みでした。1つのCognitoの中に、役割の違う2つの部品が入っている、と考えると整理しやすかったです。

まず、認証と認可の違い

混乱の元は、そもそもの言葉の違いでした。

権限を確認するには、まず本人を特定する必要があるので、通常は認証が先、認可が後になります。この順番が、2つのプールの関係にもそのまま現れていました。

ユーザープール:ログインの受付係

ユーザープールは、アプリのユーザーを管理するユーザーディレクトリです。サインアップ(新規登録)やサインイン(ログイン)の機能を提供してくれます。GoogleやFacebook、Appleなど、外部のIDプロバイダー経由のログインにも対応しています。

ログインに成功すると、JWT(JSON Web Token)というトークンが発行されます。これは「この人は、確かにログインを済ませた本人です」という証明書のようなものです。以前紹介したAPI GatewayのCognitoオーソライザーは、まさにこのトークンを検証して、リクエストを通すかどうかを判断していました。

IDプール:AWSの一時的な入館証を渡す係

一方のIDプールは、ユーザーに「AWSのサービスを使うための、一時的な認証情報」を渡す仕組みです。例えば、アプリから直接S3に写真をアップロードしたり、DynamoDBを読み書きしたりしたい場合に使います。

ここで渡される認証情報は、AWS STS(Security Token Service)が発行する、期限付きのものです。ずっと使える鍵を配るのではなく、使う間だけ有効な入館証を貸し出す、というイメージです。ユーザーに配るのが固定のアクセスキーではなく一時的な認証情報だという点は、以前のgit-secretsの記事で触れた、アクセスキーを直接扱う危うさへの対策としても、納得感がありました。

IDプールのもう1つの特徴は、ログインしていない匿名のゲストユーザーにも、限定的な権限を与えられることです。認証済みのユーザー用と、未認証のゲスト用で、それぞれ別のIAMロールを割り当てておく仕組みになっています。

2つはどう繋がるのか

最初は「ユーザープールとIDプールのどっちを使えばいいの?」と二択で考えていましたが、実は両方を組み合わせて使う場面が多い、というのが分かって腑に落ちました。流れはこうです。

1. ユーザーがユーザープールにログインする
2. ログイン成功の証明として、IDトークンを受け取る
3. そのIDトークンをIDプールに渡す
4. IDプールが、STSから一時的なAWS認証情報を取得して返す
5. アプリはその認証情報を使って、S3やDynamoDBにアクセスする

つまり、ユーザープールが「受付で本人確認をして会員証を発行する係」、IDプールが「その会員証を見せると、特定の部屋に入れる入館証を貸してくれる係」という役割分担です。会員証(IDトークン)そのものは、AWSのサービスを直接操作するための鍵ではなく、あくまで本人確認の証明にすぎない、という点が重要でした。

どちらを選ぶか、場面で整理する

試験では、問題文の要件から「認証の話か、AWSリソースへのアクセス権限の話か」を見分けるのが、最初のステップになりそうです。

見落としやすい点

外部のIDプロバイダー(Googleなど)でのログインは、ユーザープール経由でもIDプール経由でも扱える、と調べていて知りました。「ソーシャルログインならIDプール」と決めつけるのは危ない、という点は、試験のひっかけになりやすそうだと感じました。また、IDプールで渡される一時的な認証情報は、IAMロールの権限で制限されるため、前に整理したIAMの考え方(実行ロール、最小権限)とも繋がっています。

まとめ

• ユーザープールは認証(あなたは誰か)、IDプールは認可(AWSの何を使わせるか)を担当する
• ユーザープールはログイン機能とJWTトークンを提供し、API GatewayのCognitoオーソライザーが使うのもこのトークン
• IDプールはSTSを通じて、期限付きの一時的なAWS認証情報を発行する
• 両方を組み合わせ、ユーザープールのIDトークンをIDプールに渡して、AWS認証情報を受け取る流れが多い
• ログインしていないゲストに限定的な権限を与えられるのは、IDプールの特徴

API Gatewayの回で出てきたCognitoオーソライザーが、今回の整理で「ユーザープール側の話」だったと位置づけられて、点が線で繋がった感覚がありました。それでは、また明日!