ユーザープールとIDプールの利用パターン
==

### ユーザープールのみ利用 その1
#### Webアプリのユーザー認証の実装を楽したいケース
- ユーザープールにユーザーを登録しておくだけ
- Webアプリ側で CoginitoのAPIを呼び出しトークンを利用する実装をする
- Webアプリ内でユーザーの識別に使うJWTトークンをCoginitoが発行してくれる
- WebアプリはAWSのサービスを利用しない（アクセスキーが発行されない）
- 自分で登録したユーザー以外に、 GoogleなどのIDプロバイダも利用可能
### ユーザープールのみ利用 その2
#### バックエンドにAWSのサービスを使っているパターン（トークンによる認証。ALB,APIGW,AppSync）
> PollyNotesはこのパターン
- ユーザープールにユーザーを登録し、ALBやAPIGWやAppSyncのような、インターネットからアクセスされるのが前提のサービスとCognitoユーザープールを連携させておく
- 認証に成功するとCognitoがトークンを発行
- WebアプリはトークンをALBやAPIGWに渡す
- ALBやAPIGWはトークンをCoginitoに渡し、認証の結果（許可・拒否）を得る
- 自分で登録したユーザー以外に、 GoogleなどのIDプロバイダも利用可能
### IDプールのみ利用 その1
- 一番歴史が古いのはこれ
#### 外部のIDプロバイダで認証し、AWSのAPIを呼び出したい場合
- Googleや FacebookなどのIDプロバイダとIDプールを連携
- IDプロバイダで認証された時のポリシーをIAMロールに設定し、プロバイダ設定と連携
- IDプロバイダで認証するようにWebアプリを実装
- IDプロバイダの認証成功で、プロバイダからトークンがWebアプリに渡る
- WebアプリはトークンをCognitoに渡し、問題がなければSTSが一時的なアクセスキーをWebアプリに発行
- Webアプリはアクセスキーを使ってAWSのSDKを呼び出し、DynamoDBやS3なのサービスを利用する
- 未認証のユーザーに限定的な認可を与えることもできる（お試しユーザーの場合はゲームのハイスコアは記録しないのでDybamoDBへの許可を与えない、など）
### IDプールのみ利用 その2
#### ユーザー認証をさせるほどではないがインターネットにAPIGWエンドポイントなどを晒したくない場合
- IDプールの「認証されていないユーザーへアクセス権限を与えるためのIAMロール」に必要なポリシーをアタッチ
- Cognito IDプールのAPIを呼び出し。認証できない場合の一時的なアクセスキーが返ってくる
- キーを使って AWSのSDKを利用
- いわゆるゲストアクセスにも使える
### ユーザープールとIDプールの併用
#### バックエンドにAWSの各サービスを使っているパターン（一時的なアクセスキーによるAPIの利用）
- IDプールのみ利用その1のケースで、IDプロバイダの代わりにユーザープールが使われる以外は、同じ
- ユーザー管理をユーザープールで行い、そのユーザーが認証された（あるいはされない場合）にIDプールのRoleで認可できる=STSによる一時アクセスキーが発行される
- AmplifyでWebアプリに認証機能を付けると、CloudFormation経由でこのセットアップが自動で行われる
> AmplifyはWebアプリケーションのバックエンドの自動作成やWebサイトのデプロイ自動化などSPA開発者がフロントエンド開発に集中できるサービス
- （ややこしいが）ユーザープールにはIDプロバイダも登録可能