CognitoとはAWSサービスの一つであり、主にモバイルアプリの認証システムとして利用されている。
Cognitoには主に3つの機能があり、それぞれ以下のように自分は解釈している
（ツッコミをいただくために後悔してるので、間違ってたら是非教えてください）
Cognitoのサービス達
Cognito UserPool
概要
emailの確認、SMSによる確認、パスワードの再発行などもやってくれるメールによる認証機能。
メリット
- ステップが複雑なメール認証機能を実装する手間がない
- ユーザーの認証ステップの保持、Email, Passwordの暗号化など、面倒なデータを保持せずに済む（AWS管理コンソールにおいて、ユーザーの権限などいじる必要はあるけど）
デメリット
- 既存のメール認証システムから移行する場合、name, email, phone numberなどはcsvでimportできるが、passwordだけはimportできないので、ユーザーにpasswordの再設定を依頼する必要がある。そのため、移行コストは高い
- データを自分たちで保持していないため、トラブルシューティングの工数が増す危険がある
Cognito IdentityPool
概要
メール、Google, Facebookなどで認証されたユーザーに対して、特定のAWSサービスへのアクセスを許可する（=認可）の機能。
未認証ユーザーも取り扱い可能で、未認証ユーザーは認証ユーザーと別のrole（権限）を与えることができる
メリット
- アクセストークンに関する実装をする必要がない
- サーバーレスアーキテクチャーに移行しやすい（もとからサーバーレスで組むつもりならほぼ必須要件）
デメリット
- API Gateway経由で、APIを公開する際に、Lambdaならuser情報を取得できるが、HTTPプロキシでELBやEC2を繋いだときは、ユーザー情報が取得できない（？）
- tokenの受け渡しだけで、未認証ユーザーの照会をすることができない？（idをパラメータに含めないといけない？）
Cognito Sync
概要
Cognito IdentityPoolに存在するユーザーのユーザー設定を保持・同期できるサービス。認証認可とは関係ない。
メリット
機種変時、マルチデバイス対応時に、設定項目を同期するのに便利。
デメリット
今の所見つかってはいないが、iOSでいうUserDefaultに入れるような情報の保持、復元など用途が限定的なので、使わなくていいアプリケーションもたくさんありそう
考察
UserPool
開発コスト
[使わない場合]
- 単純なemail認証であったとしても、rubyだとdeviseなど便利なgemがあるものの、センシティブなデータを扱うために確認工数なども膨れる可能性が高い
- SMS認証も必須だとすると、それをサポートしてるライブラリも少ないため開発工数は爆発的に膨らみそう
[使った場合]
- ライブラリの利用方法を覚える必要があるものの、Mobile Hubなどを利用することでそのコストを格段に下げることができる
- SMS周りは特にハマるらしい。http://qiita.com/aki/items/e35e1bea8c27cfab5e9e
- アクセストークンの検証も忘れがち。http://qiita.com/devalon/items/721ef4bdec80e1e6847c, http://qiita.com/ya-mada/items/154ea6e10f9f788bfdd5
運用コスト
[使わない場合]
- いつでもデータにアクセス可能なので、ユーザー固有の問題に対するトラブルシューティングが比較的容易
- 認証の度にDBへのアクセスが走るためシステムリソースが喰われる
- センシティブなデータにいつでもアクセス可能なため、ルール作りや社内でのアクセス制御が面倒
- UserPoolを使いたくなった時に、ユーザーにpasswordの再設定を依頼する必要がある
[使った場合]
- データを自分たちで保持していないため、トラブルシューティングに時間がかかることもありそう
- AWSのユーザー権限で、アクセス制御が可能なので、そこは簡単
- AWS Cognitoが落ちたら、機能の大半が使えなくなるというリスクを孕んでいる
- export機能はないので、AWS Cognitoから独自の認証機能に移行する場合は、APIを叩いてデータをexportした上で、ユーザーにpasswordの再設定を依頼する必要がある
所感
まだ認証システムを独自で持ってないなら、使うと大幅に開発コストが削減できそう
Cognito IdentityPool
開発コスト
[使わない場合]
- Facebook, Googleなどのuidに相当する情報を保持する必要がある
- クライアントに一時的なアクセストークンを発行する必要がある
- アクセストークンの検証機構を作る必要がある
[使った場合]
- uidの保持をしてくれる
- アクセストークンの発行、検証をawsがよしなにしてくれるが、ec2, elbでそれをやろうとすると、前段にAPI Gatewayをhttp proxyとして置く必要がある
- API Gateway + Lambda ならユーザーの照会までしてくれるが、ec2, elbだとそれができない？
- elb, ec2との相性はわるそうで、未認証ユーザーの照会ができない？
- 上記の理由で構成が複雑化する
運用コスト
[使わない場合]
- uidなどの情報へのアクセス制御をする必要がある
- アクセストークン発行に際して、システムリソースを食う
- 保守しないといけないコードが増える
- サーバーレスアーキテクチャにする際にIdentityPoolに乗り換えるか、STSへのリクエストを独自で頑張るかする必要がある。1ユーザーに認証情報を複数持てるようにしておけば、IdentityPoolのidentityIdをuidとして紐付けできるので、移行コストはそこまで高くないと思う（？）
[使った場合]
- 一部システムを移譲できるものの、構成が複雑になり、全員がクラウドネイティブな考えがない限り、運用が大変になりそう
- クラウドネイティブ的な構成になると、デバッグが大変そう（慣れてないだけ？）
所感
使うことによって、構成が限定されるため初期から使う必要はなさそう。
サービスが大きくなってきて、クラウドを存分に使いたくなったら検討したい
疑問
誰か、もし知ってたらおしえてください
- API Gateway経由で、APIを公開する際に、Lambdaならuser情報を取得できるが、HTTPプロキシでELBやEC2を繋いだときは、ユーザー情報が取得できないっぽいんですが、何か方法ないですかね？（API Gatewayにおいて、
Integration Type = AWS Serviceというのがあるけど、これでどうにかできないものか...）