概要
Cogntioで出来ることをまとめる。
UserPool
認証
UserPoolを使って認証機能を提供することが可能。
認証された情報はIDトークンで渡されれる。
ユーザ名（username）は一度設定すると変更できないので注意が必要。
（例えばメールアドレスをusernameとして使用してしまうと、メアドが変わった時に変更できない）
※メールアドレスをサインインに使用したい場合は "ユーザ名以外でサインインを可能にする" 参照
TODO: アプリクライアントの設定での許可される認証方式について書く
ちなみに、SRPは `Secure Remote Password` の略
ユーザ名以外でサインインを可能にする
UserPool作成時の エンドユーザーをどのようにサインインさせますか? の ユーザ名 にて設定可能。
下記の3つの属性を指定可能（エイリアス属性になる）。
- email（検証済みのＥメールアドレス...
- phone_number（検証済みの電話番号...
- preferred_username（任意のユーザ名...
preferred_username でサインイン可能にする場合、ユーザ側で自由にサインインのIDを変更することが可能になる。
メールアドレス、電話番号は検証済みにする必要があるが、AdminUpdateUserAttributes を使って、 email_verified or phone_number_verified を true にすれば強制的に検証済み状態にすることが可能。
同じメールアドレスを複数ユーザで登録した場合、email_verified を true にできるのは１ユーザのみ。
（誰か１人を true にした場合、残りは自動的に false になる
メールアドレスを変更した場合、email_verified は 自動で false になる。
変更したメールアドレスへは、検証コードが自動で送信される。
検証コードを送らないようにする設定は存在しないようなので注意。
また、email_verified は UpdateUserAttributes で更新できないため（そもそも、アプリクライアントの書き込み可能に設定に項目がない）、Amplify等で、email を変更した場合、必ず検証コードのメールが飛ぶことになる。
ちなみにamazon（通販サイトの方）だと、メールアドレス（＝ログインＩＤ）を変えたい場合、登録済みのメールアドレスに一旦承認メールが飛んでくるので、それを承認する必要がある。
正直、、
email や phone_number を使ったサインインは色々めんどくさそうな事が起きそうなので非推奨。
preferred_username にメールアドレス入れれば良いんじゃないかな。。って思います。。
ちなみに、、
全般設定 > メッセージのカスタマイズ 内の 検証タイプ で コード と リンク が選択できるが、リンク の方が機能するのはサインアップした時だけで、それ以外ではココでの設定を無視して検証コードを送ってくるっぽい。
要確認事項メモ
- 検証コード＋VerifyUserAttributeでverifiedにできるか
属性
ユーザ毎に属性として値を持つことが出来る。
住所、名前等。
ただ、下記の理由により、実データはRDB等の別ストレージへ保存し、Cognito側にはカスタム属性でID値のみ保持する方式のが運用しやすいと思われる。
- 値のメンテナンスのし難い
- コンソール上から直接値を設定、変更出来ない（APIを直接たたく必要がある）
- 検索（RDBでのwhere句）が出来ない（API直でも出来ない）
- リレーショナルなデータ管理の仕方が出来ない
標準属性
標準の属性値として設定可能な項目はOpenID Conect準拠。
属性は必須属性を指定できる。
必須となった属性はユーザからサインアップする場合は必須であるが、管理者（AdminCreateUser）としてサインアップする場合は無くても登録可能。
※元ネタ：公式 の注記部分
カスタム属性
カスタム属性を最大25個まで設定可能。
属性名は、custom:xxxxxx の形式になる。
※細かい条件は 公式 参照
属性の注意事項
読み込み
- 属性の必須、非必須はUserPool作成後は変更できないので注意
- アプリクライアントの設定で読み取り可能にしている属性は、IDトークンの情報に含まれるため注意
※jwt.io等でパースすると丸見え（ただ、IDトークンを他人に盗み見されてる時点で大分やばい） - 逆に言うと、IDトークンに含まれていないといけない情報は読み取り可能にする必要がある
書き込み
- アプリクライアント設定で書き込み可能にしている属性は、
アクセストークン＋UpdateUserAttributesで直接書換可能であることに注意
※つまり、何かしらのID値を保持していて、書き込み可能になってる場合、自由に変更可能 - 細かなバリデートは出来ない（例えば、
birthdateをhoge/12/31にすることが出来る
※バリデートが必要な場合、直接ではなく自前のAPIを経由させる等対策が必要
（Amplifyを使う場合、画面側できっちりバリデートする - 更新に対応したアクションの実行はできないので、その辺やりたい場合、自前APIが必要
※更新値がＡの場合、～～する、Ｂが更新されたらメールを飛ばす等
自前のAPIを用意して叩かせる方式をとる方が潰しが効きやすいのは間違いない。
スモールスタートでよい場合とかはAmplifyから直接CognitoのAPIコールで良いかも。
※要件の変化に合わせて都度、自前APIを用意する