Amazon Cognito

Web / モバイルアプリに認証 / 認可機能を追加する AWS マネージドサービス

AWS認証

Cognito とは

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

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

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

コンポーネント役割出力
ユーザープール認証 (サインアップ、ログイン)JWT (ID トークン, アクセストークン)
アイデンティティプール認可 (AWS リソースへのアクセス)一時的な AWS 認証情報

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 の違いを以下にまとめる。

観点Cognito自前実装Auth0
コストMAU 課金 (無料枠あり・プランは公式料金表を確認)開発コスト有料
管理負荷低い高い低い
カスタマイズ高い
AWS 統合標準で連携できる連携は自分で実装する連携は自分で実装する

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

つまずきやすい点

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

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

この記事は役に立ちましたか?

関連用語

関連する記事