ユーザープールのマネージドログイン

ユーザープールのサービスをホストするウェブドメインを選択できます。ドメインを追加すると、Amazon Cognito ユーザープールで、以下の機能が利用可能になります。これらの機能を総称してマネージドログインと呼びます。

マネージドログインと一部の機能を共有する追加のオプションとして、クラシックのホストされた UI があります。クラシックのホストされた UI は、マネージドログインサービスの第 1 世代バージョンです。ホストされた UI の IdP および RP サービスは、通常、マネージドログインと同じ特性を備えていますが、ログインページの設計がよりシンプルで、機能数も少なくなっています。例えば、パスキーサインインは、クラシックのホストされた UI では利用できません。ライト機能プランの場合、クラシックのホストされた UI は、ユーザープールドメインサービスの唯一のオプションです。

マネージドログインページは、ユーザープールでの基本的なサインアップ、サインイン、多要素認証、およびパスワードリセットの各アクティビティを実行するためのウェブインターフェイスの集合です。また、ユーザーにサインインオプションの選択肢を提供する際に、ユーザーを 1 つ以上のサードパーティ ID プロバイダー (IdP) に接続します。アプリケーションは、ユーザーの認証と認可が必要なときに、ユーザーのブラウザでマネージドログインページを起動できます。

マネージドログインのユーザーエクスペリエンスは、カスタムロゴ、背景、スタイルを使用してブランディングに合わせることができます。マネージドログイン UI に適用できるブランディングの 2 つのオプションとして、マネージドログイン用のブランディングエディタと、ホストされた UI 用のホステッド UI (クラシック) ブランディングがあります。

ブランディングエディタは、ユーザープールのすべての機能プランで利用できるわけではありません。詳細については、「ユーザープールの機能プラン」を参照してください。

マネージドログインおよびホストされた UI のサービスへのリクエストを構築する方法の詳細については、「ユーザープールのエンドポイントとマネージドログインのリファレンス」を参照してください。

マネージドログインのローカリゼーション

マネージドログインでは、ユーザーインタラクティブページのデフォルト言語が英語になっています。マネージドログインページは、希望する言語にローカライズして表示できます。利用可能な言語は、AWS マネジメントコンソールで利用できる言語です。ユーザーに配信するリンクに、次の例に示すように、lang クエリパラメータを追加してください。

https://<your domain>/oauth2/authorize?lang=es&response_type=code&client_id=<your app client id>&redirect_uri=<your relying-party url>

Amazon Cognito は、lang パラメータを含む最初のリクエストを受け取ると、その言語設定を Cookie としてユーザーのブラウザに設定します。Cookie が設定されると、言語の選択は保持されるため、以降のリクエストではパラメータを表示したり、含めたりする必要がなくなります。例えば、サインインリクエストに lang=de パラメータを含めると、Cookie をクリアするか、lang=en などの新しいローカリゼーションパラメータを使用して新しいリクエストを行うまで、マネージドログインページはドイツ語で表示されます。

ローカリゼーションはマネージドログインでのみ可能です。マネージドログインブランディングを使用するには、機能プランがエッセンシャルまたはプラスであり、ドメインを割り当てている必要があります。

ユーザーがマネージドログインで行った選択は、カスタム E メールまたは SMS 送信者トリガーでは使用できません。これらのトリガーを実装するときは、他のメカニズムを使用してユーザーの希望する言語を特定する必要があります。サインインフローでは、locale 属性により、ユーザーの所在地に応じた言語が示される場合があります。サインアップフローでは、ユーザープールのリージョンまたはアプリケーションクライアント ID により、言語設定が示される場合があります。

以下の言語を使用できます。

規約ドキュメント

ユーザーのサインアップ時に、利用規約やプライバシーポリシードキュメントへのリンクを表示するように、マネージドログインページを設定できます。アプリケーションクライアントで両方の規約ドキュメントを設定すると、ユーザーのサインアップ時に「サインアップすることで、利用規約とプライバシーポリシーに同意したものとみなされます」というテキストが表示されます。マネージドログインページに [利用規約] と [プライバシーポリシー] の文字が表示され、ドキュメントにハイパーリンクされます。

規約ドキュメントは、マネージドログインのローカリゼーションに対応した言語固有の URL をサポートしています。ユーザーが lang クエリパラメータを使用して言語を選択すると、Amazon Cognito はその言語の規約ドキュメントへのリンクを表示します。特定の言語の URL を設定していない場合、Amazon Cognito はアプリケーションクライアント用に設定したデフォルトの URL を使用します。

アプリケーションクライアントの規約ドキュメントを設定するには、ユーザープールの [マネージドログイン] メニューに移動します。[規約ドキュメント] で [規約ドキュメントを作成] を選択します。

Amazon Cognito console

規約ドキュメントを作成するには

1. ユーザープールに移動し、[マネージドログイン] メニューを選択します。[規約ドキュメント] を見つけます。

2. [規約ドキュメントを作成] を選択します。

3. 規約ドキュメントを割り当てる先のアプリケーションクライアントを選択します。

4. [規約名] に入力します。コンソールでドキュメントを識別するために使用します。

5. [リンク] の下の [言語] で言語を選択し、[URL] にその言語で規約ドキュメントをホストする URL を入力します。

6. 他の言語の URL を追加するには、[別のものを追加] を選択します。

7. [作成] を選択します。

Amazon Cognito user pools API

CreateTerms リクエスト本文の例を次に示します。これにより、マネージドログインが該当言語にローカライズされている場合、アプリケーションクライアント 1example23456789 のサインアップページには、フランス語とポルトガル語 (ブラジル) バージョンのプライバシーポリシーへのリンクが表示されます。マネージドログインのサインアップページにリンクを表示するには、事前に terms-of-use の URL を設定するための別のリクエストが必要です。

{
   "ClientId": "1example23456789",
   "Enforcement": "NONE",
   "Links": { 
      "cognito:default" : "https://example.com/privacy/",
      "cognito:french" : "https://example.com/fr/privacy/",
      "cognito:portuguese-brazil" : "https://example.com/pt/privacy/"
   },
   "TermsName": "privacy-policy",
   "TermsSource": "LINK",
   "UserPoolId": "us-east-1_EXAMPLE"
}

AWS Amplify でのマネージドログインの設定

AWS Amplify を使用してウェブまたはモバイルアプリに認証を追加する場合は、Amplify コマンドラインインターフェイス (CLI) と Amplify Framework のライブラリを使用してマネージドログインページを設定できます。アプリケーションに認証を追加するには、Auth カテゴリをプロジェクトに追加します。次に、アプリケーションで Amplify クライアントライブラリを使用してユーザープールユーザーを認証します。

認証のためにマネージドログインページを呼び出すことも、IdP にリダイレクトする承認エンドポイントを介してユーザーをフェデレーションすることもできます。ユーザーがプロバイダーで正常に認証されると、Amplify は、ユーザープールに新しいユーザーを作成し、ユーザーのトークンをアプリケーションに渡します。

以下の例は、AWS Amplify を使用して、アプリケーションでソーシャルプロバイダーによるマネージドログインを設定する方法を示しています。

Amazon Cognito コンソールでのマネージドログインの設定

マネージドログインとホストされた UI の最初の要件は、ユーザープールドメインです。ユーザープールコンソールで、ユーザープールの[ドメイン] タブに移動し、Cognito ドメインまたはカスタムドメインを追加します。新しいユーザープールを作成するプロセス中にドメインを選択することもできます。詳細については、「ユーザープールのドメインを設定する」を参照してください。ユーザープールでドメインがアクティブな場合、すべてのアプリケーションクライアントは、そのドメインでパブリック認証ページを提供します。

ユーザープールドメインを作成または変更するときに、ドメインのブランディングバージョンを設定します。ブランディングバージョンとして、[マネージドログイン] または [ホストされた UI (クラシック)] のいずれかを選択できます。選択したブランディングバージョンは、ドメインでサインインサービスを使用するすべてのアプリケーションクライアントに適用されます。

次のステップでは、ユーザープールの [アプリケーションクライアント] タブで [アプリケーションクライアント] を作成します。アプリケーションクライアントを作成するプロセスで、Amazon Cognito はアプリケーションに関する情報の入力と、リターン URL の選択を求めます。リターン URL は、依拠しているパーティ(RP) の URL、リダイレクト URI、コールバック URL とも呼ばれます。これは、https://www.example.com や myapp://example など、アプリケーションの実行元の URL です。

ユーザープールでブランディングスタイルを使用してドメインとアプリケーションクライアントを設定すると、マネージドログインページがインターネットで利用可能になります。

サインインページの表示

Amazon Cognito コンソールの [アプリケーションクライアント] メニューで、アプリケーションクライアントの [ログインページ] タブにある [ログインページを表示] ボタンを選択します。このボタンを選択すると、ユーザープールドメインのサインインページに移動し、以下の基本パラメータが表示されます。

[ログインページを表示] ボタンは、マネージドログインページの基本機能をテストする場合に便利です。ログインページは、ユーザープールドメインに割り当てたブランディングバージョンと一致します。パラメータを追加または変更して、サインイン URL をカスタマイズできます。ほとんどの場合、[ログインページを表示] リンクの自動生成されたパラメータは、アプリのニーズに完全には一致しません。このような場合は、ユーザーのサインイン時にアプリが呼び出す URL をカスタマイズする必要があります。サインインパラメータのキーと値の詳細については、「ユーザープールのエンドポイントとマネージドログインのリファレンス」を参照してください。

サインインウェブページでは、次の URL 形式を使用します。この例では、response_type=code パラメーターを使って認可コードの付与をリクエストしています。

https://<your domain>/oauth2/authorize?response_type=code&client_id=<your app client id>&redirect_uri=<your relying-party url>

ユーザープールの [ドメイン] メニューでは、ユーザープールドメイン文字列を検索できます。[アプリケーションクライアント] メニューでは、アプリクライアント ID、コールバック URL、許可されているスコープ、その他の設定を確認できます。

カスタムパラメータを使用して /oauth2/authorize エンドポイントに移動すると、Amazon Cognito は /oauth2/login エンドポイントにリダイレクトするか、identity_provider または idp_identifier パラメータがある場合は、IdP サインインページにそのままリダイレクトします。

暗黙的な付与のリクエスト例

response_type=token を使用した暗黙的なコード付与で、次の URL により、サインインウェブページを表示できます。サインインが正常に行われると、Amazon Cognito がユーザープールトークンをウェブブラウザのアドレスバーに返します。

            https://mydomain.auth.us-east-1.amazoncognito.com/authorize?response_type=token&client_id=1example23456789&redirect_uri=https://mydomain.example.com
        

ID トークンとアクセストークンは、リダイレクト URL に追加されるパラメーターとして表示されます。

ここでは、暗黙的な許可リクエストからのレスポンス例を示します。

            https://auth.example.com/#id_token=eyJraaBcDeF1234567890&access_token=eyJraGhIjKlM1112131415&expires_in=3600&token_type=Bearer  
        

認証ページのカスタマイズ

Amazon Cognito は、これまでクラシックのホストされた UI のみを使用して、ログインページをホストしていました。ホストされた UI は、シンプルなデザインであり、認証ウェブページは一般的な外観でした。Amazon Cognito ユーザープールをカスタマイズするためにロゴイメージを使用したり、ファイルでいくつかの CSS スタイル値を指定して一部のスタイルを微調整したりすることができました。その後、Amazon Cognito は、ホストされた認証サービスを更新して、マネージドログインを導入しました。マネージドログインは、ブランディングエディタを備え、外観と操作感が更新されています。ブランディングエディタはノーコードのビジュアルエディタであり、ホストされた UI のカスタマイズエクスペリエンスよりも多くのオプションで構成されています。マネージドログインでは、カスタム背景画像とダークモードのテーマも導入されました。

ユーザープールでは、マネージドログインとホストされた UI 間でブランディングエクスペリエンスを切り替えることができます。マネージドログインページのカスタマイズの詳細については、「マネージドログインページにブランディングを適用する」を参照してください。

マネージドログインとホストされた UI について知っておくべきこと

マネージドログインとホストされた UI の １ 時間のセッション Cookie

ユーザーがログインページまたはサードパーティプロバイダーからサインインすると、Amazon Cognito はユーザーのブラウザに Cookie を設定します。この Cookie を使用すると、1 時間以内なら、ユーザーは同じ認証方法で再度サインインできます。ブラウザ Cookie を使用してサインインすると、アプリケーションクライアント設定で指定した期間にわたり、ユーザーは新しいトークンを付与されます。ユーザー属性または認証要素を変更しても、ブラウザ Cookie を使用して再度サインインする機能には影響しません。

セッション Cookie による認証では、Cookie の期間は別の 1 時間にリセットされません。最後に成功したインタラクティブ認証から 1 時間を超えてサインインページにアクセスする場合、ユーザーは再度サインインする必要があります。

ユーザーアカウントの確認とユーザー属性の検証

ユーザープールのローカルユーザーの場合、マネージドログインとホストされた UI は、ユーザープールを [Cognito が検証と確認のためにメッセージを自動的に送信することを許可] に設定したときに最も効果的です。この設定を有効にすると、Amazon Cognito は、サインアップしたユーザーに確認コードを含むメッセージを送信します。代わりにユーザーをユーザープール管理者として確認すると、サインアップ後にログインページにエラーメッセージが表示されます。この状態で、Amazon Cognito は新しいユーザーを作成しましたが、検証メッセージを送信できませんでした。引き続きユーザーを管理者として確認することはできますが、エラーが発生すると、ユーザーはサポートデスクに連絡する可能性があります。管理者の確認の詳細については、「ユーザーにアプリケーションへのサインアップを許可するがユーザープール管理者として確認する」を参照してください。

マネージドログインのオペレーションの範囲

マネージドログインとクラシックのホストされた UI は、サインアップ、サインイン、パスワード管理をサポートしています。これには、多要素認証 (MFA) によるサインインの完了と WebAuthn 認証子の登録が含まれます。マネージドログインは、属性の変更や MFA の設定構成など、ユーザーによるセルフサービスのプロファイル管理をサポートしていません。プロファイル管理は、独自のアプリケーションコードに実装する必要があります。また、マネージドログインでは、AdminUpdateUserAttributes API オペレーションを使用して管理者として E メールアドレスと電話番号を更新するときに、属性の変更を確認する機能も提供されていません。

設定の変更の表示

ページのスタイルを変更しても、変更がすぐに反映されない場合は、数分間待ってから、ページを更新してください。

ユーザープールトークンのデコード

Amazon Cognito ユーザープールトークンは、RS256 アルゴリズムを使用して署名されます。AWS Lambda を使用してユーザープールトークンのデコードと検証ができます。GitHub の「Amazon Cognito JWT トークンのデコードと検証」を参照してください。

TLS バージョン

マネージドログインページとホストされた UI ページには、転送中の暗号化が必要です。Amazon Cognito が提供するユーザープールドメインでは、ユーザーのブラウザが TLS バージョン 1.2 以上をネゴシエートする必要があります。カスタムドメインは、TLS バージョン 1.2 でのブラウザ接続をサポートしています。ホストされた UI (クラシック) では、カスタムドメインに TLS 1.2 は不要ですが、新しいマネージドログインでは、カスタムドメインとプレフィックスドメインの両方に TLS バージョン 1.2 が必要です。ドメインサービスの設定は、Amazon Cognito が管理するため、ユーザープールドメインの TLS 要件を変更することはできません。

CORS ポリシー

マネージドログインとホストされた UIは、どちらも、カスタムのクロスオリジンリソース共有 (CORS) オリジンポリシーをサポートしていません。CORS ポリシーにより、ユーザーがリクエストで認証パラメータを渡すことは許可されません。代わりに、アプリケーションのフロントエンドに CORS ポリシーを実装してください。Amazon Cognito は、以下のエンドポイントへのリクエストに対して Access-Control-Allow-Origin: * レスポンスヘッダーを返します。

Cookie

マネージドログインとホストされた UI は、ユーザーのブラウザに Cookie を設定します。Cookie は、サイトがサードパーティーの Cookie を設定しない一部のブラウザの要件に準拠しています。これらはユーザープールエンドポイントのみを対象とし、以下が含まれます。

iOS では、すべての Cookie をブロックできます。この設定は、マネージドログインまたはホストされた UI とは互換性がありません。この設定を有効にする可能性のあるユーザーと連携するには、AWS SDK を使用してユーザープール認証をネイティブ iOS アプリケーションに構築します。このシナリオでは、Cookie ベースではない独自のセッションストレージを構築できます。

マネージドログインのバージョン変更の影響

ドメインを追加し、マネージドログインのバージョンを設定する場合、以下の影響を考慮してください。

デフォルトのスタイル

AWS マネジメントコンソールでアプリケーションクライアントを作成すると、Amazon Cognito はアプリケーションクライアントにブランディングスタイルを自動的に割り当てます。CreateUserPoolClient オペレーションを使用してプログラムでアプリケーションクライアントを作成した場合、ブランディングスタイルは作成されません。CreateManagedLoginBranding リクエストを使用してアプリケーションクライアントを作成するまで、AWS SDK で作成したアプリケーションクライアントではマネージドログインを使用できません。

マネージドログイン認証プロンプトのタイムアウト

Amazon Cognito は認証リクエストが 5 分以内に完了しない場合にこれをキャンセルし、ユーザーをマネージドログインにリダイレクトします。ページには、Something went wrong というエラーメッセージが表示されます。