> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # カスタムドメイン > カスタムドメイン（CNAMEまたはバニティーURL）が、ブランドを統一し、ユーザーに継続性を示すのにどのように役立つかを理解します。 重要なコンセプト * カスタムドメインが動作するようにAuth0サービスを構成する * Auth0 Dashboardを使ってカスタムドメインの検証プロセスを完了させる * カスタムドメインで動作する機能の表を確認する * URIやトークン要求でカスタムドメインが機能する仕組みを確認する * 証明書の管理を自分で行うのか、Auth0に任せるのかを選択する 認証ページで独自のドメイン名（CNAMEまたはバニティーURLとも呼ばれる）を使用できます。カスタムドメインを使用すると、ログインエクスペリエンスを独自のブランドや製品と統合できます。ユーザーに表示されるURLには、`YOUR_DOMAIN.auth0.com`の代わりに`login.YOUR_DOMAIN.com`などのブランドが表示されます。Auth0のカスタムドメインは、テナントドメインURLの「マスク」のようなものです。 テナントの作成時にカスタムドメインを設定することも、コードと設定を若干変更して既存の実装にカスタムドメインを追加することもできます。 ## カスタムドメインを使用する利点 カスタムドメインを使用していれば、ユーザーは、より確信をもって自分の資格情報を適切な相手に提供できます。認証はブランドのコンテキスト内で行われるため、ブランドロイヤリティの構築に役立ちます。ユーザーが、ブランドのコンテキストを壊すサードパーティのサイトにリダイレクトされることはありません。これにより、ユーザーがまだ取引や操作が続いているのかどうか混乱する、といったことを避けることができます。 認証サービスを1か所に含めることで、アプリケーションアーキテクチャの保守が容易になります。アプリケーションは必要なアクセスのみを取得し、認証サービスは簡単に拡張できます。カスタムドメインを使用することによるその他のセキュリティ上の利点は以下のとおりです。 * 一部のブラウザーでは、共有ドメインがない場合、デフォルトでiFrameでの通信が困難になります。 * バニティーURLがある場合、URLを模倣するにはバニティーURLを作成する必要があるため、ドメインのフィッシング詐欺が難しくなります。たとえば、カスタムドメインを使用すると、独自の証明書を使用して拡張認証を取得できるため、フィッシングがより困難になります。 ## 仕組み カスダムドメインを構成する場合は、Auth0 Dashboardの[［Auth0 Dashboard］>［Branding（ブランディング）］>［Custom Domains（カスタムドメイン）］](https://manage.auth0.com/#/custom_domains)タブで行います。カスタムドメインを追加し、証明書の種類を選択して、指示に従います。ドメインの検証プロセスを完了します。検証プロセスは、Auth0管理証明書を使用するか自己管理証明書を使用するかによって異なります。CNAMEを作成するときは、Auth0がCNAMEを検証してカスタムドメインを使用できるように、CNAMEをAuth0に対して宣言する必要があります。カスタムドメインを構成し確認したら、新しいカスタムドメインを使用するために[Auth0の機能を構成する](/docs/ja-jp/customize/custom-domains/configure-features-to-use-custom-domains)必要があります。 無料のカスタムドメインをセットアップするには、Auth0テナントは検証目的および詐欺防止のために有効なクレジットカードをファイルに保有していなければなりません。クレジットカードには請求されません。 Auth0では、CNAMEが正しく管理されていることを確認できるように、開発段階（運用環境に移行する前）でカスタムドメインを作成することを推奨しています。たとえば、`login.YOUR_DOMAIN.com`を`YOUR_DOMAIN.auth0.com`にマッピングするCNAMEを作成することができます。 IPアドレスは変更されやすいため、Auth0はIPアドレスの静的なリストを提供していません。代わりに、カスタムドメインを[Allow List（許可リスト）](/docs/ja-jp/secure/security-guidance/data-security/allowlist)に追加することをお勧めします。 カスタムドメインを使用するように既存のテナントを更新できます。`YOUR_DOMAIN.auth0.com`を使用した既存の統合はそのまま機能します。変更後は既存のセッションが無効になるため、ユーザーは再度ログインする必要があります。さらに、ログイン中にエラーが発生した場合、ユーザーはカスタムドメインに関連付けられたブラウザーCookieを削除しなければならない場合があります。埋め込み型のLockまたはSDKを使用する場合は、標準ドメイン設定とカスタムドメインのどちらを使用するかを選択できます。 カスタムドメインは、HTTPのベストプラクティスに従わなければなりません。フィールドの順序が正しくないと、ヘッダーが重複して送信される可能性があります。詳細については、「[RFC 7230 HTTP/1.1 Message Syntax Routing - Field Order](https://tools.ietf.org/html/rfc7230#section-3.2.2)」を参照してください。 ### カスタムドメインと認証 以下のAuth0認証機能は、カスタムドメインの使用をサポートしています。 | 機能またはフロー | 詳細 | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | ユニバーサルログイン | シームレスで安全なユーザーエクスペリエンスのため | | MFA | すべての要素 | | Guardian | Android SDK/Swift SDK/MFA Widget バージョン 1.3.3/Guardian.js バージョン 1.3.0以降 | | メール | カスタムドメインを使用するメールに含まれるリンク | | 接続 | データベース、ソーシャル、Google Workspace、Entra ID、 ADFS, AD/LDAP | | Lock | クロスオリジン認証を備えたバージョン 11 | | パスワードレス | ユニバーサルログインで使用（このオプションが **Dashboard > ［Tenant Settings（テナント設定）］ > ［Custom Domains（カスタムドメイン）］** で有効にされた場合、カスタムドメインを使用してメールリンクを送信） | | SAML | 接続とアプリケーション | | WS-Federation | IDプロバイダーとしてAuth0はWS-Fedアドオンを使用 | | OAuth 2.0/OIDC-Compliantフロー | [`/authorize`](/docs/ja-jp/api/authentication#authorize-application)および[`/oauth/token`](/docs/ja-jp/api/authentication#get-token)エンドポイントを使用 | ### カスタムドメインとURI Auth0は、サードパーティのIDプロバイダーやアプリケーションの相互運用性と設定のために、特定のメタデータエンドポイントを使用します。メタデータにAuth0を指し示すURIが含まれている場合は、メタデータの要求に使用したホスト名に応じて、URLはAuth0サブドメインまたはカスタムドメインのいずれかになります。例： | 使用するホスト名 | メタデータ内の参照 | | ---------------------------------------------- | ------------------------------- | | `https://travel0.auth0.com/.well-known/...` | `https://travel0.auth0.com/...` | | `https://travel0.auth0.com/samlp/metadata/...` | `https://travel0.auth0.com/...` | | `https://login.travel0.com/samlp/metadata/...` | `https://login.travel0.com/...` | 詳細については「[ログイン後にユーザーをリダイレクトする](/docs/ja-jp/authenticate/login/redirect-users-after-login)」を参照してください。 この柔軟性は、以下の認証シナリオに適用されます。 * [OpenID Connect Discoveryを使ったアプリケーションの構成](/docs/ja-jp/get-started/applications/configure-applications-with-oidc-discovery) * [SAMLサービスプロバイダーとしてのAuth0の構成](/docs/ja-jp/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider) * [SAML IDプロバイダーとしてのAuth0の構成](/docs/ja-jp/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider) ### カスタムドメインとトークン要求 Auth0は、トークン要求で使用したドメインに対して、`iss`クレームを持つトークンを発行します。例： | 使用するドメイン | issのクレーム値 | | ---------------------------------------------------------------------------------------- | ---------------------------- | | `https://travel0.auth0.com/authorize...`
`https://travel0.auth0.com/oauth/token...` | `https://travel0.auth0.com/` | | `https://login.travel0.com/authorize...`
`https://login.travel0.com/oauth/token...` | `https://login.travel0.com/` | カスタムドメインを使った認可フローを使用してManagement APIのアクセストークンを取得する場合は、そのカスタムドメインを使用してManagement APIを呼び出す必要があります。そうしないと、トークンは無効とみなされます。トークンの`iss`クレームは、オーディエンスに依存しません。カスタムドメインを使用して取得したトークンの場合、オーディエンスの値は変わりません。トークンの詳細については、「[Management APIのアクセストークン](/docs/ja-jp/secure/tokens/access-tokens/management-api-access-tokens)」をご確認ください。 ## 証明書管理のオプション ### Auth0管理証明書 Auth0は、カスタムドメインの証明書を管理し、SSLハンドシェイクを直接管理できます。ドメインにCNAMEレコードを追加すると、Auth0がそのレコードを確認し、Auth0サーバー上に証明書を生成します。この証明書は3か月ごとに自動的に更新されます。確認したら、カスタムドメインの使用を開始するために、[Auth0の機能を構成](/docs/ja-jp/customize/custom-domains/configure-features-to-use-custom-domains)します。詳細については、「[Auth0管理証明書を使ってカスタムドメインを構成する](/docs/ja-jp/customize/custom-domains/auth0-managed-certificates)」をご確認ください。 ### 自己管理証明書 カスタムドメインで[独自の証明書を取得し管理する](/docs/ja-jp/customize/custom-domains/self-managed-certificates)ことができます。この場合、SSL証明書を処理し、コンテンツをAuth0に送信するためのリバースプロキシを設定および管理するのはユーザーの責任です。Auth0は、エンドユーザークライアントと直接SSLをネゴシエートするのではなく、プロキシとSSLをネゴシエートします。その後、プロキシはエンドユーザーとSSLをネゴシエートします。他人が所有しているドメインから、誰かがあなたのAuth0アカウントを使用しようとするのを防ぐために、Auth0はそのドメインがあなたに属していることを検証する必要があります。検証するには、Auth0にヘッダー（`cname-api-key`）を指定する必要があります。このオプションを使用するには、Auth0のエンタープライズサブスクライバーである必要があります。 Auth0は、以下のプロバイダーのリバースプロキシを設定する手順を提供しています。 * [Google Cloud Platform with Load Balancing](/docs/ja-jp/customize/custom-domains/self-managed-certificates/configure-gcp-as-reverse-proxy) * [Cloudflare](/docs/ja-jp/customize/custom-domains/self-managed-certificates/configure-cloudflare-for-use-as-reverse-proxy) * [AWS CloudFront](/docs/ja-jp/customize/custom-domains/self-managed-certificates/configure-aws-cloudfront-for-use-as-reverse-proxy) * [Azure CDN](/docs/ja-jp/customize/custom-domains/self-managed-certificates/configure-azure-cdn-for-use-as-reverse-proxy) ## もっと詳しく * [機能にカスタムドメインの使用を構成する](/docs/ja-jp/customize/custom-domains/configure-features-to-use-custom-domains) * [Auth0管理証明書を使ってカスタムドメインを構成する](/docs/ja-jp/customize/custom-domains/auth0-managed-certificates) * [自己管理証明書を使ってカスタムドメインを構成する](/docs/ja-jp/customize/custom-domains/self-managed-certificates) * [カスタムドメインのトラブルシューティング](/docs/ja-jp/troubleshoot/integration-extensibility-issues/troubleshoot-custom-domains) * [プライベートクラウドのカスタムドメインを移行する](/docs/ja-jp/migrate-private-cloud-custom-domains)