##Amazon Cognitoとはそもそも何か
認証と認可のうちの認証をするやつです。
認証の部分だけです。
認可はIAMのroleでやります。
##認証を束ねられるのがCognito
FacebookやTwitterやGoogleやAmazonなどいろんな認証(Authentication Providersと呼ばれている)でログインしても、同一人物であれば一つのId(IdentityIdと呼ばれている）で管理できます。
FacebookやTwitterなどと並列に、自社で会員サイトをもっていれば、それも利用できます。
また、後述するUserPoolsも並列に利用できます。
ただ認証を束ねるのに使うのが目的ではないです。
##AWSリソースを自社サイト会員だけつかえるようにしたいというのが今回の目的
これはカスタム認証を利用して実現します。
注意：カスタム認証の際は認証フローがちょっと違います
qiitaだと実装にこの記事が参考になりました
##認可のグループ
・上記の認証がされたユーザーグループ
・上記の認証がされていないユーザーグループ
これら２つのグループに対してそれぞれ認可(role)を指定できます
例えば、
認証されていないユーザーにはS3のgeneralフォルダのリソースにのみアクセスできるroleを
認証されたユーザーにはそれに加えてpremiumフォルダのリソースにアクセスできるroleを
といった具合。
##混乱：User Poolsとは
Cognitoを勉強しようと思って何故かはじめにUserPoolsから勉強してしまったのが混乱の原因だった。
User PoolsはCognitoのAuthentication Providersの一つとして機能する(ただの)ユーザー管理機能。
アカウント登録やサインアップなどといったユーザー管理機能をマネージドに提供してくれるやつ。
参照
##UserPoolsに認可の機能はないのでAwsのリソースのアクセス権はわたせません
UserPoolsはもちろんAuthentication Providersの一つとしてではなく、単体で機能します。
が、認証の機能なのでAwsのリソースにアクセスさせようとするような認可の部分についてはこれのみではできません。
認証部分の実装はこちらが参考になります。
またこちらでコンソールでの設定について記載があります。
##混乱：UserPoolsの実装に認証は必要？
実装は他にもこのあたりやこのあたりを参考にしていた。
両方ともAWS.config.credentialsとAWSCognito.config.credentialsをセットしているが、理解ができない。
認証機能（ユーザーの登録・emailバリデーション・ログイン）だけであればAWSCognitoだけで完結するはずで、認証機能を利用するために認証が必要な仕組みの意味が理解できない。
実際AWSも使わずAWSCognito.config.credentialsも指定せずに実行してみて、問題なく動いた。
何かこちらの見落としがあるのか・・・？
##混乱：IAM単体でもFacebook認証で認可(role)を渡せる
これまた混乱するのですがIAMのRole自体にもFacebook/Google/Amazonに認証を依存できる
「IDプロバイダアクセス用のロール」というロールタイプがあります。
これよりもCognitoの方が高機能でTwitterなどもサポートしているので、こちらの機能は廃れる方向に進むのかな?
##参考になりそうな資料
http://dev.classmethod.jp/cloud/aws/cognito-identity-and-sts-web-identity-federation/