AWS CognitoのユーザープールトークンとIDプールトークンはどのように使い分けるのか？🤔

こんにちは！

認証処理の構築は、開発の中で複雑になりやすいですよね。状態を意識しなければいけないプログラミングは、考えることが多くなりややこしくなりがちです…。

そんな認証処理の構築を、わたし達は AWS Cognito と AmplifySDK を用いて非常にシンプルかつ簡単に実装しています。

本記事では、AWS Cognito 初学者が理解に苦しむユーザープールとIDプールの違いについて解説していきたいと思います！

はじめに

AWS Cognitoのワークフロー

AWS Cognito は、AWS の各種サービスへ接続する際に使用する、認証・認可のトークンを発行してくれます。具体的には下記のようなワークフローで使用します。

1. ユーザーにパスワード、Emailを入力させてCognitoへリクエスト
2. ユーザープールトークン(認証トークン)を取得
3. ユーザープールトークンをIDプールトークン(認可トークン)と交換
4. 認証もしくは認可トークンをヘッダーに設定しAWSの各サービスへリクエスト

認証・認可トークンを使用したユースケースの一例も紹介しておきますね。

認可トークン

• S3バケットのPre-Signed(署名付き) URLを発行
• DynamoDBへのオペレーション
• SQSのキューへメッセージ送信
• SNSへのトピック作成

認証トークン

• API Gatewayへのリクエスト
• AppSyncへのリクエスト

ユーザープールとIDプールの違い

ユーザープール	認証トークンを発行します。
IDプール	STSと連携し、アクセストークン（認可）を発行します。 これにより、フロントエンドからの各種 AWS サービスへのリクエストに、認可を提供することが可能です。

では、AWS における認証トークンと認可トークンの扱いはどのようになるのかを解説していきます。

ユーザープールトークンの（認証トークン）の扱い

結論から言うと、API Gateway、AppSyncへのリクエストを、認証されたユーザーのみに制限するときに使用します。リクエストヘッダーのAuthorizationに認証トークンを設定することで、非認証のリクエストに対し 401 ステータスをレスポンスできます。

また、AppSyncではVTLテンプレートをカスタムすることで、ユーザープールグループと連携し、ユーザーが属しているユーザープールグループで呼び出しを制御することが可能です。例えばユーザーの削除に関するAPIは、Adminグループに属しているユーザーのみ使用できるようにことができます。

IDプールトークンの（認可トークン）の扱い

こちらも結論から言うと、フロントエンドからAWS SDK を使用してAWS サービスを直接呼び出している際に使用します。（これだけではないですが、主要なユースケースと言えます）

逆に言うと、アプリケーションの全ての機能のAppSync、API Gatewayを通して処理している場合は不要です。

認可トークンを使用する最も多いシーンとしては、フロントエンドから S3 の Pre-Signed(署名付き) を発行するシーンです。誰でもPUTができてしまっては問題ですので、そんな時は S3 へのアクセスを認可トークンで制御します。

また、少しややこしくなるかもしれませんが、ID プールには非認証のユーザーへ認可トークンを渡すことも可能です。この場合は Guest ユーザーに対する認可トークンとして扱うことが多いです。

まとめ

AWS で開発を行う際は、AWS Cognito はまず間違いなく必須なサービスです。ユーザープールとIDプールの違いを抑えて、認証・認可をうまく使い分けましょう。

余談ですが、私たちが普段開発する際は、なるべく認可トークンを発行するシーンを減らします。フロントエンドの実装が複雑になりやすく、工数が増える危険性を伴うためです。（認証で事足りているなら認証だけで済ますことを推奨）

私たちは 「AWS Cognito の構築だけ」でも開発を承ることが可能です。

AWS Cognito に関する開発は、ぜひお問い合わせください。