Cognitoについて存在は知っていましたが実際に使ったことも詳しく勉強したこともなかったので調べたり試してみました。
実装方法などに関しては後日時間があれば別記事にでも残すかもしれません。
Cognitoとは
一言でいうと認証専門のサーバーレスサービスと言えるでしょう。
一般的なIDとパスワードの認証方法から多要素認証(MFA)、外部プロバイダー連携(Googleアカウントでのサインイン)など、現代のWebアプリケーションに求められる幅広い認証方法をサポートしています。
Cognitoのメリット
調べた限りで私が感じたCognitoを使うメリットは大きく下記の３つです。
-
実装の容易性
認証・認可まわりの複雑な操作を一通りCognitoに丸投げすることができます。サインアップ、サインイン、パスワードリセットなどの基本機能はもちろん、API Gateway等の他サービスと連携したアクセス制限の構築も簡易的に実装することができます。
-
性能（スケーリング）を気にする必要がない
完全なサーバーレスサービスであるため、ありがたいことにユーザー数の増減に応じたスケーリングはすべてAWSが自動で行ってくれます。登録者が100人であれ10万人であれ、インフラのパフォーマンスやプロビジョニングを気にする必要がありません。
-
セキュリティリスクの転移
認証機能を自前で実装・運用する際のリスクとして常に付きまとうのが個人情報やパスワードの漏洩リスクになります。
しかし、Cognitoを利用すれば認証情報の管理責任や暗号化の担保をAWS側へ転移することができます。
また、最新のセキュリティ標準への追従もAWSが担うため、認証方式の危殆化をエンジニアが常時監視するコストも削減できます。
Cognitoのデメリット
フルマネージドで強力な反面、ログイン画面の細かなデザインカスタマイズや、特殊な認証ロジックの埋め込みなど、独自のカスタマイズを行いたい場合には柔軟性が低く、制約を感じる場合があるようです。
もし独自の認証方法などを考えている場合はCognitoでの運用は控えた方がいいかもしれないですね。
実際に使ってみた感想
私が今回試したことは大きく2つです。
1.サインアップ、サインイン
2.認証を利用したAPIの接続確認。
- サインアップ、サインインについて
まず第一にサインアップとサインインの機能はすごく簡単に実装することができました。
構成もすごくシンプルで認証部分は、ブラウザとCognitoだけで実装することができました。
Cognitoでユーザープールを作成して、アプリケーションクライアントを作成すればそれだけでほとんど完成です。ブラウザから直接CognitoにアプリケーションクライアントのクライアントIDを指定してリクエストを送ればユーザーを登録したり、IDトークンを発行させて認証を取得することができました。
やはり認証アルゴリズムやDBの用意など一切なくできるのでだいぶ楽に実装できましたね
- 認証を利用したAPIの接続確認について
今回はCloudFrontとAPI Gateway、Lambdaを使ってAPIの接続確認を行いました。
この構成の場合、認証を行うのはAPI Gatewayになります。
API GatewayにCognitoのアプリケーションクライアントを連携することでアプリケーションクライアントが発行した公開鍵を使ってIDトークンの認証を行ってくれます。
（※あくまでも使用されたIDトークンが連携しているアプリケーションクライアントが有効期限内に発行したものかを認証しているだけということを認識している必要があります。API Gatewayで毎回そのユーザー情報やIDトークンをCognitoに確認に行っているわけではありません。）
API Gatewayで認証回りをパスできるので後ろのLambdaなどの処理であまり気にせず実装できる点も非常に助かる機能だと思います。
まとめ
Cognito認証はやはり圧倒的に手軽に実装できて、サーバーレスのwebアプリケーションの構成を作る場合確実に有用な選択だと思います。
今回は手動確認から、最終的に「メール確認コードによる自動認証」まで実装を拡張することができ、一連のログインフローを自力で完結させることができました。
今回はシンプルなID・パスワード認証とAPI GatewayのJWT検証のみを試しましたが、今後は「MFA（多要素認証）の強制化」や「Lambdaトリガーを使った DynamoDB へのユーザーデータ自動初期化（Post Confirmationトリガー）」、さらには「GoogleやGitHubアカウントを使ったソーシャルログインの統合」など、まだまだできることはあるので試してみてください。