複数のカスタムドメインのベストプラクティス

Auth0 における複数のカスタムドメインの導入と管理に関するベストプラクティス。

複数のカスタムドメイン (MCD) を効果的に導入するには、十分な計画とベストプラクティスに沿った運用が欠かせません。これらのガイドラインに従うことで、拡張性を確保し、堅牢なセキュリティを維持しながら、すべてのカスタムドメインで一貫したブランド体験を提供できます。

このガイドでは、複数のカスタムドメインを使用する際の計画、セキュリティ、パフォーマンス、運用、ユーザーエクスペリエンスに関するベストプラクティスを紹介します。

​

ドメインの所有権を確認する

カスタムドメインの所有権を速やかに確認できるよう、あらかじめ準備しておいてください。ドメインを長期間未確認のままにすると、スペースが煩雑になり、管理が複雑になるおそれがあります。

​

計画と設計

​

ドメイン戦略を選択する

MCD を実装する前に、どのようなドメイン戦略を採用するかを決めます。

• ブランド別: ブランドごとに個別のカスタムドメインを設定する (例: login.brand1.com, login.brand2.com)
• リージョン別: コンプライアンスやパフォーマンスを考慮して、リージョンごとにドメインを分ける (例: login.us.example.com, login.eu.example.com)
• 顧客別: エンタープライズ顧客ごとに専用ドメインを用意する (例: login.customer1.com, login.customer2.com)
• ハイブリッド: 複数の戦略を組み合わせる (例: ブランド + リージョン: login-us.brand1.com)

​

デフォルトドメインを設定する

デフォルトのカスタムドメインは、必ず設定してください。これにより、次のことが可能になります。

• ドメイン固有の動作を必要としないアプリケーションの設定を簡素化できる
• メール通知のフォールバックを提供できる
• API 呼び出しでドメインを明示的に指定する必要性を減らせる

ベストプラクティス: デフォルトには、ブランド固有のドメインではなく、汎用的なドメインまたは管理用ドメイン (例: login.company.com または admin.company.com) を使用してください。

​

スケールを見据えた計画

MCD アーキテクチャを設計する際は、将来的な拡張も考慮しましょう。

• ドメインの割り当てを文書化する: どのアプリケーションがどのドメインを使用しているかを、明確に記録しておきます
• ドメインのパターンを確保する: 将来必要になる可能性のあるドメインを登録しておきます
• 上限を監視する: ドメイン数が利用可能な上限に対してどの程度かを追跡します
• 拡張を見据えて計画する: 追加のドメインにも対応できるようにアーキテクチャを設計します

​

メタデータを活用して整理しやすくする

各カスタムドメインで利用できるメタデータフィールドを活用すると、効率的な管理とカスタマイズが可能になります。

推奨メタデータフィールド:

• brand: ブランド識別子 (例: “BrandA”、“BrandB”)
• region: 地理的リージョン (例: “us-east”、“eu-west”)
• environment: 環境の種類 (例: “production”、“staging”)
• customer_id: 顧客またはテナントの識別子
• support_email: ドメイン固有のサポート連絡先
• purpose: ドメインの用途 (例: “customer-portal”、“admin-portal”)

メタデータ構造の例:

{
  "brand": "BrandA",
  "region": "us-east",
  "environment": "production",
  "customer_id": "cust_12345",
  "support_email": "[e-mail]",
  "tier": "enterprise"
}

メタデータの用途:

• メールのカスタマイズ: メタデータに基づいてメールテンプレートをカスタマイズ
• Actions のロジック: ドメイン固有の認証ルールを実装
• フィルタリングと検索: 管理ツールでドメインを整理
• レポート: ブランド、リージョン、または顧客ごとに使用状況とパフォーマンスを追跡

​

セキュリティ

複数のカスタムドメインを導入する際は、ユースケースに応じて次のセキュリティパターンを考慮してください。

• ドメイン検証: 認証を特定のカスタムドメインのみに制限し、不正なドメイン利用を防ぎます
• 組織の分離: ユーザーが承認済みのドメイン経由でのみ組織にアクセスできるようにします
• 証明書管理: 証明書のライフサイクルを安全に管理します

​

Actions でのドメイン検証

Actions を使用すると、認証を特定のカスタムドメインに限定できます。これは、ユーザーが標準の Auth0 ドメイン経由で認証するのを防ぎたい場合や、特定のブランドドメインへのアクセスを制限したい場合に役立ちます。

exports.onExecutePostLogin = async (event, api) => {
  const domain = event.custom_domain?.domain;

  // 許可されたカスタムドメインのリスト
  const allowedDomains = [
    'login.brand1.com',
    'login.brand2.com',
    'login.example.com'
  ];

  if (!domain || !allowedDomains.includes(domain)) {
    return api.access.deny(
      `Authentication from ${domain} is not permitted.`
    );
  }
};

​

組織 ベースのアクセス制御

Auth0 組織 を使用している場合、各組織で許可されるカスタムドメインを制限できます。これは、各顧客が独自のブランドドメインを持ち、そのドメイン経由でのみ自社の組織にアクセスすべき B2B シナリオで役立ちます。

exports.onExecutePostLogin = async (event, api) => {
  const domain = event.custom_domain?.domain;

  if (!event.organization) {
    return;
  }

  // 組織の許可済みドメインを確認する
  const allowedDomains = event.organization.metadata?.allowed_domains?.split(',') || [];

  if (allowedDomains.length > 0 && !allowedDomains.includes(domain)) {
    return api.access.deny(
      `Access to ${event.organization.name} requires authentication via an approved domain.`
    );
  }
};

​

証明書の管理

• 有効期限を監視: 証明書の有効期限に関するアラートを設定します
• 更新を自動化: 自動更新には Auth0 管理の証明書 を使用します
• 自己管理の手順を文書化: 自己管理証明書を使用している場合は、明確な運用手順書を整備します

​

パフォーマンス

​

リージョン別ドメインを使用する

グローバルなアプリケーションでは、データレジデンシー要件や地域ごとのブランディングに対応するため、リージョン固有のカスタムドメインの使用を検討してください。

• 例: login-us.example.com, login-eu.example.com, login-ap.example.com

認証時の遅延は、カスタムドメイン名ではなく、Auth0 テナントがどのリージョンにデプロイされているかによって決まります。テナントのリージョンは、ユーザーが所在する地域に基づいて選択してください。

​

ブランディングとユーザーエクスペリエンス

​

ブランディングの一貫性を保つ

MCD は、ブランディングの取り組みに新たな要素を加えます。ユーザーは、あらゆる接点で一貫した体験を期待しています。

• Universal Login: ドメインメタデータを使って、ドメインごとにログインページをカスタマイズする
• メールテンプレート: カスタムドメイン変数を使ってメールをパーソナライズする
• アプリケーション UI: アプリケーションのブランディングを認証体験に合わせる

詳しくは、B2B および B2C のブランディングガイドラインを参照してください。

​

パスキーの管理

• 明確に伝える: パスキーはドメインごとに作成されることをユーザーに明確に伝えます
• 登録を促す: 3回目のログイン後にパスキーの登録を促します
• 登録状況を把握する: ユーザーがどのドメインでパスキーを登録しているかを把握します
• サポートを提供する: パスキー管理に関するわかりやすいドキュメントを提供します

詳しいガイダンスについては、複数のカスタムドメインでのパスキーを参照してください。

​

ユーザーとのコミュニケーション

ユーザーが複数のカスタムドメインを利用する場合:

• 事前に伝える: ブランドやポータルによってログインURLが異なる場合があることを説明する
• 利用方法を案内する: どのドメインを使うべきかをユーザーが理解できるようにする
• エラーに適切に対応する: ユーザーが誤ったドメインにアクセスしようとした場合は、わかりやすいエラーメッセージを表示する
• サポートドキュメントを整備する: ドメイン構成についてのわかりやすいドキュメントを維持する

​

運用と保守

​

監視とアラート

次の項目を監視するよう設定します。

• 証明書の有効期限: 有効期限の30日前、15日前、7日前にアラートを出す
• ドメイン検証ステータス: 検証失敗を監視する
• 認証の失敗: カスタムドメインごとの失敗を追跡する
• DNSの稼働状況: すべてのカスタムドメインのDNS名前解決を監視する
• APIパフォーマンス: ドメイン操作に関するManagement APIのレイテンシを追跡する

​

ドキュメント

包括的なドキュメントを整備・維持します。

• ドメイン一覧: すべてのカスタムドメインの一覧 (メタデータと用途を含む)
• アプリケーションの対応関係: どのアプリケーションがどのドメインを使用しているか
• 運用手順書: 一般的な運用作業 (ドメインの追加、証明書の更新、トラブルシューティング) の手順
• アーキテクチャ図: ドメイン構成を視覚的に示した図
• 連絡先情報: 各ドメインの担当チーム／担当者

​

テスト

本番環境に導入する前に、十分にテストしてください。

• 機能テスト: 各カスタムドメインで認証が正しく行われることを確認する
• 連携テスト: すべてのアプリケーションを、それぞれに割り当てられたカスタムドメインでテストする
• メールテスト: メールで正しいカスタムドメインが使用されていることを確認する
• フェイルオーバーテスト: 既定のドメインへのフォールバックをテストする
• 性能テスト: カスタムドメイン経由の認証に対して負荷テストを実施する

​

変更管理

カスタムドメインに変更を加える際は、次の点に注意してください。

• まずステージングで検証する: 非本番環境で変更をテストする
• 段階的に展開する: まずは一部のドメインを対象に変更を展開する
• 注意深く監視する: 展開中に問題が発生しないか確認する
• ロールバック計画を用意する: 必要に応じて変更を元に戻せるようにしておく
• 変更を周知する: 予定している変更を関係者に通知する

​

よくある落とし穴

​

ドメイン構造を複雑にしすぎない

• 避けるべきパターン: 想定されるあらゆるバリエーションごとにカスタムドメインを作成する
• より良いアプローチ: まずは中核となる少数のドメインから始め、必要に応じて増やしていく

​

すべての連携箇所を忘れずに更新する

新しいカスタムドメインを追加する際は、次の項目を更新してください。

• アプリケーションのコールバックURL
• ソーシャルプロバイダーのリダイレクトURI
• エンタープライズ接続のエンドポイント
• トークンの検証ロジック
• 監視とアラートのルール

​

ドキュメント整備をおろそかにしない

• アンチパターン: 組織内の暗黙知に頼る
• よりよいアプローチ: ドメインの割り当て内容、メタデータの意味、運用手順を文書化する

​

証明書の管理をおろそかにしないでください

• アンチパターン: 証明書の有効期限切れを見過ごすこと
• よりよいアプローチ: 監視と更新のプロセスを自動化すること

​

認証コンテキストを混在させない

• アンチパターン: 関係のないブランドや顧客で同じカスタムドメインを使い回す
• より良いアプローチ: 異なる認証コンテキストを明確に分けて管理する

​

詳細はこちら

• 複数のカスタムドメイン
• デフォルトのカスタムドメイン
• 複数のカスタムドメイン向けのManagement API
• 移行ガイド
• Actionsとの連携
• 複数のカスタムドメインでのパスキー