> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> カスタムドメイン（CNAME またはバニティ URL）を使用してブランドを統一し、ユーザーに一貫した体験を提供する方法を説明します。

# カスタムドメイン

<Card title="概要">
  主な概念

  * Auth0 のサービスがカスタムドメインで動作するように設定します。
  * Auth0 Dashboard でカスタムドメインの検証プロセスを完了します。
  * カスタムドメインで利用できる機能の一覧を確認します。
  * カスタムドメインが URI とトークンリクエストでどのように機能するかを確認します。
  * 証明書を自分で管理するか、Auth0 に管理させるかを決定します。
</Card>

認証ページでは、独自のドメイン名 (CNAME またはバニティ URL とも呼ばれます) を使用できます。<Tooltip tip="カスタムドメイン: 固有の名前、またはバニティ名を持つサードパーティドメイン。" cta="用語集を表示" href="/ja/docs/glossary?term=custom+domain">カスタムドメイン</Tooltip>を使用すると、ログイン体験を自社のブランドや製品に合わせて統一できます。ユーザーには、`YOUR_DOMAIN.auth0.com.` ではなく、`login.YOUR_DOMAIN.com` のようなブランドを示す URL が表示されます。Auth0 のカスタムドメインは、テナントドメイン URL を隠す「マスク」のようなものです。

カスタムドメインは、テナントの作成時に設定することも、既存の実装にコードと設定の軽微な変更を加えて追加することもできます。

<div id="benefits-of-using-a-custom-domain">
  ## カスタムドメインを使用する利点
</div>

カスタムドメインを使用すると、ユーザーは正しい相手に認証情報を提供しているという安心感を持てます。認証は自社ブランドの文脈の中で行われるため、ブランドへの信頼や愛着の醸成に役立ちます。ユーザーがブランディングの一貫性を損なうサードパーティのサイトにリダイレクトされることもありません。これにより、ユーザーが引き続き自社とのトランザクションや操作を行っているのかどうか混乱するのを防げます。

認証サービスを 1 か所に集約することで、アプリケーションアーキテクチャの保守性も向上します。アプリケーションには必要なアクセス権のみが付与され、認証サービスも容易にスケールできます。カスタムドメインを使用するその他のセキュリティ上の利点は次のとおりです。

* 一部のブラウザーでは、共有ドメインがない場合、既定で `iFrame` 内での通信が難しくなります。
* vanity URL を使用すると、攻撃者がその URL を模倣するには同様の vanity URL を作成する必要があるため、ドメインのフィッシングが難しくなります。たとえば、カスタムドメインでは独自の証明書を使用して Extended Validation を取得できるため、フィッシングをより困難にできます。
* 従来の認証要素に代わるフィッシング耐性のある手段である [Passkeys](/ja/docs/authenticate/database-connections/passkeys) は、依拠当事者 ID 属性 `rpId` によってカスタムドメインに関連付けられます。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  カスタムドメインを設定する前に、サブドメイン (`login.yourDomain.com`) ではなく、親ドメインまたはルートドメイン (例: `yourDomain.com`) を使用することをお勧めします。Auth0 でカスタムドメインをルートドメインに設定すると、エンドユーザーはネイティブアプリケーションやモバイル Web アプリケーション全体で 1 つの passkey を使って認証できます。詳しくは、[Configure Passkey Policy](/ja/docs/authenticate/database-connections/passkeys/configure-passkey-policy#configure-relying-party-id-rpid) を参照してください。
</Callout>

<div id="how-it-works">
  ## 仕組み
</div>

<Tooltip tip="Auth0 Dashboard: サービスを設定するための Auth0 のメイン製品です。" cta="用語集を見る" href="/ja/docs/glossary?term=Auth0+Dashboard">Auth0 Dashboard</Tooltip> の [Branding > Custom Domains](https://manage.auth0.com/#/custom_domains) タブでカスタムドメインを設定します。カスタムドメインを追加し、証明書の種類を選択して、手順に従ってください。ドメインの検証プロセスは、Auth0 管理証明書とセルフマネージド証明書のどちらを使用するかによって異なります。CNAME を作成したら、Auth0 がその CNAME を検証してカスタムドメインを使用できるよう、Auth0 に申告する必要があります。カスタムドメインの設定と検証が完了したら、新しいカスタムドメインを使用するように [Auth0 の機能を設定](/ja/docs/customize/custom-domains/configure-features-to-use-custom-domains) する必要があります。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  無料のカスタムドメインを設定するには、確認および不正防止のため、Auth0 テナントに有効なクレジットカードが登録されている必要があります。クレジットカードに請求されることはありません。
</Callout>

Auth0 では、CNAME が正しく設定されていることを確認するため、開発段階 (本番環境に移行する前) でカスタムドメインを作成することを推奨しています。たとえば、`login.YOUR_DOMAIN.com` を `YOUR_DOMAIN.auth0.com` にマッピングする CNAME を作成できます。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Auth0 は固定の IP アドレス一覧を提供していません。IP アドレスは変更される可能性があるためです。代わりに、カスタムドメインを [Allow List](/ja/docs/secure/security-guidance/data-security/allowlist) に追加することを推奨します。
</Callout>

既存のテナントを更新してカスタムドメインを使用できます。`YOUR_DOMAIN.auth0.com` を使用する既存の統合は引き続き動作します。変更後は既存のセッションが無効になるため、ユーザーは再度ログインする必要があります。また、ログイン時にエラーが発生する場合は、ユーザーがカスタムドメインに関連付けられたブラウザー Cookie を削除する必要があることがあります。埋め込み Lock または SDK を使用している場合は、標準ドメイン設定とカスタムドメイン設定のいずれかを選択できます。

<Warning>
  カスタムドメインは HTTP のベストプラクティスに従う必要があります。フィールドの順序が正しくないと、重複したヘッダーが送信される可能性があります。詳細については、[RFC 7230 HTTP/1.1 Message Syntax Routing - Field Order](https://tools.ietf.org/html/rfc7230#section-3.2.2) を参照してください。
</Warning>

<div id="custom-domains-and-authentication">
  ### カスタムドメインと認証
</div>

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

| 機能またはフロー                                            | 詳細                                                                                                                                                                                                                        |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Universal Login                                     | シームレスで安全なユーザーエクスペリエンスのため                                                                                                                                                                                                  |
| MFA                                                 | すべての認証要素                                                                                                                                                                                                                  |
| Guardian                                            | Android SDK/Swift SDK/MFA Widget バージョン 1.3.3/Guardian.js バージョン 1.3.0 以降                                                                                                                                                   |
| Emails                                              | メールに含まれるリンクでカスタムドメインが使用されます                                                                                                                                                                                               |
| Connections                                         | データベース、ソーシャル、Google Workspace、Azure AD、ADFS、AD/LDAP                                                                                                                                                                       |
| [Lock](/ja/docs/glossary?term=Lock)                 | クロスオリジン認証に対応したバージョン 11                                                                                                                                                                                                    |
| [Passwordless](/ja/docs/glossary?term=Passwordless) | Universal Login と併用 (**Dashboard > Tenant Settings > Custom Domains** でオプションを有効にすると、送信されるメールのリンクでカスタムドメインが使用されます。)                                                                                                        |
| [SAML](/ja/docs/glossary?term=SAML)                 | 接続とアプリケーション                                                                                                                                                                                                               |
| WS-Federation                                       | WS-Fed アドオンを使用する、IDプロバイダーとしての Auth0                                                                                                                                                                                       |
| OAuth 2.0/OIDC 準拠フロー                                | [`/authorize`](https://auth0.com/docs/api/authentication/authorization-code-flow/authorize-application) エンドポイントと [`/oauth/token`](https://auth0.com/docs/api/authentication/authorization-code-flow/get-token) エンドポイントを使用 |

<div id="custom-domains-and-uris">
  ### カスタムドメインと URI
</div>

Auth0 は、サードパーティの<Tooltip tip="IDプロバイダー（IdP）：デジタル ID を保存・管理するサービス。" cta="用語集を表示" href="/ja/docs/glossary?term=identity+providers">IDプロバイダー</Tooltip>やアプリケーションの相互運用性と構成のために、特定のメタデータエンドポイントを使用します。メタデータに Auth0 を指す URI が含まれている場合、その URL は、メタデータのリクエストに使用したホスト名に応じて、Auth0 のサブドメインまたはカスタムドメインのいずれかになります。例:

| 使用する URL                                       | メタデータ内の参照先                      |
| ---------------------------------------------- | ------------------------------- |
| `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/...` |

詳細については、[ログイン後にユーザーをリダイレクトする](/ja/docs/authenticate/login/redirect-users-after-login)を参照してください。

この柔軟性は、次の認証シナリオに適用されます。

* [OpenID Connect Discovery でアプリケーションを設定する](/ja/docs/get-started/applications/configure-applications-with-oidc-discovery)
* [Auth0 を SAML サービスプロバイダーとして設定する](/ja/docs/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider)
* [Auth0 を SAML IDプロバイダーとして設定する](/ja/docs/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider)

<div id="custom-domains-and-token-requests">
  ### カスタムドメインとトークンリクエスト
</div>

Auth0 は、トークンリクエストで使用したドメインを `iss` クレームに持つトークンを発行します。例:

| 使用するもの                                                                                   | iss のクレーム値                   |
| ---------------------------------------------------------------------------------------- | ---------------------------- |
| `https://travel0.auth0.com/authorize...`<br />`https://travel0.auth0.com/oauth/token...` | `https://travel0.auth0.com/` |
| `https://login.travel0.com/authorize...`<br />`https://login.travel0.com/oauth/token...` | `https://login.travel0.com/` |

カスタムドメインを使用した <Tooltip tip="Management API: 顧客が管理タスクを実行できるようにするプロダクト。" cta="用語集を表示" href="/ja/docs/glossary?term=authorization+flow">認可フロー</Tooltip> で <Tooltip tip="アクセストークン: API へのアクセスに使用される、不透明文字列または JWT 形式の認可資格情報。" cta="用語集を表示" href="/ja/docs/glossary?term=access+token">アクセストークン</Tooltip> を <Tooltip tip="アクセストークン: API へのアクセスに使用される、不透明文字列または JWT 形式の認可資格情報。" cta="用語集を表示" href="/ja/docs/glossary?term=Management+API">Management API</Tooltip> 用に取得した場合は、Management API の呼び出しにもカスタムドメインを使用する必要があります。そうしないと、そのトークンは無効と見なされます。トークンの `iss` クレームは、<Tooltip tip="対象者: 発行されたトークンの対象者を識別する一意の識別子。トークンでは aud という名前で、その値には IDトークン の場合はアプリケーション (クライアントID)、アクセストークン の場合は API (API Identifier) の ID が含まれます。" cta="用語集を表示" href="/ja/docs/glossary?term=audience">オーディエンス</Tooltip> とは独立しています。カスタムドメインを使用して取得したトークンでも、オーディエンスの値は変わりません。トークンの詳細については、[Management API Access Tokens](/ja/docs/secure/tokens/access-tokens/management-api-access-tokens) を参照してください。

<div id="certificate-management-options">
  ## 証明書の管理方法
</div>

<div id="auth0-managed-certificates">
  ### Auth0管理証明書
</div>

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

<div id="self-managed-certificates">
  ### 自己管理証明書
</div>

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

Auth0 は、次のプロバイダー向けにリバースプロキシを設定する手順を提供しています。

* [ロードバランシングを使用する Google Cloud Platform](/ja/docs/customize/custom-domains/self-managed-certificates/configure-gcp-as-reverse-proxy)
* [Cloudflare](/ja/docs/customize/custom-domains/self-managed-certificates/configure-cloudflare-for-use-as-reverse-proxy)
* [AWS CloudFront](/ja/docs/customize/custom-domains/self-managed-certificates/configure-aws-cloudfront-for-use-as-reverse-proxy)
* [Azure CDN](/ja/docs/customize/custom-domains/self-managed-certificates/configure-azure-cdn-for-use-as-reverse-proxy)

<div id="learn-more">
  ## 詳細情報
</div>

* [カスタムドメインを使用するための機能を設定する](/ja/docs/customize/custom-domains/configure-features-to-use-custom-domains)
* [Auth0管理証明書を使用してカスタムドメインを設定する](/ja/docs/customize/custom-domains/auth0-managed-certificates)
* [自己管理証明書を使用してカスタムドメインを設定する](/ja/docs/customize/custom-domains/self-managed-certificates)