メインコンテンツへスキップ

概要

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

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

カスタムドメインを使用すると、ユーザーは正しい相手に認証情報を提供しているという安心感を持てます。認証は自社ブランドの文脈の中で行われるため、ブランドへの信頼や愛着の醸成に役立ちます。ユーザーがブランディングの一貫性を損なうサードパーティのサイトにリダイレクトされることもありません。これにより、ユーザーが引き続き自社とのトランザクションや操作を行っているのかどうか混乱するのを防げます。 認証サービスを 1 か所に集約することで、アプリケーションアーキテクチャの保守性も向上します。アプリケーションには必要なアクセス権のみが付与され、認証サービスも容易にスケールできます。カスタムドメインを使用するその他のセキュリティ上の利点は次のとおりです。
  • 一部のブラウザーでは、共有ドメインがない場合、既定で iFrame 内での通信が難しくなります。
  • vanity URL を使用すると、攻撃者がその URL を模倣するには同様の vanity URL を作成する必要があるため、ドメインのフィッシングが難しくなります。たとえば、カスタムドメインでは独自の証明書を使用して Extended Validation を取得できるため、フィッシングをより困難にできます。
  • 従来の認証要素に代わるフィッシング耐性のある手段である Passkeys は、依拠当事者 ID 属性 rpId によってカスタムドメインに関連付けられます。
カスタムドメインを設定する前に、サブドメイン (login.yourDomain.com) ではなく、親ドメインまたはルートドメイン (例: yourDomain.com) を使用することをお勧めします。Auth0 でカスタムドメインをルートドメインに設定すると、エンドユーザーはネイティブアプリケーションやモバイル Web アプリケーション全体で 1 つの passkey を使って認証できます。詳しくは、Configure Passkey Policy を参照してください。

​
仕組み

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

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

次の Auth0 の認証機能は、カスタムドメインの使用に対応しています。

​
カスタムドメインと URI

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

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

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

​
証明書の管理方法

​
Auth0管理証明書

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

​
自己管理証明書

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

​
詳細情報