翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ホストされた UI への独自のドメインの使用
アプリケーションクライアントを設定したら、Amazon Cognito がホストする UI および認証サーバーエンドポイントのカスタムドメインを使用してユーザープールを設定できます。カスタムドメインを使用すると、ユーザーはデフォルトの Amazon Cognito ドメインの代わりに独自のウェブアドレスを使用してアプリケーションにサインインできます。カスタムドメインは、特にルートドメインがアプリケーションをホストするドメインと一致する場合、使い慣れたドメイン名を使用してアプリケーションのユーザー信頼を向上させます。カスタムドメインは、組織のセキュリティ要件に準拠することもできます。
カスタムドメインには、ユーザープール、アプリケーションクライアント、所有するウェブドメインなど、いくつかの前提条件があります。カスタムドメインには、米国東部 (バージニア北部) の AWS Certificate Manager (ACM) で管理されるカスタムドメインのSSL証明書も必要です。Amazon Cognito は、カスタムドメイン名のエイリアスターゲットである必要がある Amazon DNS CloudFront ディストリビューションを作成し、ACM証明書を使用して転送中に保護します。
これらの要素の準備ができたら、Amazon Cognito コンソールまたは を使用してカスタムドメインをユーザープールに追加できますAPI。これには、ドメイン名とSSL証明書を指定し、指定されたエイリアスターゲットでDNS設定を更新する必要があります。これらの変更を行った後、サインインページがカスタムドメインでアクセス可能であることを確認できます。
ユーザープールへのカスタムドメインの追加
ユーザープールにカスタムドメインを追加するには、Amazon Cognito コンソールでドメイン名を指定し、 AWS Certificate Manager () で管理する証明書を指定しますACM。ドメインを追加すると、Amazon Cognito はエイリアスターゲットを提供し、設定に追加しますDNS。
前提条件
開始するには、以下が必要です。
-
アプリクライアントを持つユーザープール。詳細については、「ユーザープールの開始方法」を参照してください。
-
所有するウェブドメイン。その親ドメインには有効な DNS A レコード が必要です。このレコードには任意の値を割り当てることができます。親は、ドメインのルート、またはドメイン階層の 1 つ上の子ドメインです。例えば、カスタムドメインが auth.xyz.example.com の場合、Amazon Cognito は xyz.example.com を IP アドレスに解決できる必要があります。お客様のインフラストラクチャへの偶発的な影響を防ぐために、Amazon Cognito はカスタムドメインのトップレベルドメイン (TLDs) の使用をサポートしていません。詳細については、「ドメイン名
」を参照してください。 -
カスタムドメインのサブドメインを作成する機能。サブドメインとして [auth] を使用することをお勧めします。例:
auth.example.com
.注記
「ワイルドカード証明書
」がない場合は、カスタムドメインのサブドメイン用に新しい証明書の取得が必要な場合があります。 -
によって管理される Secure Sockets Layer (SSL) 証明書ACM。
注記
証明書をリクエストまたはインポートする前に、ACMコンソールで AWS リージョンを米国東部 (バージニア北部) に変更する必要があります。
-
ユーザープール認証サーバーがユーザーセッションに Cookie を追加することを許可するアプリケーション。Amazon Cognito は、ホストされた UI に必要ないくつかの Cookie を設定します。たとえば
cognito
、cognito-fl
、およびXSRF-TOKEN
に適用されます。個々の Cookie はブラウザのサイズ制限に準拠していますが、ユーザープールの設定を変更すると、ホストされた UI Cookie のサイズが大きくなる可能性があります。カスタムドメインの前の Application Load Balancer (ALB) などの中間サービスでは、最大ヘッダーサイズまたは合計 Cookie サイズが適用される場合があります。アプリケーションが独自の Cookie も設定している場合、ユーザーのセッションはこれらの制限を超える可能性があります。サイズ制限の競合を避けるため、アプリケーションはホストされた UI サブドメインに Cookie を設定しないことをお勧めします。 -
Amazon CloudFront ディストリビューションを更新するアクセス許可。これを行うには、次のIAMポリシーステートメントを のユーザーにアタッチします AWS アカウント。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudFrontUpdateDistribution", "Effect": "Allow", "Action": [ "cloudfront:updateDistribution" ], "Resource": [ "*" ] } ] }
でのアクションの承認の詳細については CloudFront、「 のアイデンティティベースのポリシー (IAM ポリシー) CloudFrontの使用」を参照してください。
Amazon Cognito は当初、ディストリビューションの設定 CloudFrontに アクセスIAM許可を使用しますが、ディストリビューションは によって管理されます AWS。Amazon Cognito がユーザープールに関連付けられた CloudFront ディストリビューションの設定を変更することはできません。例えば、セキュリティポリシーでサポートされているTLSバージョンを更新することはできません。
ステップ 1: カスタムドメイン名を入力する
Amazon Cognito コンソールまたは を使用して、ユーザープールにドメインを追加できますAPI。
ステップ 2: エイリアスターゲットとサブドメインを追加する
このステップでは、前のステップのエイリアスターゲットを指すエイリアスをドメインネームサーバー (DNS) サービスプロバイダーを介してセットアップします。DNS アドレス解決に Amazon Route 53 を使用している場合は、「Route 53 を使用してエイリアスターゲットとサブドメインを追加するには」セクションを選択します。
-
DNS アドレス解決に Route 53 を使用しない場合は、DNSサービスプロバイダーの設定ツールを使用して、前のステップのエイリアスターゲットをドメインのDNSレコードに追加する必要があります。また、DNSプロバイダーはカスタムドメインのサブドメインを設定する必要があります。
-
Route 53 コンソール
にサインインします。プロンプトが表示されたら、 AWS 認証情報を入力します。 -
Route 53 にパブリックホストゾーンがない場合は、カスタムドメインの親であるルートでゾーンを作成します。詳細については、「Amazon Route 53 デベロッパーガイド」の「パブリックホストゾーンの作成」を参照してください。
-
[ホストゾーンの作成] を選択します。
-
例えば、親ドメインを入力します。
auth.example.com
カスタムドメインの などmyapp.auth.example.com
、ドメイン名リストから。 -
ホストゾーンの説明を入力します。
-
パブリックホストゾーンのホストゾーン [Type] (タイプ) を選択して、パブリッククライアントがカスタムドメインを解決できるようにします。Private hosted zone (プライベートホストゾーン) はサポートされていません。
-
必要に応じてタグを適用します。
-
[ホストゾーンの作成] を選択します。
注記
クエリをサブドメインのホストゾーンに誘導する親ホストゾーンに委任が設定されているカスタムドメインの新しいホストゾーンを作成することもできます。それ以外の場合は、A レコードを作成します。この方法により、ホストゾーンの柔軟性とセキュリティが向上します。詳細については、「Amazon Route 53 を通してホストされるドメインのサブドメインの作成
」をご覧ください。
-
-
[ホストゾーン] ページで、ホストゾーンの名前を選択します。
-
カスタムドメインの親ドメインのDNSレコードがまだない場合は、そのレコードを追加します。次のプロパティを使用して、親ドメインのDNSレコードを作成します。
-
レコード名 : 空白のままにします。
-
レコードタイプ:
A
。 -
エイリアス : 有効にしないでください。
-
値 : 選択したターゲットを入力します。このレコードは に解決する必要がありますが、レコードの値は Amazon Cognito には関係ありません。
-
TTL: を優先に設定するTTLか、デフォルトのままにします。
-
ルーティングポリシー : Simple routing を選択します。
-
-
[レコードを作成] を選択します。ドメインのレコードの例を次に示します。
example.com
:example.com.
60 IN A198.51.100.1
注記
Amazon Cognito は、本番ドメインの偶発的な乗っ取りから保護するためのカスタムドメインの親ドメインDNSの記録があることを確認します。親ドメインのDNSレコードがない場合、Amazon Cognito はカスタムドメインを設定しようとするとエラーを返します。Start of Authority (SOA) レコードは、親ドメインの検証のために十分なDNSレコードではありません。
-
次のプロパティを使用して、カスタムドメインに別のDNSレコードを追加します。
-
レコード名 : カスタムドメインプレフィックス。例えば、 のレコードを作成する
auth
場合などですauth.example.com
。 -
レコードタイプ:
A
。 -
エイリアス : 有効にします。
-
へのトラフィックのルーティング: エイリアスを Cloudfront ディストリビューション に選択します。例えば、前に記録したエイリアスターゲットを入力します
123example.cloudfront.net
。 -
ルーティングポリシー : Simple routing を選択します。
-
-
[レコードを作成] を選択します。
注記
新しいレコードがすべての Route 53 DNSサーバーに伝播されるまでに約 60 秒かかる場合があります。Route 53 GetChangeAPIメソッドを使用して、変更が伝播されたことを確認できます。
ステップ 3: サインインページを検証する
-
カスタムドメインでサインインページが表示できることを確認します。
このアドレスをブラウザに入力して、カスタムドメインとサブドメインでサインインします。これはカスタムドメインURLの例です
example.com
サブドメインを使用するauth
:https://
myapp
.auth
.example.com
/login?response_type=code&client_id=<your_app_client_id>
&redirect_uri=<your_callback_url>
カスタムドメインのSSL証明書の変更
必要な場合は、Amazon Cognito を使用して、カスタムドメインに適用した証明書を変更することができます。
通常、これは での定期的な証明書の更新後には必要ありませんACM。で既存の証明書を更新するとACM、証明書ARNの は同じままになり、カスタムドメインは自動的に新しい証明書を使用します。
ただし、既存の証明書を新しい証明書に置き換えると、 は新しい証明書に新しい ACMを付与しますARN。新しい証明書をカスタムドメインに適用するには、これを Amazon Cognito ARNに提供する必要があります。
新しい証明書の提供後、Amazon Cognito では、それがカスタムドメインに配布されるまで最大 1 時間かかります。
開始する前に
Amazon Cognito で証明書を変更する前に、証明書を に追加する必要がありますACM。詳細については、AWS Certificate Manager ユーザーガイドの「使用開始」を参照してください。
証明書を に追加するときはACM、 AWS リージョンとして米国東部 (バージニア北部) を選択する必要があります。
Amazon Cognito コンソールまたは を使用して証明書を変更できますAPI。