Skip to main content

概要

主なポイント
  • Auth0 のサービスがカスタムドメインで動作するように設定します。
  • Auth0 Dashboard でカスタムドメインの検証プロセスを完了します。
  • カスタムドメインで利用できる機能の一覧を確認します。
  • カスタムドメインが URI やトークンリクエストでどのように機能するかを確認します。
  • 証明書を自分で管理するか、Auth0 に管理を任せるかを決定します。
認証ページでは、独自のドメイン名 (CNAME またはバニティURLとも呼ばれます) を使用できます。を使うと、自社のブランドや製品に合わせてログイン体験を統一できます。ユーザーには、YOUR_DOMAIN.auth0.com. ではなく、login.YOUR_DOMAIN.com のような自社ブランドの URL が表示されます。Auth0 のカスタムドメインは、テナントのドメイン URL にかぶせる「マスク」のようなものです。 カスタムドメインは、テナントの作成時に設定することも、少しのコードと設定変更で既存の実装に追加することもできます。

​
カスタムドメインを使用する利点

カスタムドメインを使用すると、ユーザーは自分の資格情報を正しい相手に提供しているという安心感を持てます。認証はブランドのコンテキスト内で行われるため、ブランドロイヤルティの向上にもつながります。ユーザーがブランド体験を損なうサードパーティのサイトにリダイレクトされることもありません。これにより、ユーザーが引き続きあなたとの取引や操作を行っているのか分からなくなる事態を防げます。 認証サービスを1か所に集約することで、アプリケーションのアーキテクチャの保守性が高まります。アプリケーションは必要最小限のアクセス権のみを取得し、認証サービスも容易にスケールできます。カスタムドメインを使用するその他のセキュリティ上の利点は次のとおりです。
  • 一部のブラウザーでは、共有ドメインがない場合、既定で iFrame 内での通信が難しくなります。
  • バニティURLを使用していると、フィッシング攻撃者はそれを模倣するために同様のバニティURLを用意しなければならないため、ドメインを悪用したフィッシングが難しくなります。たとえば、カスタムドメインでは独自の証明書を使用して Extended Validation を取得できるため、フィッシングをさらに困難にできます。
  • 従来の認証要素に代わる耐フィッシング性の高い方法であるパスキーは、Relying Party ID 属性 rpId によってカスタムドメインに紐付けられます。
カスタムドメインを設定する前は、サブドメイン (login.yourDomain.com) ではなく、親ドメインまたはルートドメイン (例: yourDomain.com) を使用することをお勧めします。Auth0 のカスタムドメインがルートドメインに設定されている場合、エンドユーザーは1つのパスキーを使って、複数の Native アプリケーションまたはモバイル Web アプリケーションで認証できます。詳しくは、Configure Passkey Policyをご覧ください。

​
仕組み

の Auth0 Dashboard > Branding > Custom Domains タブでカスタムドメインを設定します。カスタムドメインを追加し、証明書の種類を選択して、手順に従ってください。ドメインの検証プロセスを完了する必要がありますが、このプロセスは Auth0 管理 証明書と自己管理証明書のどちらを使用するかによって異なります。CNAME を作成したら、Auth0 がそれを検証してカスタムドメインを利用できるよう、Auth0 に登録する必要があります。カスタムドメインの設定と検証が完了したら、新しいカスタムドメインを使用するように Auth0 の機能を設定 する必要があります。
無料のカスタムドメインを設定するには、確認および不正利用防止のため、有効なクレジットカードが Auth0 テナントに登録されている必要があります。クレジットカードに請求されることはありません。
Auth0 では、CNAME が正しく設定されていることを確認できるよう、開発段階 (本番環境に移行する前) でカスタムドメインを作成することを推奨しています。たとえば、login.YOUR_DOMAIN.com を YOUR_DOMAIN.auth0.com にマッピングする CNAME を作成できます。
IP アドレスは変更される可能性があるため、Auth0 では固定の IP アドレス一覧を提供していません。代わりに、カスタムドメインを Allow List に追加することを推奨します。
既存のテナントを更新してカスタムドメインを使用することもできます。YOUR_DOMAIN.auth0.com を使用している既存の連携は引き続き動作します。変更後は既存のセッションが無効になるため、ユーザーは再度ログインする必要があります。また、ログイン時にエラーが発生する場合は、カスタムドメインに関連付けられたブラウザーの Cookie を削除する必要があることがあります。Embedded Lock または SDK を使用している場合は、標準のドメイン設定を使うか、カスタムドメインを使うかを選択できます。
カスタムドメインは HTTP のベストプラクティスに従う必要があります。フィールドの順序が正しくないと、重複したヘッダーが送信される可能性があります。詳しくは、RFC 7230 HTTP/1.1 Message Syntax Routing - Field Order を参照してください。

​
カスタムドメインと認証

以下の Auth0 authentication 機能は、カスタムドメインの利用に対応しています。

​
カスタムドメインと URI

Auth0 は、サードパーティのやアプリケーションの相互運用や設定のために、特定のメタデータエンドポイントを使用します。メタデータに Auth0 を参照する URI が含まれている場合、URL は、メタデータの取得時に使用したホスト名に応じて、Auth0 のサブドメインまたはカスタムドメインのいずれかになります。たとえば、次のとおりです。 詳細については、ログイン後にユーザーをリダイレクトするを参照してください。 この柔軟な動作は、次の認証シナリオに適用されます。

​
カスタムドメインとトークンリクエスト

Auth0 は、トークンリクエストで使用したドメインに対応する iss claim を含むトークンを発行します。例: カスタムドメインを使用した で を取得して を利用する場合は、カスタムドメインを使って Management API を呼び出す必要があります。そうしないと、そのトークンは無効と見なされます。トークンの iss claim は とは独立しています。カスタムドメインを使用して取得したトークンでも、audience の値は変わりません。トークンについて詳しくは、Management API Access Tokens を参照してください。

​
証明書管理のオプション

​
Auth0 管理の証明書

Auth0 では、カスタムドメインの証明書を管理し、SSL ハンドシェイクも直接処理できます。ドメインに CNAME レコードを追加すると、Auth0 がそのレコードを検証し、Auth0 サーバー上で証明書を生成します。証明書は 3 か月ごとに自動的に更新されます。検証が完了したら、Auth0 の機能を設定して、カスタムドメインの利用を開始してください。詳細については、Auth0 管理の証明書を使用したカスタムドメインの設定 を参照してください。

​
自己管理証明書

カスタムドメインでは、証明書を自分で取得して管理することができます。この場合、SSL 証明書の管理と、Auth0 にコンテンツを送信するためのリバースプロキシの設定および管理は、お客様の責任となります。Auth0 はエンドユーザーのクライアントと直接 SSL のネゴシエーションを行うのではなく、プロキシと行います。一方、プロキシはエンドユーザーと SSL のネゴシエーションを行います。自分が所有していないドメインから誰かが Auth0 アカウントを使用しようとすることを防ぐため、Auth0 はそのドメインの所有者があなたであることを検証する必要があります。そのため、検証用のヘッダー (cname-api-key) を Auth0 に提供する必要があります。このオプションを使用するには、Auth0 Enterprise の契約者である必要があります。 Auth0 では、以下のプロバイダー向けにリバースプロキシを設定する手順を提供しています。

​
詳細はこちら