Multi-Brand Identity Simplified with Auth0 Multiple Custom Domains
Multi-Brand Identity Simplified with Auth0 Multiple Custom Domains の翻訳です。
複数ブランドのポートフォリオにまたがって、統一感がありシームレスなユーザー体験を維持するのは大変な作業になりがちです。複数のアプリケーションやサービスを運営する企業にとって、ブランドごとに別々のアイデンティティ基盤を維持するのは非効率であり、ユーザージャーニーの不整合にもつながりやすくなります。この記事では、Auth0 Multiple Custom Domains (MCD) の機能と、それがマルチブランド企業のアイデンティティ管理をどのように簡素化するのかを解説します。
マルチブランドのアイデンティティが抱える課題
よくあるビジネスシナリオを考えてみましょう。たとえば、1つの組織が1つの傘の下で複数の独立したブランドやアプリケーションを管理しているケースです。例として、教育テクノロジー企業が、生徒と教師向けのプラットフォームに加えて、企業研修や人材開発向けの別サービスを運営している、といった状況が挙げられます。
このような組織には、従来型のアイデンティティソリューションでは達成しにくい、明確な優先事項があります。
-
1つのテナントで多数のブランドをスケールさせる:
ブランドごとに新しいテナントを作成するのではなく、単一の集中管理されたアイデンティティテナントから、複数ブランドを効率よく管理・拡張したい。 -
ブランドごとにユーザー体験を最適化する:
ログインの根本的な流れは一貫していても、ユーザー体験(UX)はブランドごとに「そのブランドらしさ」を感じられるようにカスタマイズしたい。 -
ブランドごとにURLを統一する:
認証フローの途中でドメインが不統一になる(たとえば、あるブランドにアクセスしようとしたユーザーが、ログイン時に汎用のIdentity Providerドメインへリダイレクトされる)と、顧客が混乱し、ブランドへの信頼を損ねる可能性がある。
これらの課題は、さまざまなマルチブランドビジネスで共通して見られます。MCD は、単一の Auth0 テナントで複数ブランドそれぞれの distinct なカスタムドメインを管理できるようにすることで、ユーザーストアは統合したまま、表示・体験の層を分離し、これらの課題を解決します。
サンプルアプリケーション
MCD がない場合の課題を大まかに理解したところで、次はサンプルアプリケーションに MCD を実装してみましょう。ここでは、生徒と教師に特化したプラットフォーム MyLearning と、企業研修・人材開発向けに設計されたサービス Streamward を例にします。
MCD の実装は Auth0 Dashboard から開始します。このプロセスには Enterprise プランが必要で、あわせてドメイン所有権の検証も必要になります。
1. 1つのテナントで多数のブランドをスケールさせる
ここで登場するのが Centralized Domain Management です。新しい製品をローンチするたびに別テナントを立ち上げるのではなく、MCD を使えば、2つのブランド分のインフラを1か所で管理できます。
Auth0 Dashboard の中で、複数の distinct な完全修飾ドメイン名(Fully Qualified Domain Name)を追加して検証できます。たとえば、auth.my-learnings.net と auth.streamward.net を、単一テナント内で同時に運用できます。
検証は、各ブランドのURLをテナントのオリジンへ向けるシンプルな CNAME DNS レコードで行います。検証が完了すると、両方のドメインは "ready" 状態になり、管理作業の重複を増やすことなく、まったく異なる2つの事業ラインのトラフィックを捌けるようになります。
2. ブランドごとにURLを統一する
次の優先事項は、ログイン中に汎用的なURLや誤ったURLが表示されることで、ユーザーの信頼が揺らぐ事態を防ぐことです。MCD は、ブラウザのアドレスバーが常に「ユーザーが訪れようとしているアプリケーション」と一致するように、一貫した認証エンドポイントを提供します。
たとえば学生が MyLearning にログインする場合、リダイレクト先は汎用のプロバイダードメインではなく auth.my-learnings.net になります。両方のドメインは同じ Auth0 テナントを参照しているため、ユーザーの認証やデータは集中管理され共有されます。一方で Universal Login ページは、リクエストの hostname に基づいて動的にブランド適用されます。
ユーザーがログインページへ遷移する際にはブランドのURLへリダイレクトされますが、各カスタムドメインは独立したセキュリティコンテキストを持ち、それぞれ固有の Access Token とセッションが必要です。そのため、ユーザープロファイルは共有される一方で、新しいアプリケーションセッションを確立するには、ユーザーはカスタムドメインごとに別々にサインインする必要があります。この設計により、異なるドメイン間でセッションを分離して安全性を確保し、自動的なクロスドメインのシングルサインオン(SSO)伝播を防ぎつつ、共有された単一のアイデンティティプロファイルと、ログインのたびの動的ブランディングという利点は維持できます。
3. ブランドごとにユーザー体験を最適化する
最後に、メールから登録フローまで、ユーザー体験は特定のブランド(B2C か B2B か)に合わせて「そのブランド固有」に感じられる必要があります。MCD は、次の2つの主要機能を通じて、深いカスタマイズを可能にします。
Email Templates のカスタマイズ
MCD は、パスワードリセットのようなセキュリティ上重要なフローにおいて、ブランドに沿ったコミュニケーションを実現します。これは、メールテンプレート内で Liquid Syntax を使って参照できる新しい変数 custom_domain.domain を通じて行います。たとえば、メールテンプレートの From Address を support@{{ custom_domain.domain }} に設定すると、正しいブランドドメインへ動的に解決されます。
Actions による動的なアイデンティティフロー
より高度なロジックには、Auth0 Actions と拡張された event.custom_domain オブジェクトを使うことで、ドメインを意識した処理を実行できます。EA の拡張により、event.custom_domain.domain(hostname を提供)や event.custom_domain.metadata(そのドメイン向けに設定されたカスタムデータを含む)といった構造化された属性にアクセスでき、リクエストヘッダーの生データに頼るよりも、信頼性が高くデータドリブンな条件分岐が可能になります。
Use Case: Progressive Profiling Based on Brand Type
B2B と B2C のユーザーで、求めるデータ収集要件を変えることができます。
次の Post-Login Action は、ユーザーが特定の B2B ドメイン(例: store.com)経由でログインしている場合にのみ、追加データ(会社名など)を収集するフォームを動的に表示します。
exports.onExecutePostLogin = async (event, api) => {
const domain = event.custom_domain.domain;
// Check if the domain is a known restricted/allowed domain
if (domain && allowed_domains.includes(domain)) {
// Logic for allowed domains
}
// Check if the user is logging in via the specific B2B domain ('store.com')
if (domain === "store.com") {
// Render the Progressive Profiling form return
api.prompt.render("PROGRESSIVE_PROFILING");
}
// Other domains proceed with standard login
};
これにより、アイデンティティフローそのものを、カスタムドメインに紐づくビジネスセグメントに合わせて調整できます。複数テナントを用意することなく、効率的にドメイン別のオンボーディングを実現できます。
MCD であらゆるログインをパーソナライズする
MCD は、大規模な企業にとって強力なツールです。単一テナントにユーザーデータと設定を集約しつつ、アプリケーションやサービスのポートフォリオ全体でブランディングと動的なユーザー体験の調整を可能にし、アイデンティティ管理をシンプルにします。MCD を Actions と組み合わせて活用すれば、きめ細かな制御により、セキュリティと真にシームレスでブランドに沿った体験を、大規模に提供できます。
さらに学びたい方は、Multiple Custom Domains (MCD) documentation および Multiple Custom Domains Best Practices を参照してください。