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

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 Organizations を使用している場合、組織ごとに許可するカスタムドメインを制限できます。これは、各顧客がそれぞれ独自のブランドドメインを持ち、そのドメイン経由でのみ自社の組織にアクセスする必要がある 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: ドメインメタデータを使用して、ドメインごとにログインページをカスタマイズ
• Email templates: カスタムドメイン変数を使用して、メールをパーソナライズ
• Application UI: 認証体験に合わせて、アプリケーションのブランド表現を統一

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

​

パスキーの管理

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

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

​

ユーザーへの案内

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

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

​

運用と保守

​

監視とアラート

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

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

​

ドキュメント

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

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

​

テスト

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

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

​

変更管理

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

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

​

避けたいよくある落とし穴

​

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

• アンチパターン: 想定されるあらゆるパターンごとにカスタムドメインを作成する
• より良いアプローチ: まずは中核となる少数のドメインから始め、必要に応じて拡張する

​

すべての連携箇所の更新を忘れないでください

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

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

​

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

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

​

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

• アンチパターン: 証明書の有効期限が切れても、警告なしに放置すること
• より良いアプローチ: 監視と更新のプロセスを自動化すること

​

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

• アンチパターン: 関係のないブランドや顧客で同じカスタムドメインを使い回す
• よりよい方法: 認証コンテキストごとに明確に分離する

​

詳しく見る

• 複数のカスタムドメイン
• デフォルトのカスタムドメイン
• 複数のカスタムドメイン用 Management API
• 移行ガイド
• Actions との統合
• 複数のカスタムドメインでのパスキー
• カスタムドメインのトラブルシューティング