Amazon Cognitoの認証とAWSリソース認可

Amazon Cognitoは、Webアプリケーションやモバイルアプリケーションにユーザー認証・管理の機能を提供します。Cognitoを理解するときの中心は、ユーザープールとIDプールが別の役割を持つことです。ユーザープールはアプリ利用者の本人確認とアプリ向けトークンの発行を担い、IDプールは外部IDをAWSの一時認証情報に交換し、IAMロールを通じてAWSリソースへのアクセスを認可します。

「ログインできた」ことと「S3やDynamoDBを操作できる」ことは同じではありません。どの主体が認証され、どの種類のトークン／認証情報を持ち、その認証情報にどの権限が設定されているかを順番に確認する必要があります。

CognitoはAWSが運用するマネージドサービスであり、アプリケーション開発者がユーザーディレクトリや認証サーバーの基盤を自前で構築・運用する負担を減らします。サービスはサーバーレス型で、ユーザー数や認証要求の変化に応じた拡張を支援し、大規模なユーザーベースを持つアプリケーションにも利用できます。ただし、アプリケーション側のトークン検証、IAM権限の設計、ユーザー単位のデータ分離、料金・クォータ確認まで不要になるわけではありません。

認証と認可を区別する

**認証（authentication）**は、リクエストを行っている利用者やシステムが誰であるかを確かめることです。本人性を確認する材料には、次のような要素があります。

要素	確認するもの	例
知識情報	本人が知っているもの	パスワード、PIN、秘密の質問への回答
所持情報	本人が持っているもの	登録済みスマートフォン、セキュリティキー、ワンタイムコード生成器
生体情報	本人の身体的特徴など	指紋、顔、声

異なる要素を複数組み合わせる多要素認証（MFA）は、パスワードだけに依存する場合と比べて、盗まれたパスワードだけでログインされるリスクを下げます。同じ種類の情報を二つ使うことは、通常、二要素を組み合わせたMFAとは見なしません。

一方、**認可（authorization）**は、認証された主体にどの操作を許すかを判断することです。対象リソース、実行アクション、条件を合わせて評価します。たとえば、本人確認済みの利用者であっても、自分のアカウントに属する注文だけを読み取れるようにすることがあります。認可条件には、ユーザー属性やグループ、IAMロール、対象リソース、送信元ネットワークなどが使われます。

通常の処理ではまず認証して主体を特定し、その後に認可します。ただし、認証が成功しただけで、あらゆるAPI操作やAWSリソースアクセスが許可されるわけではありません。アプリケーション内のデータアクセス制御とAWS IAMの評価も、それぞれ適切に実装します。

Cognitoを構成する二つの仕組み

ユーザープール：アプリ利用者の認証とトークン

Amazon Cognitoユーザープールは、ユーザー名・パスワードなどを管理するユーザーディレクトリであり、アプリケーションから見たOpenID Connect（OIDC）IDプロバイダー（IdP）として動作します。ユーザーの登録・サインインを受け付け、認証結果を表すJSON Web Token（JWT）を発行します。

ユーザープールが提供する代表的な機能は次のとおりです。

• ユーザーのサインアップ、サインイン、管理者によるユーザー作成やユーザー管理
• パスワードの変更・再設定、確認コードによるメールアドレスや電話番号の検証
• MFAを含む認証フローと、アプリケーションクライアントごとの認証設定
• ソーシャルIdP、SAML 2.0 IdP、OIDC IdPとの連携、および属性マッピング
• OAuth 2.0スコープやユーザー属性を含むJWTの発行
• Lambdaトリガーによる認証・登録フローの拡張

ユーザープール単独で、アプリケーション独自のAPIやAWSリソースに対するすべての認可が自動的に完了するわけではありません。アプリやAPIは受け取ったJWTの署名・発行者・有効期間・用途などを検証し、対象操作への許可を判断します。API GatewayなどのJWT対応機能でトークンを検証する構成もあります。

IDプール：AWS一時認証情報とIAMによる認可

**Amazon Cognito IDプール（Identity Pool）**は、アプリ利用者のIDをAWS認証情報に交換し、AWSサービスへの署名付きリクエストを行えるようにする仕組みです。ユーザープールのJWTに限らず、ソーシャルプロバイダーのトークン、SAMLアサーション、OIDCトークンなどをIDプロバイダーとして受け入れられます。また、要件に応じて未認証のゲストアクセスを構成できます。

IDプールはAWS Security Token Service（STS）とIAMロールを利用し、期限付きのAWS認証情報を返します。認証済みユーザーとゲストで異なるIAMロールを割り当てたり、ユーザーの属性・グループなどに基づいてロールを選択したりできます。実際に操作できる範囲は割り当てたロールのポリシーなどで決まり、IDプールを使っただけでリソースへの権限が自動的に広く付くわけではありません。

Cognitoの機能	主な問い	発行・管理するもの	主な用途
ユーザープール	アプリ利用者の本人確認はできたか	アプリ向けJWT（ID・アクセストークンなど）	アプリへのサインイン、APIのユーザー認証・認可
IDプール	どのIAMロールの権限でAWSへアクセスさせるか	IAMロールに基づく一時AWS認証情報	アプリからS3・DynamoDBなどを直接呼び出す

ユーザープールは認証側、IDプールはAWSリソースアクセスの認可側と整理すると理解しやすくなります。ただしIDプールは認証済みのIDだけでなくゲストIDにも対応し、外部プロバイダーのIDを受け取ることができます。アプリにログインさせるだけでAWS認証情報が不要なら、IDプールを追加する必要はありません。

外部IdPを使うフェデレーションの基本

IDフェデレーションは、利用者が既に持つ別のIDを信頼し、その認証結果を別のアプリケーションやサービスで利用できるようにする仕組みです。利用者は外部のIdPで認証し、アプリケーション側（サービスプロバイダー、SP）は受け取った認証情報を検証してサービス利用を認めます。

一般的なブラウザーベースのフェデレーションでは、次のように進みます。

1. クライアントがサービスプロバイダーのアプリケーションにアクセスする。
2. アプリケーションがユーザーをIdPの認証画面へ誘導する。
3. ユーザーがIdPに認証情報を提示する。要件に応じてMFAなどの追加確認を行う。
4. IdPが認証に成功すると、ユーザーの識別情報や属性・認証結果を含む応答を発行する。
5. クライアントがその応答をSPへ届け、SPが署名・発行者・宛先・有効期間などを検証する。
6. 検証結果とアプリ側のアクセス制御に基づき、アプリケーションが利用を許可する。

Cognitoのユーザープールを使う場合、アプリはユーザープールで直接認証することも、ソーシャルIdPや企業IdPへ認証を委任することもできます。Facebook、Google、Login with Amazon、AppleなどのソーシャルIdPや、SAML／OIDC IdPから受け取る情報をユーザープールの属性にマッピングし、ユーザープールがアプリ向けトークンを発行する構成があります。外部IdPで認証した事実と、AWS上でどのIAMロールを使えるかは別の判定です。AWSサービスにアクセスさせるには、IDプールなどの仕組みとIAM権限を別途構成します。

ユーザープール認証とJWT

サインインからアプリ/API利用まで

ユーザープールでアプリ利用者を認証する標準的な流れは、次のとおりです。

1. クライアントがユーザープールへサインアップまたはサインインを要求する。
2. CognitoがパスワードやMFAなどの認証チャレンジを処理する。外部IdP連携を構成している場合は、そのIdPで認証する。
3. 認証に成功すると、Cognitoがトークンを発行する。
4. クライアントは用途に応じたトークンをアプリケーションやAPIに提示する。
5. アプリ/APIは署名、有効期限、発行者、トークンの用途や必要なクレームを検証し、要求された操作を認可する。

ユーザープールが発行する主なJWTは次の3種類です。

トークン	主な役割	扱い方
IDトークン	認証されたユーザーの識別情報や属性をクライアントへ伝える。OpenID ConnectのID情報に用いる	ユーザーの識別情報を必要とするクライアントやサービスで使う。アクセストークンの代わりにAPI認可へ流用しない
アクセストークン	APIやユーザープールのユーザー操作を認可する。スコープやグループなどのクレームを含み得る	APIはアクセストークンの署名と用途を検証し、スコープ・クレームを認可に利用する
リフレッシュトークン	再度ユーザー名・パスワードを入力させずに、新しいIDトークンやアクセストークンを取得する	認証情報に準じて保護する。ユーザー属性をAPIに提示するためのトークンではない

JavaScript向けAWS SDKやCognito対応ライブラリでは、認証成功時のコールバックやPromiseの成功経路でトークンを受け取り、認証失敗時のエラー経路で失敗を処理します。受け取ったアクセストークンをAPIクライアントへ渡す実装はアプリ側で行います。ログイン処理を一度呼び出せばSDKがどのHTTP要求にも自動でアクセストークンを付ける、という意味ではありません。ライブラリがセッションを管理する場合も、どのAPIにどのトークンを付けるかを設定・確認します。APIへは通常HTTPSを使い、Bearerトークンを認可ヘッダーなどで送ります。トークンの保存場所、更新、ログへの出力防止、ログアウト時の破棄も設計します。

JWTは署名付きのトークンであり、内容を暗号化して秘密にするものとは限りません。クレームを読むだけで信用せず、API側で署名と期待する発行者、トークン種別、対象クライアント／対象API、有効期限などを検証します。IDトークンとアクセストークンは別の目的を持ち、それぞれ独立に検証します。クライアントが書き換えたユーザーIDなどを、検証なしで認可の根拠にしてはいけません。

ユーザープールの作成とクライアント設定

ユーザープールはAWS Management Console、AWS CLI、SDK、またはIaCから作成・設定できます。開発時に確認する設定項目には、サインインに使うユーザー属性、パスワードポリシー、MFA、メール／SMS検証、ユーザープールのアプリケーションクライアント、認証フロー、外部IdP、コールバックURLなどがあります。作成時に発行されるユーザープールIDとアプリクライアントIDはアプリの設定値として扱い、SDKの初期化や認証要求に渡します。一般にユーザープールIDは認証先を特定し、アプリクライアントIDはどのアプリ設定を使うかを識別します。

作成後はユーザープールIDとアプリケーションクライアントIDをアプリの設定に反映し、AWS SDKのCognito Identity Providerクライアントや対応する認証ライブラリから利用します。リージョン、エンドポイント、アプリクライアントの設定も一致させます。ブラウザーやモバイルアプリにクライアントシークレットを埋め込む設計は避けてください。クライアント内の値は利用者から抽出できるため、公開クライアントとして扱い、認可コードフローとPKCEなど、クライアントの性質に合ったフローを選びます。

ユーザープールが提供するホスト型のログイン画面（Managed login）を利用する方式と、SDK/APIを使って独自画面から認証する方式があります。どちらでも、アプリ側は認証結果とトークンを用途に応じて取り扱い、API側のトークン検証を省略しません。サインアップを一般公開する場合は、意図しない利用者が誰でも登録できる設定になっていないかを確認します。

IDプールでAWSリソースへアクセスする

認証トークンからAWS一時認証情報へ

ユーザープールのトークンはアプリ利用者の認証結果であり、それ自体がAWS SigV4署名に使うアクセスキーではありません。クライアントからS3やDynamoDBなどのAWS APIを直接呼び出す場合は、IDプールを利用してIAMロールに対応する一時AWS認証情報を取得する構成にできます。

1. クライアントがユーザープール、ソーシャルIdP、SAML/OIDC IdPなどで認証する。ゲストアクセスを構成している場合は未認証IDから始めることもできる。
2. クライアントが認証結果をIDプールへ渡し、AWS認証情報を要求する。
3. IDプールがIDプロバイダーと認証状態を確認し、設定されたロール選択ルールに基づいてIAMロールを決定する。
4. STSがそのロールのセッション用の一時認証情報を発行し、IDプールがクライアントへ返す。
5. クライアントは認証情報を使ってAWS SDK経由で要求に署名し、許可されたAWS APIを呼び出す。
6. 認証情報は有効期限付きであり、必要に応じて再取得する。認証情報をアプリに固定した長期アクセスキーとして埋め込まない。

このフローで重要なのは、IDプールが権限の境界を無視して任意のAWSアクセスを許可するのではないことです。認証済み・未認証ロールの信頼関係と権限ポリシーをIAMで設定し、必要な操作とリソースだけを許可します。利用者ごとに異なるデータへアクセスさせるなら、IAM条件キー、セッションタグ、ロール選択、リソース側ポリシーなどを組み合わせ、データ分離を検証します。ゲストアクセスを有効にすると、ログインしていない利用者にも認証情報が発行されるため、権限を特に狭く設計します。

ユーザープールとIDプールの併用

ユーザー認証にユーザープールを、AWSサービスアクセスにIDプールを使う構成はよく利用されます。ユーザープールがユーザーを認証して発行したトークンを、クライアントがIDプールに提示し、IDプールからAWS一時認証情報を受け取ります。たとえば、アプリのAPIにはアクセストークンを提示し、クライアントからの特定オブジェクト取得にはIDプールで得たAWS認証情報を使う、というようにアクセス先と認証方式を分けられます。

ただし、ブラウザーやモバイルクライアントへAWS認証情報を渡す構成が常に最適とは限りません。アプリケーションサーバー経由でデータへアクセスさせる設計も選べます。クライアントから直接AWS APIを呼び出すメリットと、IAMポリシー・ユーザー単位のデータ分離・認証情報管理の複雑さを比較してください。

IDプール作成時の設定とアクセス許可

IDプールを作成したら、次の設定と動作を確認します。

1. 認証プロバイダーを設定する：ユーザープールを使う場合はユーザープールIDとアプリクライアントIDを指定する。ソーシャル、SAML、OIDCなどの外部プロバイダーも、要件に応じて登録する。
2. 認証済み／未認証の利用可否を決める：ゲストアクセスを有効にするかを判断する。ゲストを有効にする場合は未認証ロールの権限を限定する。
3. IAMロールを関連付ける：信頼ポリシーがCognito IDプールからの引き受けを許し、権限ポリシーが必要なAWS操作だけを許すようにする。認証済み利用者に共通ロールを使うか、属性に応じてロールを選ぶかも決める。
4. プロバイダー名と認証結果を正しく扱う：クライアントのログイン情報に、設定したプロバイダーを識別する名前とそのプロバイダーから得た有効なトークン／アサーションを指定する。
5. IDプールIDをアプリに設定する：SDKにリージョン・IDプールID・プロバイダー情報を渡し、認証情報を取得する。
6. 権限を実環境で検証する：意図したロールが選択されること、ロールの権限外の操作が拒否されること、ユーザー間のデータが分離されることをテストする。

サードパーティのIDプロバイダーを利用する場合も、外部IdPで認証されたという事実だけでAWS操作が許可されるわけではありません。IDプール側のプロバイダー設定、ロール選択、IAMの信頼ポリシー、実際の権限ポリシーを一組として確認します。

Lambdaトリガーによる認証フローの拡張

ユーザープールは、サインアップや認証などの処理段階でAWS Lambda関数を呼び出すトリガーを提供します。Cognitoはイベント情報を関数へ渡し、トリガーの種類に応じて、関数が変更した応答を処理フローに反映します。外部ディレクトリとの照合、入力条件の検証、メッセージ変更、トークンへのクレーム追加、イベント記録などを実装できます。

たとえば、イベント会員アプリでサインアップ時に招待コードを検査する、認証後に監査用イベントをCloudWatch Logsへ記録する、既存の社内ディレクトリを調べてユーザーを移行する、といった用途があります。Lambdaはトリガーごとの入力・出力契約やタイムアウト・エラーの振る舞いに従わせる必要があります。関数が失敗したとき認証処理を続けるのか拒否するのかはトリガーとフローの仕様を確認し、障害時の影響を設計してください。Lambda実行ロールには、関数が本当に必要とするログ出力や外部サービス呼び出しの権限だけを付与します。

主なトリガーの例です。

トリガーの段階	使い方の例
サインアップ前	入力値や招待条件の検証、登録要求の許可・拒否
サインアップ確認後	ウェルカム処理、監査・分析イベントの記録
認証前／認証後	独自条件による認証要求の検証、成功イベントの記録
カスタム認証チャレンジ	独自チャレンジの作成、回答の検証、次の段階の決定
ユーザーマイグレーション	既存のディレクトリから利用者を検索・移行
トークン生成前	設定に応じてJWTのクレームやスコープを追加・抑制
カスタムメッセージ	検証コード、パスワード再設定などの通知内容を変更

Lambdaトリガーは標準フローを拡張する手段であり、Cognitoの全トリガーが同じタイミングで動くわけではありません。必要なイベント種別とトリガー契約を選び、トークンのクレームを追加する場合は、その情報を信頼してよいか、個人情報や権限情報を過剰に含めていないかを確認します。

パスワード、MFA、アカウント保護

ユーザープールでは、利用者の認証強度やアカウント回復方法に関する機能も構成できます。

• パスワードポリシー：長さや複雑さなどを設定し、弱いパスワードを避ける。
• MFA：SMS、認証アプリなどを追加要素として使う。利用者に必須とするか、状況に応じて要求するかなどの方針を決める。
• パスワード再設定：利用者がパスワードを忘れたときに、登録済みの連絡先などを利用する回復フローを提供する。
• 連絡先属性の検証：メールアドレスや電話番号に確認コードを送信し、利用者がその連絡先を利用できることを確認する。
• リスクベースの保護：脅威保護の設定に応じて、サインインに伴うリスクを評価し、疑わしい要求に追加認証を要求したり、サインインをブロックしたり、監視目的で記録したりできる。設定によっては通知を送ることもできる。
• 漏えいパスワード・不正アクセス対策：脅威保護は漏えいした認証情報や一般的に推測されやすいパスワードの検出、適応認証によるリスク評価などを提供する。AWSの現行ドキュメントでは脅威保護はユーザープールのPlus機能プランで提供されるため、利用するプラン、認証方式、リージョン、機能制限を確認する。

セキュリティを強化するときも、利用者がアカウントを回復できること、検証コードの送信先が適切であること、MFA要素を紛失したときの手順があることを合わせて設計します。MFAを追加しても、API側の認可やJWT検証を省略できるわけではありません。

SAML 2.0とシングルサインオン

SAML（Security Assertion Markup Language）2.0は、ドメインをまたいで認証・属性情報を交換するXMLベースのオープン標準です。企業が社内のIdPで社員を認証し、その認証結果で別のサービスへログインさせるシングルサインオン（SSO）で広く使われます。

SAMLの用語は役割を分けて理解します。

要素	役割
アサーション（assertion）	IdPが発行するXML文書。利用者の認証結果、属性、対象サービスなどの主張を含む
プロトコル（protocol）	認証要求や応答などのSAMLメッセージ交換手順を定義する
バインディング（binding）	SAMLメッセージをHTTPなどの通信経路でどのように転送するかを定義する

アサーションは「どんな認証・属性情報を伝えるか」、プロトコルは「要求と応答をどうやりとりするか」、バインディングは「メッセージをどの方法で運ぶか」を表します。これらは同じものではありません。SAMLのメッセージを受け取る側は、署名、発行者、宛先、対象、時刻条件などを検証し、信頼できるIdPからの有効な応答であることを確認します。

一般的なSP起点のSSOは次の流れです。

1. 利用者がSP（サービスプロバイダー）のアプリケーションを開く。
2. SPが利用者を企業IdPへリダイレクトし、認証を要求する。
3. IdPが社員ディレクトリとパスワード・MFAなどに基づいて利用者を認証する。
4. IdPがSAMLアサーションを含む応答を生成し、ブラウザー経由でSPへ返す。
5. SPがアサーションと応答を検証し、ユーザー属性をアプリ内のIDへ対応付ける。
6. SPがアプリケーションのセッションを開始し、割り当てた権限でサービス利用を許可する。

たとえば、企業ディレクトリと連携したIdPで社員が認証され、SAML連携を設定したAWS環境へSSOする構成があります。AWS Management Consoleへのフェデレーションでは、SAML IdPの認証結果を使ってIAMロールを選択し、AWSへのアクセスを得ます。アプリケーションのSPとしてのCognitoユーザープールにSAML IdPを接続する方式と、IAMでSAMLフェデレーションを構成してAWS Management Consoleへログインする方式は、目的・設定箇所が異なるため区別してください。

設計・障害調査で確認する順序

Cognitoを含む認証・認可でアクセス拒否が起きた場合は、次の順に分解すると原因を追いやすくなります。

1. 誰が認証されたか：ユーザープールのローカルユーザーか、ソーシャル／SAML／OIDC IdPか、ゲストかを確認する。
2. どのコンポーネントを使ったか：アプリ認証ならユーザープール、AWS認証情報が必要ならIDプールを構成しているかを確認する。
3. 何を送ったか：API向けアクセストークン、ユーザー属性を表すIDトークン、IDプールへ渡すプロバイダー認証情報、AWS一時認証情報のどれかを特定する。
4. トークン／認証情報が有効か：署名・発行者・用途・期限・クライアント設定・プロバイダー設定を検証する。
5. どのロールが選ばれたか：認証済み・未認証ロールやロール選択ルール、IAM信頼ポリシーを確認する。
6. 操作が許可されるか：ロールのIAMポリシー、リソースポリシー、条件キー、明示的Denyなどを確認する。
7. ユーザー間のデータ分離ができているか：トークンのクレームを認可に用いる場合、検証済みの値であることと、データ所有者との対応が崩れていないことを確かめる。
8. カスタム処理で止まっていないか：Lambdaトリガーのログ、タイムアウト、エラー応答、外部依存を調べる。

DVA試験で押さえるポイント

• 認証は「誰か」、認可は「何をしてよいか」を決める。ログインに成功したことだけでは、アプリのすべてのデータやAWSサービスへのアクセスは認められない。
• Cognitoユーザープールはユーザーディレクトリ／OIDC IdPとしてアプリユーザーを認証し、JWTを発行する。
• IDプールはユーザープールや外部IdPなどからのIDをAWSの一時認証情報に交換し、IAMロールによるAWSリソースアクセスを可能にする。
• IDトークンはユーザー情報、アクセストークンはAPIやスコープに基づく認可、リフレッシュトークンは新しいトークンの取得を担う。
• CognitoのJWTはAWSアクセスキーではない。S3やDynamoDBへ署名付きのAWS API要求を直接送るには、IDプールなどからAWS認証情報を取得する構成が必要。
• IDプールから認証情報を得ても、それがすべてのAWS操作を許可するわけではない。IAMロールの信頼ポリシーと権限ポリシーを最小権限で設定する。
• Lambdaトリガーは登録・認証・トークン生成などの段階をカスタマイズできるが、トリガーごとの契約とエラー時の挙動を考慮する。
• MFA、パスワード回復、連絡先検証、脅威保護を利用できる。高度な脅威検知などは利用可能なプラン・設定を確認する。
• SAMLアサーションは認証・属性情報を含む文書、プロトコルは交換手順、バインディングは転送方法を定義する。
• SAMLで認証された利用者がいることと、AWS IAMロールによる認可は別の段階である。信頼するIdP、選択可能なロール、ロールの権限をそれぞれ設定する。

AWS公式ドキュメント

• Amazon Cognitoユーザープール
• ユーザープール認証の概要
• Amazon CognitoユーザープールのJWT
• Amazon Cognito IDプール
• サインイン後にIDプールを使ってAWSサービスへアクセスする
• ユーザープールのLambdaトリガー
• ユーザープールのMFA
• ユーザープールの脅威保護
• IAMによるSAML 2.0フェデレーション