Auth0カスタムドメインの設定：DNSおよびSDK設定ガイド

本記事は2026年2月3日に公開された「Setting Up Auth0 Custom Domains: A Complete Guide to DNS and SDK Configuration」を翻訳した記事です。

TL;DR: このガイドではデフォルトのAuth0ドメインではなく、自社ドメインをAuth0認証で使用したい場合について、DNSの設定からSDKやAPIにおけるアプリケーションコードの更新までの手順を詳しく解説します。今回はPython/FastAPIを例に使用しますが、他のAuth0 SDKでも同様のパターンで対応できます。また、無料プランにおいてもカスタムドメインを1つまで設定できます。

Auth0でカスタムドメインを設定すると、認証フロー全体でユーザーを自社ドメインに留められます。ブランドの統一性を維持し、信頼を高め、プロフェッショナルな印象を与えられるだけでなく、認証プロセスの分析トラッキングにも役立ちます。

カスタムドメインは、無料プランを含むすべてのAuth0ユーザーが利用可能です。Auth0のデベロッパーアドボケイトとして、開発者の設定を支援する中で、よくある質問を1つにまとめました。

本ガイドでは、DNSプロバイダーでの設定と、アプリケーションに必要なコード変更の両方を網羅し、カスタムドメインを完全に機能させるまでの手順を解説します。

本チュートリアルで学べる内容は以下の通りです。

ドメイン構造の理解と選択
Auth0ダッシュボードでのカスタムドメイン設定
NamecheapやSquarespaceを用いた場合のDNSレコード設定
ドメイン設定の検証
カスタムドメインを使用するためのAuth0 SDKを更新
トークン検証のためのAPI連携の修正
セッションとソーシャルプロバイダーに関する注意点

前提条件

開始前に以下を確認してください。

ドメイン（Namecheap、Squarespace、または、その他のDNSプロバイダーで登録済みであること）
Auth0アカウント（無料プランはカスタムドメインを1つ利用できます）
プロジェクトまたはアプリ（自作のもの、あるいはAuth0 Developer Centerから取得したもの）
アプリケーションのソースコードへのアクセス権

本チュートリアルでは、簡略化のため以下のスタックを使用します。

Python 3.7以降
FastAPIアプリケーション（例としてauth0-fastapiおよびauth0-fastapi-api SDKを使用します）

注意: 例ではPython/FastAPIを使用しますが、手順はすべてのAuth0 SDKで共通です。環境変数の AUTH0_DOMAIN パラメーターをカスタムドメインに更新し、コードを微調整するパターンは変わりません。

ドメイン構造の理解

実際の設定を実施する前にドメインの仕組みを整理します。

完全なURLの構成は以下の通りです。 <サブドメイン>.<ドメイン>.com/<パス>

サブドメイン: メインドメインの前に配置します（例: auth.example.com の auth）。
ドメイン: ドメインプロバイダーから取得したメインドメインです（例: example.com）。
パス: ドメインの後に配置します（例: example.com/auth の /auth）。

Auth0カスタムドメインでは、ユーザーがサインアップやログインを行う際にルーティングする、認証用のサブドメインまたはパスを選択する必要があります。ドメインが coolest-startup-ever.com の場合の例を挙げます。

サブドメインの選択肢:

auth.coolest-startup-ever.com（本チュートリアルではこの方法を採用します）
login.coolest-startup-ever.com
accounts.coolest-startup-ever.com

パスの選択肢:

coolest-startup-ever.com/auth
coolest-startup-ever.com/login

パート1: Auth0のためのDNS設定

Auth0でのカスタムドメイン設定

DNSプロバイダーを設定する前に、Auth0テナント側でカスタムドメインをセットアップします。

ステップ1: 検証用クレジットカードの登録

無料プランであっても、カスタムドメインの設定にはクレジットカードの登録が必要です。これは本人確認が目的であり、無料プランの範囲内（カスタムドメイン1つを含む）であれば課金されませんので安心してください。

Auth0ダッシュボードにログインします。
テナント設定の支払いと請求タブに移動します。
未登録の場合は、支払い方法を追加してください。

ステップ2: カスタムドメインの構成

支払い方法の設定後、以下の手順を進めます。

ブランディング > カスタムドメインに移動します。
カスタムドメインセクションで、選択したサブドメイン（例: auth.coolest-startup-ever.com）を入力します。
証明書の種類で、Auth0-managed certificatesを選択します（ほとんどのユースケースで推奨されます）。
ドメインの追加をクリックします。

「ドメインの追加」をクリックすると、CNAMEレコードの詳細が表示されます。次のステップで使用するため、このページは開いたままにしてください。CNAMEレコードは以下のような形式です。

CNAME: <your-subdomain>.<your-domain>.com
Points to: <random-string>.edge.tenants.auth0.com

DNSプロバイダーの設定

Auth0側の設定が終わったら、サブドメインがAuth0を向くようにDNSプロバイダーを構成します。ここでは、NamecheapとSquarespaceの2つのプロバイダーを例に説明します。

重要: DNSの反映には数分から48時間かかる場合がありますが、通常は10分から30分程度で完了します。

オプション1: Namecheap

Namecheapは、DNS設定が容易な人気のドメインレジストラです。この例では、既存のWebサイト（GitHub Pagesでホストされているブログなど）にサブドメインを追加する方法を説明します。

オプション2: Squarespace

SquarespaceはWebサイトビルダー兼ドメインレジストラです。ドメインをSquarespaceで登録している場合は、以下の手順に従ってください。

注意: 本記事で使用しているドメイン（coolest-startup-ever.com）は架空のものです。

Namecheapの手順

Namecheapアカウントにログインします。
Domain Listに移動し、対象ドメインの横にあるManageをクリックします。
Advanced DNSタブを開きます。
Add New Recordをクリックします。
CNAMEレコードを以下のように構成します。
- Type: CNAME Record を選択。
- Host: サブドメインのみ入力（例: login.coolest-startup-ever.com ではなく login）。
- Value: Auth0からコピーしたCNAMEの値を貼り付け（例: <random-string>.edge.tenants.auth0.com）。
- TTL: Automatic のままにするか、反映を早めるために 1 min と設定。
緑のチェックマークをクリックして保存します。

Namecheapでは、ルートドメイン（例: coolest-startup-ever.com）をAuth0テナントドメインとして使用する場合、Hostに @ を指定できます。

Squarespaceの手順

Squarespaceアカウントにログインします。
Domainsページを開きます。
Auth0に追加するドメインをクリックします。
DNS設定に移動します。
新規ドメインの場合: 競合する可能性があるデフォルトのCNAMEレコードを削除してください。
レコードを追加をクリックし、CNAMEを選択します。
CNAMEレコードを以下のように構成します。
- ホスト: サブドメインのみ入力（例: auth.coolest-startup-ever.com ではなく auth）。
- タイプ: CNAME
- エイリアスデータ: Auth0からコピーしたCNAMEの値を貼り付け（例: <random-string>.edge.tenants.auth0.com）。
レコードを保存します。

Namecheapと異なり、Squarespaceはルートドメインを使用するためのHostへの @ 指定をサポートしていないため、必ずサブドメインを使用してください。Hostフィールドには、常にサブドメイン部分（例: auth）のみ入力します。

待ち時間の目安

設定完了後、検証プロセスには通常10分から30分かかります。「Could not verify domain」というエラーが表示された場合は、30分待ってから再度試してください。反映時間はプロバイダーやTTL設定によって異なります。

Auth0でのドメイン検証

DNSレコード構成後、正しく設定されたか確認します。

Auth0へ戻る前に、以下のツールを使ってDNSの変更が反映されたか確認できます。

dig コマンドを使用する場合（Mac/Linux）:

dig auth.coolest-startup-ever.com CNAME

ANSWERセクションのCNAMEレコードを確認してください。構成したAuth0ドメインを指していれば正常です。

MX Toolboxを使用する場合（Webベース）:

https://mxtoolbox.com/DNSLookup.aspxを開きます。
ドロップダウンから「CNAME Lookup」を選択します。
サブドメイン（例: auth.coolest-startup-ever.com）を入力します。
「CNAME Lookup」をクリックします。

Auth0ドメインを指すCNAMEレコードが表示されるはずです。

Auth0ダッシュボードで検証

DNSの反映を確認したら、Auth0ダッシュボードに戻り、以下を実行します。

ブランディング > カスタムドメインに移動します。
テストボタンをクリックします。

検証に成功すると、緑のチェックマークが表示され、ステータスが「Ready」に変わります。

DNS設定のよくあるエラーとトラブルシューティング

「Could not verify domain」エラーが発生する場合:

もう少し待つ: DNSの反映には最大30分（場合によってはそれ以上）かかることがあります。
入力ミスを確認: CNAMEレコードがAuth0から提供されたものと完全に一致しているか確認してください。
TTL設定: TTLが高すぎないか確認してください（設定中は一時的に1分に設定してください）。
重複レコード: 同じサブドメインに競合するCNAMEレコードがないか確認してください。
ルートドメインの制限: Squarespaceではルートドメインに @ を使用できない点に注意してください。

解決しない場合:

DNSキャッシュをクリアしてください: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder (Mac)
別のネットワークから検証を試してください。
DNSプロバイダーのサポートに、レコードが正しく構成されているか確認してください。

パート2: アプリケーションの更新

カスタムドメインの検証が完了しました。しかし、本番環境で使用するにはアプリケーションコードの更新が必要です。

カスタムドメインに切り替えると、背後で以下の変化が起こります。

トークン発行者（Issuer）: トークンの iss クレームが、デフォルトのAuth0ドメインからカスタムドメインに変わります。
SDK構成: 各Auth0 SDKに新しいドメインを通知する必要があります。
APIエンドポイント: トークンリクエストにカスタムドメインを使用する必要があります。
アクティブなセッション: 既存のユーザーセッションはすべて無効になります（全員ログアウトされ、再ログインが必要です）。

最後の項目は重要です。切り替え後、ユーザーに再ログインが必要になる旨を必ず周知してください。

それでは必要なコード変更を確認します。

カスタムドメイン向けにAuth0 SDK設定を更新

多くの開発者は認証処理にAuth0 SDKを使用しています。カスタムドメインを利用する場合、SDKの初期化時にデフォルトドメインではなく新しいドメインを指定するように更新します。

注意: 以下の例ではPythonとFastAPIを使用しますが、すべてのAuth0 SDKでパターンは同じです。 domain パラメーターをカスタムドメインに書き換えるだけです。各プラットフォームの詳細はSDKドキュメントを確認ください。

Auth0 FastAPI SDK（Webアプリケーション）

FastAPIを使用したPython Webアプリでは、auth0-fastapi SDKを利用します。このSDKは、ログイン、ログアウト、セッション管理を含む認証フローを処理します。

変更前: デフォルトのAuth0ドメイン

from fastapi import FastAPI
from auth0_fastapi import Auth0

app = FastAPI()

auth = Auth0(
   domain='your-tenant.us.auth0.com',
   client_id='YOUR_CLIENT_ID',
   client_secret='YOUR_CLIENT_SECRET'
)

auth.init_app(app)

@app.get("/")
async def homepage(user=auth.require_auth()):
   return {"message": f"Hello {user.name}!"}

変更後: カスタムドメイン

from fastapi import FastAPI
from auth0_fastapi import Auth0

app = FastAPI()

auth = Auth0(
   domain='auth.coolest-startup-ever.com',  # カスタムドメインを指定
   client_id='YOUR_CLIENT_ID',
   client_secret='YOUR_CLIENT_SECRET'
)

auth.init_app(app)

@app.get("/")
async def homepage(user=auth.require_auth()):
   return {"message": f"Hello {user.name}!"}

これだけです。 SDKが残りの処理を自動で実行します。ログイン、ログアウト、セッション管理にカスタムドメインが適用されます。

ドメインをハードコードせず環境変数を使用している場合は、対応する AUTH0_DOMAIN 変数の値を更新してください。

重要: このパターンは、JavaScript、React、Angular、Vue、iOS、Android、.NETなど、すべてのAuth0 SDKに当てはまります。SDK構成の domain パラメーターを更新するだけで、SDKが適切に処理します。

API連携の更新

カスタムドメインを使用すると、アクセストークンのリクエストと検証方法が少し変わります。

Auth0が発行するトークン（IDトークンとアクセストークンの両方）には、 iss（発行者）クレームが含まれます。このクレームは、トークン取得に使用したドメインを反映します。

カスタムドメイン適用前: "iss": "https://your-tenant.us.auth0.com/"
カスタムドメイン適用後: "iss": "https://auth.coolest-startup-ever.com/"

APIはトークンが信頼できる発行元からのものか検証する必要があるため、この変更は重要です。

重要: API識別子（ audience クレーム）は変更されません。 https://api.example.com のようなURI形式が一般的ですが、Audienceは単なる識別子であり、どのドメインがトークンを発行したかに関わらず一定です。

バックエンドAPIでアクセストークンを検証する際、発行者の構成を更新しなければなりません。FastAPI APIでは、auth0-fastapi-api SDKを使用します。

Auth0 FastAPI API SDK

変更前: デフォルトのAuth0ドメイン

from fastapi import FastAPI, Security
from auth0_fastapi_api import Auth0API

app = FastAPI()

auth = Auth0API(
   domain='your-tenant.us.auth0.com',
   audience='https://api.coolest-startup-ever.com'
)

@app.get("/api/private")
async def private_endpoint(user=Security(auth.get_user)):
   return {"message": f"Hello {user.sub}! This is a protected endpoint."}

変更後: カスタムドメイン

from fastapi import FastAPI, Security
from auth0_fastapi_api import Auth0API

app = FastAPI()

auth = Auth0API(
   domain='auth.coolest-startup-ever.com',  # カスタムドメインに更新
   audience='https://api.coolest-startup-ever.com'  # 変更なし
)

@app.get("/api/private")
async def private_endpoint(user=Security(auth.get_user)):
   return {"message": f"Hello {user.sub}! This is a protected endpoint."}

主な変更点:

domain をカスタムドメインに更新。
audience（API識別子）は変更なし。

domain パラメーターを更新すると、SDKは以下の処理を自動で実行します。

カスタムドメイン（https://auth.coolest-startup-ever.com/.well-known/jwks.json）からのJWKS取得。
トークン署名の検証。
発行者がカスタムドメインと一致するかの確認。
Audienceクレームの検証。

SDKを使わず手動でトークンを検証している場合、以下の更新を手動で行う必要があります。
JWKSエンドポイントURLをカスタムドメインに変更。
期待される発行者の値をカスタムドメインに変更。
Audienceの検証はそのまま維持。

環境変数を使用している場合は、ここでも AUTH0_DOMAIN の値を更新してください。

カスタムドメインに関する重要な考慮事項

セッションの無効化

カスタムドメインを有効にすると、既存の全ユーザーセッションが無効になります。これは以下を意味します。

ログイン中の全ユーザーがログアウトされます。
新しいカスタムドメインで再認証が必要になります。
旧ドメインのリフレッシュトークンは機能しません。

事前に計画を立て、ユーザーに通知してください。影響を最小限にするため、トラフィックの少ない時間帯の移行を推奨します。

開発用キーを使用しているソーシャルプロバイダー

GoogleやFacebookなどのソーシャルプロバイダーを、Auth0提供の開発用キーで使用している場合、カスタムドメインでは動作しません。各プロバイダーで独自のアプリケーション認証情報を構成する必要があります。

Auth0の開発用キーはテストを迅速に実施するためのものであり、デフォルトのAuth0ドメインに制限されています。カスタムドメインでソーシャルログインを使用するには、以下の手順が必要です。

各プロバイダー（Google、Facebookなど）でアプリケーションを作成。
Auth0ダッシュボードでOAuth認証情報を構成。
コールバックURLをカスタムドメインを使用するように更新。

詳細は、ソーシャル接続キーの構成に関するAuth0ドキュメントを確認ください。

CORS設定

ブラウザベースのアプリケーションからAuth0エンドポイントを呼び出す場合、CORS設定にカスタムドメインを含める必要があります。

Auth0ダッシュボードを開きます。
アプリケーション > 対象のアプリケーション > 設定に移動します。
許可するWebオリジンと許可するCallback URLを、カスタムドメインを含むように更新します。

設定後のテスト

更新完了後、以下のフローを十分にテストしてください。

ログインフロー:
- 認証時にカスタムドメインへリダイレクトされるか。
- ログイン中のアドレスバーのURLを確認。
トークンの確認:
- アクセストークンの iss クレームがカスタムドメインになっているか。
- jwt.ioでトークンをデコードして確認。
API呼び出し:
- APIがカスタムドメイン発行のトークンを正しく検証できるか。
- 認証成功と失敗の両方のシナリオをテスト。
ログアウトフロー:
- ログアウトリダイレクトが正常に動作するか。
- 完全にログアウトされるか。
トークンリフレッシュ:
- 新しいドメインでリフレッシュが動作するか。
- 古いリフレッシュトークンが正しく無効化されているか。
ソーシャルログイン（利用している場合）:
- 構成した各プロバイダーをテスト。
- コールバックURLが正しく動作するか。

ブラウザの開発者ツールでネットワークリクエストやJWTを確認し、すべてが期待通り動作しているか検証してください。

まとめ

カスタムドメインの設定は、ブランドの統一性を高め、ユーザーの信頼を築くために役立ちます。DNS設定からコードの更新まで、重要なポイントを振り返ります。

DNS設定:

プロバイダーによる違い: Namecheapはルートドメインに @ を使えますが、Squarespaceは使えません。Hostフィールドには常にサブドメイン部分（例: auth.example.com ではなく auth）を入力します。
タイポの確認: 最も多いトラブルです。CNAMEレコードがAuth0の提供したものと完全に一致するか確認してください。
忍耐が必要: 反映には通常10〜30分、最大48時間かかります。コーヒーでも飲んで待ちましょう。
検証ツールの活用: dig やMX Toolboxは、反映されたことを確認できる強力な味方です。

アプリケーションの更新:

すべてのSDKを更新: Auth0 SDK構成の domain パラメーターを変更します。JavaScript、React、Python、.NETなど、どのSDKでも同様です。更新後はSDKが自動で処理します。
トークン発行者の変更: トークンの iss クレームは変わりますが、 audience は変わりません。
API検証: SDKを使用している場合は domain を更新するだけです。手動検証の場合は、JWKSエンドポイントと期待される発行者の値を更新してください。
セッションリセット: 切り替え時に全員ログアウトされます。ユーザーへの周知を忘れずに行ってください。
ソーシャルIdP: 開発用キーは使えなくなります。独自の認証情報を構成してください。
徹底的なテスト: 本番投入前にすべてのフローをテストしてください。

さらに詳細を知りたい場合

本ガイドでは一般的なシナリオを解説しましたが、構成によっては以下の追加設定が必要になります。

メールテンプレートとリンク
パスワードリセットフロー
RulesとHooks
SAMLおよびWS-Fedアプリケーション
その他

これらの機能を使用している場合は、カスタムドメインを使用するための機能構成に関するAuth0ドキュメントで詳細を確認ください。