Amazon Cognito ユーザープールと ID プールでの認証の仕組み - Amazon Cognito

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Cognito ユーザープールと ID プールでの認証の仕組み

顧客が Amazon Cognito ユーザープールにサインインすると、アプリケーションは JSON ウェブトークン (JWTsを受け取ります。

ユーザーがユーザープールトークンまたは別のプロバイダーを使用して ID プールにサインインすると、アプリケーションは一時的な AWS 認証情報を受け取ります。

ユーザープールのサインインを使用すると、 AWS SDK を使用して認証と認可を完全に実装できます。独自のユーザーインターフェイス (UI) コンポーネントを構築しない場合は、構築済みのウェブ UI (ホストされた UI) またはサードパーティー ID プロバイダー (IdP) のサインインページを呼び出すことができます。

このトピックでは、アプリケーションが Amazon Cognito とやり取りして ID トークンで認証し、アクセストークンで認証し、ID プール認証情報 AWS のサービス で にアクセスする方法の概要を説明します。

AWS SDK によるユーザープール API 認証と認可

AWS は、さまざまなデベロッパーフレームワーク で Amazon Cognito ユーザープールまたは Amazon Cognito ID プロバイダー のコンポーネントを開発しました。 AWS SDK による認証これらの SDKsAmazon Cognito ユーザープール API を呼び出します。同じユーザープール API 名前空間には、ユーザープールの設定とユーザー認証のためのオペレーションがあります。詳細な概要については、「」を参照してくださいAmazon Cognito ユーザープール API とユーザープールのエンドポイントの使用

API 認証は、アプリケーションに既存の UI コンポーネントがあり、主にユーザープールをユーザーディレクトリとして使用するモデルに適合します。この設計により、Amazon Cognito がより大きなアプリケーション内のコンポーネントとして追加されます。複雑なチャレンジとレスポンスのチェーンを処理するには、プログラムによるロジックが必要です。

このアプリケーションは、OpenID Connect (OIDC) 証明書利用者の完全な実装を実装する必要はありません。代わりに、JWTsをデコードして使用できます。ローカルユーザーのユーザープール機能のすべてにアクセスする場合は、開発環境で Amazon Cognito SDK を使用して認証を構築します。

カスタム OAuth スコープを使用した API 認証は、外部 API 認証に対する指向性が低くなります。API 認証からアクセストークンにカスタムスコープを追加するには、実行時に を使用してトークンを変更しますトークン生成前の Lambda トリガー

次の図は、API 認証の一般的なサインインセッションを示しています。

ユーザーに入力を求め、 AWS SDK でサインインするアプリケーションを示すフローチャート。
API 認証フロー
  1. ユーザーはアプリケーションにアクセスします。

  2. 「サインイン」リンクを選択します。

  3. ユーザー名とパスワードを入力します。

  4. アプリケーションは API InitiateAuthリクエストを行う メソッドを呼び出します。リクエストは、ユーザーの認証情報をユーザープールに渡します。

  5. ユーザープールはユーザーの認証情報を検証し、ユーザーが多要素認証 (MFA) をアクティブ化したと判断します。

  6. ユーザープールは、MFA コードをリクエストするチャレンジで応答します。

  7. アプリケーションは、ユーザーから MFA コードを収集するプロンプトを生成します。

  8. アプリケーションは API RespondToAuthChallengeリクエストを行う メソッドを呼び出します。リクエストはユーザーの MFA コードを渡します。

  9. ユーザープールはユーザーの MFA コードを検証します。

  10. ユーザープールはユーザーの JWTs。

  11. アプリケーションは、ユーザーの JWTs。

  12. アプリケーションには、リクエストされたアクセスコントロールコンポーネントが表示されます。

  13. ユーザーは自分のコンテンツを表示します。

  14. 後で、ユーザーのアクセストークンの有効期限が切れ、アクセスコントロール対象コンポーネントの表示をリクエストします。

  15. アプリケーションは、ユーザーのセッションを永続する必要があると判断します。更新トークンを使用して InitiateAuthメソッドを再度呼び出し、新しいトークンを取得します。

バリアントとカスタマイズ

このフローは、独自のカスタム認証チャレンジなど、追加のチャレンジで強化できます。パスワードが侵害されたユーザー、または予期しないサインイン特性が悪意のあるサインインの試みを示している可能性があるユーザーのアクセスを自動的に制限できます。このフローは、サインアップ、ユーザー属性の更新、パスワードのリセットを行うオペレーションでもほぼ同じように見えます。これらのフローのほとんどには、パブリック (クライアント側) と機密 (サーバー側) の API オペレーションが重複しています。

ホストされた UI によるユーザープール認証

ホストされた UI は、ユーザープールとアプリクライアントにリンクされているウェブサイトです。ユーザーのサインイン、サインアップ、パスワードリセットの各オペレーションを実行できます。認証用のホストされた UI コンポーネントを使用するアプリケーションでは、実装に必要なデベロッパーの労力が軽減されます。アプリケーションは認証用の UI コンポーネントをスキップし、ユーザーのブラウザでホストされた UI を呼び出すことができます。

アプリケーションは、ウェブまたはアプリケーションのリダイレクト場所を使用してユーザーの JWTs を収集します。ホストされた UI を実装するアプリケーションは、OpenID Connect (OIDC) IdP であるかのようにユーザープールに接続して認証できます。

ホストされた UI 認証は、アプリケーションが認証サーバーを必要とするが、カスタム認証、ID プール統合、ユーザー属性セルフサービスなどの機能を必要としないモデルに適合します。これらの高度なオプションの一部を使用する場合は、 SDK のユーザープールコンポーネントを使用して実装できます。

OIDC 実装に主に依存するホストされた UI およびサードパーティーの IdP 認証モデルは、OAuth 2.0 スコープを使用する高度な認証モデルに最適です。

次の図は、ホストされた UI 認証の一般的なサインインセッションを示しています。

ユーザーに入力を求め、ホストされた UI でサインインするアプリケーションを示すフローチャート。
ホストされた UI 認証フロー
  1. ユーザーはアプリケーションにアクセスします。

  2. 「サインイン」リンクを選択します。

  3. アプリケーションは、ホストされた UI サインインプロンプトにユーザーを誘導します。

  4. ユーザー名とパスワードを入力します。

  5. ユーザープールはユーザーの認証情報を検証し、ユーザーが多要素認証 (MFA) をアクティブ化したと判断します。

  6. ホストされた UI は、ユーザーに MFA コードの入力を求めます。

  7. ユーザーが MFA コードを入力します。

  8. ホストされた UI は、ユーザーをアプリケーションにリダイレクトします。

  9. アプリケーションは、ホストされた UI がコールバック URL に追加した URL リクエストパラメータから認証コードを収集します。

  10. アプリケーションは認証コードを使用してトークンをリクエストします。

  11. トークンエンドポイントは JWTsをアプリケーションに返します。

  12. アプリケーションは、ユーザーの JWTs。

  13. アプリケーションには、リクエストされたアクセスコントロールコンポーネントが表示されます。

  14. ユーザーは自分のコンテンツを表示します。

  15. 後で、ユーザーのアクセストークンの有効期限が切れ、アクセスコントロール対象コンポーネントの表示をリクエストします。

  16. アプリケーションは、ユーザーのセッションを永続する必要があると判断します。更新トークンを使用して、トークンエンドポイントに新しいトークンをリクエストします。

バリアントとカスタマイズ

ホストされた UI のルックアンドフィールは、任意のアプリクライアントで CSS を使用してカスタマイズできます。また、独自の ID プロバイダー、スコープ、ユーザー属性へのアクセス、高度なセキュリティ設定を使用してアプリクライアントを設定することもできます。

サードパーティー ID プロバイダーによるユーザープール認証

外部 ID プロバイダー (IdP ) またはフェデレーション認証 を使用したサインインはホストされた UI と同様のモデルです。アプリケーションはユーザープールの OIDC 依存パーティであり、ユーザープールは IdP へのパススルーとして機能します。IdP は、Facebook や Google などのコンシューマーユーザーディレクトリでも、Azure などの SAML 2.0 や OIDC エンタープライズディレクトリでもかまいません。

ユーザーのブラウザでホストされた UI の代わりに、アプリケーションはユーザープール認証サーバー でリダイレクトエンドポイントを呼び出します。ユーザービューから、アプリケーションのサインインボタンを選択します。次に、IdP はサインインするように促します。ホストされた UI 認証と同様に、アプリケーションはアプリケーションのリダイレクト場所に JWTs を収集します。

サードパーティーの IdP による認証は、ユーザーがアプリケーションにサインアップするときに新しいパスワードを入力したくない場合があるモデルに適合します。ホストされた UI 認証が実装されているアプリケーションには、サードパーティー認証を少ない労力で追加できます。実際には、ホストされた UI とサードパーティは、ユーザーのブラウザで呼び出す内容のわずかなバリエーションから一貫した認証結果 IdPs を生成します。

ホストされた UI 認証と同様に、OAuth 2.0 スコープの高度な認証モデルにはフェデレーション認証が最適です。

次の図は、フェデレーション認証の一般的なサインインセッションを示しています。

ユーザーに入力を求め、サードパーティーの IdP でサインインするアプリケーションを示すフローチャート。
フェデレーティッド認証フロー
  1. ユーザーはアプリケーションにアクセスします。

  2. 「サインイン」リンクを選択します。

  3. アプリケーションは、IdP を使用してサインインプロンプトをユーザーに指示します。

  4. ユーザー名とパスワードを入力します。

  5. IdP はユーザーの認証情報を検証し、ユーザーが多要素認証 (MFA) をアクティブ化したと判断します。

  6. IdP は、ユーザーに MFA コードの入力を求めます。

  7. ユーザーが MFA コードを入力します。

  8. IdP は、SAML レスポンスまたは認証コードを使用してユーザーをユーザープールにリダイレクトします。

  9. ユーザーが認証コードを渡した場合、ユーザープールはコードを IdP トークンとサイレントに交換します。ユーザープールは IdP トークンを検証し、新しい認証コードを使用してユーザーをアプリケーションにリダイレクトします。

  10. アプリケーションは、ユーザープールがコールバック URL に追加した URL リクエストパラメータから認証コードを収集します。

  11. アプリケーションは認証コードを使用してトークンをリクエストします。

  12. トークンエンドポイントは JWTsをアプリケーションに返します。

  13. アプリケーションは、ユーザーの JWTs。

  14. アプリケーションには、リクエストされたアクセスコントロールコンポーネントが表示されます。

  15. ユーザーは自分のコンテンツを表示します。

  16. 後で、ユーザーのアクセストークンの有効期限が切れ、アクセスコントロール対象コンポーネントの表示をリクエストします。

  17. アプリケーションは、ユーザーのセッションを永続する必要があると判断します。更新トークンを使用して、トークンエンドポイントに新しいトークンをリクエストします。

バリアントとカスタマイズ

ホストされた UI でフェデレーション認証を開始できます。ユーザーは、アプリクライアント に割り当て IdPs た のリストから選択できます。ホストされた UI は、E メールアドレスの入力を求め、ユーザーのリクエストを対応する SAML IdP に自動的にルーティングすることもできます。 IdP サードパーティーの ID プロバイダーによる認証では、ホストされた UI とユーザーとのやり取りは必要ありません。アプリケーションは、ユーザーの認証サーバーリクエストに リクエストパラメータを追加し、ユーザーがサイレントで IdP サインインページにリダイレクトするようにできます。

ID プール認証

ID プールはアプリケーションのコンポーネントであり、関数、API 名前空間、および SDK モデルのユーザープールとは異なります。ユーザープールがトークンベースの認証と承認を提供する場合、アイデンティティプールは AWS Identity and Access Management (IAM) の認証を提供します。

のセットを ID プール IdPs に割り当てて、それらを使用してユーザーにサインインできます。ユーザープールは ID プールと密接に統合 IdPs されており、ID プールにアクセスコントロールのほとんどのオプションを提供します。同時に、ID プールには幅広い認証オプションがあります。ユーザープールは、SAML、OIDC、ソーシャル、デベロッパー、ゲスト ID ソースを ID プールからの一時的な AWS 認証情報へのルートとして結合します。

ID プールによる認証は外部です。前に示したユーザープールフローのいずれか、または別の IdP で個別に開発するフローに従います。アプリケーションが最初の認証を実行すると、証明を ID プールに渡し、代わりに一時セッションを受け取ります。

ID プールによる認証は、IAM 認証 AWS のサービス を使用して のアプリケーションアセットとデータにアクセスコントロールを適用するモデルに適合します。ユーザープール の API 認証と同様に、成功したアプリケーションには、ユーザーの利益のためにアクセスする各サービスの AWS SDKs が含まれます。 AWS SDKs、ID プール認証からの認証情報を API リクエストの署名として適用します。

次の図は、IdP による ID プール認証の一般的なサインインセッションを示しています。

ユーザーに入力を求め、サードパーティーの IdP でサインインするアプリケーションを示すフローチャート。
フェデレーティッド認証フロー
  1. ユーザーはアプリケーションにアクセスします。

  2. 「サインイン」リンクを選択します。

  3. アプリケーションは、IdP を使用してサインインプロンプトをユーザーに指示します。

  4. ユーザー名とパスワードを入力します。

  5. IdP はユーザーの認証情報を検証します。

  6. IdP は、SAML レスポンスまたは認証コードを使用してユーザーをアプリケーションにリダイレクトします。

  7. ユーザーが認証コードを渡した場合、アプリケーションはコードを IdP トークンと交換します。

  8. アプリケーションは、ユーザーの JWTs、キャッシュします。

  9. アプリケーションは API GetIdリクエストを行う メソッドを呼び出します。ユーザーのトークンまたはアサーションを渡し、アイデンティティ ID をリクエストします。

  10. ID プールは、設定された ID プロバイダーに対してトークンまたはアサーションを検証します。

  11. ID プールは ID を返します。

  12. アプリケーションは API GetCredentialsForIdentityリクエストを行う メソッドを呼び出します。ユーザーのトークンまたはアサーションを渡し、IAM ロールをリクエストします。

  13. ID プールは新しい JWT を生成します。新しい JWT には、IAM ロールをリクエストするクレームが含まれています。ID プールは、IdP の ID プール設定のユーザーのリクエストとロール選択基準に基づいてロールを決定します。

  14. AWS Security Token Service (AWS STS) は ID プールからのAssumeRoleWithWebIdentityリクエストに応答します。レスポンスには、IAM ロールを持つ一時セッションの API 認証情報が含まれています。

  15. アプリケーションはセッション認証情報を保存します。

  16. ユーザーは、 のアクセス保護されたリソースを必要とするアクションをアプリで実行します AWS。

  17. アプリケーションは、必要な API リクエストに署名として一時的な認証情報を適用します AWS のサービス。

  18. IAM は、認証情報のロールにアタッチされたポリシーを評価します。リクエストと比較します。

  19. はリクエストされたデータ AWS のサービス を返します。

  20. アプリケーションは、ユーザーのインターフェイスでデータをレンダリングします。

  21. ユーザーはデータを表示します。

バリアントとカスタマイズ

ユーザープールによる認証を視覚化するには、「トークン/アサーションの問題」ステップの後に、前のユーザープールの概要のいずれかを挿入します。デベロッパー認証は、リクエスト ID の前にあるすべてのステップを、デベロッパー認証情報 によって署名されたリクエストに置き換えます。また、ゲスト認証では、リクエスト ID に直接スキップし、認証を検証せず、アクセスが制限された IAM ロールの認証情報を返します。