Amazon Cognito

Amazon Cognito は、Web やモバイルアプリケーションにユーザー認証とアクセス制御を提供するフルマネージドサービスです。サインアップ・サインインのフローやソーシャルログイン、企業 ID プロバイダーとの連携を自前で実装せずに導入できます。

解決する課題

アプリケーションに認証機能を自前で構築すると、パスワードの安全な保管、多要素認証、トークン発行と検証、ソーシャルログインや SAML 連携など、扱うべき要素が多く、セキュリティ上の責任も重くなります。Cognito はこれらをマネージドサービスとして提供し、開発者がビジネスロジックに集中できるようにします。

具体的には次のような課題を解決します。

• パスワードのハッシュ化や保管、リセットフローといった認証基盤の運用負荷を肩代わりする
• Google や Apple などのソーシャル ID、企業の SAML・OIDC IdP を一元的に束ねて扱える
• 標準準拠のトークンを発行し、API Gateway や ALB と組み合わせて認可を実現できる
• 認証済みユーザーに一時的な AWS 認証情報を払い出し、S3 や DynamoDB へ直接アクセスさせられる

主要概念と用語

• ユーザープール: ユーザーのディレクトリ。サインアップ・サインイン・パスワード管理を担い、認証成功時に JWT 形式のトークンを発行する。アプリにとっての「ID プロバイダー」として機能する。
• ID プール: フェデレーテッド ID とも呼ばれる。認証済み・未認証のユーザーに対し、IAM ロールに基づく一時的な AWS 認証情報を払い出す仕組み。
• アプリクライアント: ユーザープールに接続するアプリケーションの登録単位。許可するフローやトークンの有効期限、シークレットの有無などをここで設定する。
• フェデレーション: 外部の ID プロバイダーを信頼し、その認証結果を取り込む仕組み。ソーシャル IdP、SAML、OIDC に対応する。
• トークン: 認証成功時に発行される。ユーザー属性を含む ID トークン、API 認可に使うアクセストークン、再発行に使うリフレッシュトークンの3種類がある。
• Hosted UI: Cognito が提供するホスト型のサインイン画面。OAuth 2.0 のエンドポイントを備え、自前で画面を作らずに認証フローを実装できる。
• トリガーと Lambda: サインアップ前後やトークン生成前など、特定のタイミングで Lambda 関数を呼び出してフローをカスタマイズできる拡張点。
• 属性: ユーザーに紐づくデータ。標準属性とカスタム属性があり、必須・任意やミュータブルかどうかを定義できる。

仕様・制限・クォータ

• ユーザープールは標準の OAuth 2.0 認可コードフローやインプリシットフロー、クライアントクレデンシャルフローなどに対応する。
• 発行されるトークンには有効期限があり、ID トークンとアクセストークンは比較的短く、リフレッシュトークンはより長い期間を設定できる。具体的な範囲はアプリクライアント設定で調整する。
• 多要素認証として SMS と TOTP に対応し、必須・任意・無効を選べる。
• 多くのリソースにはアカウント単位やリージョン単位のクォータがあり、ユーザープール数やアプリクライアント数、API 呼び出しレートなどに上限がある。上限の一部は引き上げ申請が可能だが、固定のものもある。
• カスタム属性の数やサイズには上限があり、後から型や名前を変更できない点に注意する。

内部の仕組み

ユーザープールは ID プロバイダーとして振る舞い、認証が成功すると署名付きの JWT を発行します。アプリやバックエンドは、Cognito が公開する署名鍵（JWKS）を使ってトークンの署名と有効期限、発行者などを検証します。

ID プールは異なる役割を担います。ユーザープールや外部 IdP が発行したトークンを受け取り、それと引き換えに STS を介して一時的な AWS 認証情報を払い出します。このとき、認証済みユーザー用ロールと未認証ユーザー用ロールが割り当てられ、ロールマッピングによってユーザーの属性に応じたロールを選択することもできます。

つまり、ユーザープールが「誰であるか」を確立し、ID プールが「AWS リソースに対して何ができるか」を一時認証情報の形で与える、という分担になっています。両者は独立して使うことも、組み合わせて使うこともできます。

設計パターン / ベストプラクティス

• アプリの認証はユーザープールに任せ、AWS リソースへの直接アクセスが必要な場合のみ ID プールを併用する。
• バックエンド API では、受け取ったアクセストークンの署名・有効期限・発行者・対象クライアントを必ず検証する。検証を省略すると認可が成立しない。
• Hosted UI と OAuth 2.0 の認可コードフローを使い、クライアント側にトークンを露出しにくい構成を優先する。
• Lambda トリガーでサインアップ時のドメイン制限やカスタムクレームの付与などを実装し、業務要件に合わせる。
• 外部 IdP 連携を使う場合は、属性マッピングを明示的に定義し、必要な属性だけを取り込む。
• リフレッシュトークンの失効や、サインアウト時のグローバルサインアウトを適切に扱い、トークンの寿命を管理する。

運用・監視

• CloudTrail で管理操作やフェデレーション関連の API 呼び出しを記録し、監査に利用する。
• サインインやサインアップの成否、スロットリングなどのメトリクスを CloudWatch で確認し、異常な失敗率の増加を検知する。
• 高度なセキュリティ機能を有効にすると、漏洩した認証情報の検出やリスクベースの適応認証が利用でき、疑わしいサインインに対して追加の検証を要求できる。
• ユーザーのインポートやエクスポート、属性の一括更新は CLI や SDK を通じて運用する。大量操作はレート上限を意識する。

コスト

Cognito のユーザープールは、おおむね月間アクティブユーザー数に応じた従量課金が基本です。一定数までは無料枠が用意されている場合があり、SAML・OIDC によるフェデレーションや高度なセキュリティ機能は別の料金体系になることがあります。SMS による多要素認証や通知には、別途メッセージング側の費用が発生します。

ID プールが払い出す一時認証情報の発行自体に対する直接の追加料金は一般に小さく、コストはむしろアクセス先の AWS リソース利用料に依存します。正確な料金は変動するため、設計時には公式の料金ページで最新の体系を確認してください。

セキュリティ

• パスワードは Cognito 側で安全に管理され、ポリシー（長さや文字種、再利用制限など）を設定できる。
• 多要素認証を必須化することで、パスワード漏洩時のリスクを大きく下げられる。
• 高度なセキュリティ機能により、既知の漏洩パスワードの拒否やリスクスコアに基づく適応認証が可能になる。
• ID プールでは最小権限の IAM ロールを割り当て、認証済みと未認証で権限を明確に分ける。
• トークンの有効期限は短めに設定し、リフレッシュトークンの寿命と失効ポリシーを適切に管理する。

Well-Architected の観点

セキュリティの柱の観点では、Cognito は ID 管理とアクセス制御を AWS のマネージドサービスへ委譲することで、認証基盤の実装ミスや運用負荷を減らします。トークンによる認可、多要素認証、最小権限の IAM ロールマッピング、適応認証といった機能は、強固な ID 基盤と多層防御の実現に寄与します。CloudTrail との連携による監査性も、セキュリティの柱が重視する「トレーサビリティの確保」に沿っています。

試験で問われるポイント

関連サービス・比較

ユーザー認証という観点では、AWS IAM Identity Center（旧 AWS SSO）と混同されがちです。両者は対象とする利用者が異なります。

顧客向けアプリの認証には Cognito、社内ユーザーの AWS や業務アプリへのアクセス管理には IAM Identity Center、という使い分けが基本です。

ハンズオン / CLI例

CLI でユーザープールと、シークレットを持たないアプリクライアントを作成する例です。

# ユーザープールを作成し、プール ID を取得する
aws cognito-idp create-user-pool \
  --pool-name demo-user-pool \
  --auto-verified-attributes email \
  --query 'UserPool.Id' \
  --output text

# 取得したプール ID を使ってアプリクライアントを作成する
aws cognito-idp create-user-pool-client \
  --user-pool-id <USER_POOL_ID> \
  --client-name demo-app-client \
  --no-generate-secret \
  --explicit-auth-flows ALLOW_USER_SRP_AUTH ALLOW_REFRESH_TOKEN_AUTH