はじめに
初めまして、テクロスでAWSを勉強中の学生アルバイトです。
今回はCognitoとその他AWSサービスを用いたアプリ開発の流れみたいなものをようやく理解したので整理して置いておきます。
Cognitoとは
認可、認証を司るAWSサービスです。
認証を担当するのがUser Pool、認可を担当するのがIdentity Poolです。
AWS Cognitoの公式ドキュメント
（最初公式ドキュメント見たときは「なんだこの分かりにくいドキュメントは！」とか思ってたけどある程度理解してから読むと「詳しくて助かる」ってなる。公式ドキュメントってそんなもんか）
認証とは
多分一番わかりやすいのがE-mailアドレスとpasswordでユーザー確認をするものですね。
UserPoolを使いこなすことで、さらにFacebook等のアカウントを使ってユーザー確認することができます。
認可とは
AWSの他のサービス(例えばDynamoDB等)にアクセスすることを許可すること。
ユーザー認証が完了したユーザーに許可証のようなものを配布するというイメージで理解しました。
すなわち
バックエンドを全てAWSで構築するアプリケーションの場合、UserPoolでユーザー認証をし、認証が完了したユーザーにIdentityPoolで認可して、DB等にアクセスするみたいなことができます。
「認証は自前で作ってIdentityPoolだけを使う」とか、「認証だけしたいからUserPoolだけ使う」とかもできます。
しかしAPI gatewayはUserPoolのトークンを用いて呼び出すことができるのでIdentityPoolは不要だったりもします。
この辺がややこしくて少し詰まりました、、
さて、それぞれのpoolについて具体的に見ていきます。
UserPool
サインアップ(ユーザー登録)やサインインの具体的なコードはググればたくさん出てくるので自分の環境に合わせて調べてもらえばいいのですが、
結局何をしてるかというと、
- 自分の作成したUserPoolのIDやRegionを指定
- 入力されたメールアドレス等の情報を元にユーザー登録、認証
- 認証が成功すれば3つのトークンを返す
この流れですね。
返ってくるトークンはIDトークン、アクセストークン、更新トークンです。
「IDトークン」は認可の際に使用します。
「アクセストークン」はユーザー属性を変更等するときに使用します。
上記2トークンは一時間で切れてしまうので、「更新トークン」を用いてそれらが切れる前にトークンを作り直すことができます。
IdentityPool(Federated Identity)
認可を担当します。
ユーザープール(あるいは自作機構)を用いてユーザー認証を行なった場合、ユーザーは認証されたユーザーと認証されていないユーザーの二つに分けられます(例えばユーザー登録したプレイヤーとゲストプレイヤー)。
IdentityPoolを用いることで、この二つのユーザー群それぞれに対してAWSサービスへのアクセス権を与えることができます。
具体的には、あらかじめ認証ユーザー用と非認証ユーザー用のIAMロールを作っておき、認証情報に応じてそれらを割り当てるようなイメージです。
そのアクセス権に応じて柔軟にサービスの利用を制限することができるようになります。
アプリケーションの流れ
公式ドキュメントにはこんな感じの図があるんですが、最初時系列がよく分からなくて意味不明でした。
この図は、
- アプリを起動したらまずUserPoolで認証し、結果としてトークンを得る
- そのトークンをIdentityPoolに渡して、credentialsという許可証のようなものを得る
- credentialsを持つユーザーにだけ他のAWSサービスにアクセスを許可する
という流れを表しています。
1と2はログイン画面で、3からアプリのメイン画面というイメージで理解しました。
認可した先でAPI gatewayを使う場合
API gatewayのAPIを叩く場合、API gatewayのオーソライザーという仕組みを使えば、UserPoolで認証済みのユーザーはAPIを叩けるようになります。なのでIdentityPoolでの認可は省くことができます。
（APIの先のサービスに対して認可しなくてもいいのかはよく分かりません）
おしまい
認可認証あたりについてはすぐ理解できたのですが、プール同士の関係やサービス利用の部分がよく分からなかったので手こずってしまいました、、
認証の部分はいろんな人が分かりやすい記事を作ってくれているのでそれを見ればいいとして、認証後はAWS SDKの開発者ガイドのサンプルコードとにらめっこすればなんとかなりそうです！