Amazon Cognito

Cognito とは

Amazon Cognito は、Web / モバイルアプリに認証 / 認可機能を追加する AWS マネージドサービスである。ユーザープール (認証) とアイデンティティプール (認可) の 2 つのコンポーネントで構成される。

ユーザープール vs アイデンティティプール

ユーザープールとアイデンティティプールの違いを以下にまとめる。

SAM での定義

SAM での定義の例を示す。

UserPool:
  Type: AWS::Cognito::UserPool
  Properties:
    AutoVerifiedAttributes: [email]
    Policies:
      PasswordPolicy:
        MinimumLength: 8

UserPoolClient:
  Type: AWS::Cognito::UserPoolClient
  Properties:
    UserPoolId: !Ref UserPool
    ExplicitAuthFlows: [ALLOW_USER_SRP_AUTH, ALLOW_REFRESH_TOKEN_AUTH]

API Gateway との統合

API Gateway との 統合の例を示す。

MyApi:
  Type: AWS::Serverless::HttpApi
  Properties:
    Auth:
      DefaultAuthorizer: CognitoAuth
      Authorizers:
        CognitoAuth:
          JwtConfiguration:
            issuer: !Sub https://cognito-idp.${AWS::Region}.amazonaws.com/${UserPool}
            audience: [!Ref UserPoolClient]

Cognito vs 自前認証 vs Auth0

Cognito と自前認証 vs Auth0 の違いを以下にまとめる。

認証の自前実装はパスワードのハッシュ化、総当たり対策、トークン失効、多要素認証と守るべき項目が多く、セキュリティ事故の温床になりやすい。マネージドに寄せる判断は「作る楽しさ」より「破られたときの損害」で下すのが実務的だ。

つまずきやすい点

導入でつまずきやすいのは 3 点ある。第 1 に、標準のサインイン画面 (Hosted UI) は見た目のカスタマイズ幅が限られるため、デザイン要件が厳しい場合は自前フォーム + SDK の構成になる。第 2 に、ユーザープールは後からのリージョン移動や属性設計の変更に弱く、最初の設計 (サインインをメールにするかユーザー名にするか等) が長く残る。第 3 に、受け取った JWT はアプリ側で必ず署名検証が必要で、検証を省いた実装は認証を丸ごと無効化してしまう。検証には公式や実績あるライブラリを使うのが原則だ。

基礎から学ぶなら関連書籍が手がかりになる。