アプリケーションを理解することは、Auth0 をどのように活用して要件を満たすかを考えるうえで重要です。経験上、最も成功しているお客様は、提案中の、あるいは多くの場合は既存のアーキテクチャをまず可視化し、その後の検討を進める際の基準として活用しています。アプリケーションが組織内でどのような位置付けにあるのかを把握することも重要です。Auth0 アカウントとテナント は Auth0 のアセットをグループ化し構造化する基盤となるため、シングルサインオン (SSO) 、一元化されたユーザー プロファイル管理 、請求の統合などと連携するには、既存の Auth0 デプロイメントを活用する必要がある場合もあります。
アーキテクチャ全体を最初に整理するために時間をかけることは、長期的に見て大きな効果があります。機能やワークフローを検討する際は、次のような点を考慮してください。
Auth0 がユーザーに Web ページを表示する必要がある場合、URL はどのようなものにすべきでしょうか。
SDLC (Software Development Lifecycle) を支えるために、Auth0 をどのように構成できるでしょうか。
Auth0 テナントが契約に適切にひも付いていることを、どのように確保できるでしょうか。
組織内の他のプロジェクトも Auth0 と統合している場合、何を考慮する必要があるでしょうか。特に、それぞれ独自の、または別のユーザードメインを対象とするプロジェクト (たとえば、従業員だけが使用するアプリケーション) は重要です。
顧客の組織構造やドメインを、Auth0 デプロイメントとどのように整合させることができるでしょうか。
組織は、多くの場合、複数のユーザードメインに対応しています。最もよく見られるのは顧客、従業員、提携先で、通常はそれぞれの間に重なりはほとんど、あるいはまったくありません。たとえば、従業員は顧客と同じアプリケーションを使わず、その逆も同様です。場合によっては、1 つのドメイン内でさらに分割が必要になることもあります。たとえば、異なる独立した製品を利用する別々の顧客グループがある場合です。Auth0 には、ユーザーと関連アセットを分離する方法が用意されており、 テナントのプロビジョニング でこれについてさらに詳しく説明します。独立したテナントをプロビジョニングする必要がある場合は、 これを既存の Auth0 アカウントに関連付ける ことも必要になります。これにより、組織の契約済みサブスクリプションレベルで提供される利点を最大限に活用できます。
ベストプラクティス 企業が複数のユーザーコミュニティ (顧客、パートナー、従業員など) に対応するアイデンティティ要件を持つことは珍しくありません。そのため、アーキテクチャを設計する際には、他のプロジェクトや将来の要件も必ず考慮してください。 さらに、Software Development Lifecycle (SDLC) の一環として、すでに確立されたプロセスや手順があるはずです。そのため、それを支える Auth0 テナントのプロビジョニングに関する SDLC サポート のガイダンスも確認してください。
顧客向けアプリケーションでは、通常、最もよく使用されるプロトコルは OpenID Connect (OIDC) です。OIDC では、ユーザーに提示されるブラウザー URL を使った Web ベースのワークフローを利用します。Auth0 の OIDC サポートにおけるクライアント向け URL は、標準では Auth0 ブランドになりますが、一貫した企業アイデンティティを提供し、ユーザーの信頼に関する懸念に事前に対処するためにも、Auth0 の カスタムドメイン 機能を使用することをおすすめします。
ベストプラクティス 組織内の他のグループも Auth0 を利用している可能性があります。異なるユーザーコミュニティに対応する複数の部門を持つお客様は珍しくありません。こうした点を把握することで設計上の選択に影響が及ぶ可能性があり、早い段階で確認しておけば、後で大きなコストにつながる判断を避けられるかもしれません。 顧客組織の一部またはすべてが、それぞれ独自のカスタム URL を必要とする場合や、組織ごとにブランド化されたカスタム同意ページを必要とするソーシャルプロバイダーを使用している場合は、それらの組織ごとに個別の Auth0 テナントを作成することをおすすめします。詳細は 複雑な組織向けのテナントのプロビジョニング を参照してください。
すべては Auth0 テナントから始まります。ここで Auth0 の利用方法を設定し、アプリケーション 、接続 、ユーザープロファイル などの Auth0 のアセットを定義、管理、保存します。Auth0 テナントには Auth0 の ダッシュボード からアクセスします。また、ダッシュボードから関連する追加のテナントを作成することもできます。複数の Auth0 テナントを作成して、異なるユーザードメインを分離できるように構成し、さらに Software Development Life Cycle (SDLC) もサポートできます。
テナント名は変更できず、削除後に再利用することもできません。そのため、Auth0 テナントを作成する前に、その名前で問題ないことを確認してください。
ユーザードメインに関してどの程度の分離が必要かを判断することは重要なステップです。また、ブランディング要件とあわせて検討することで、本番環境で必要になる Auth0 テナントの数を見極めやすくなります。本番環境で運用するすべての Auth0 テナントについて、SDLC をサポートするテナント を一式作成することを推奨しているため、管理が必要な Auth0 テナントの数はすぐに増える可能性があります。したがって、本番用に複数の Auth0 テナントを作成する前によく検討し、最終的な判断を下す前に ブランディング に関するガイダンスを参照してください。
ほとんどの場合、顧客の組織ごとに個別の Auth0 テナントをプロビジョニングする必要はありません。これは、新しい Organizations 機能 のリリースによって、さらに簡単になりました。ただし、状況によっては、この方法がセットアップの複雑さを軽減するうえで有効な場合もあります。たとえば、次のような場合は、ベストプラクティスとして顧客の組織ごとに個別の Auth0 テナントをプロビジョニングすることを推奨します。
顧客の組織ごとに固有のカスタムログイン URL が必要な場合。これは通常、共通のログイン URL を使用するのではなく、各組織で独自のバニティ URL を使用できるようにしている場合に限られます。Auth0 では、1 テナントにつき 1 つの カスタムドメイン
顧客の組織がログインにソーシャルプロバイダーを使用している場合。この場合、その組織向けにブランド設定された、ソーシャルプロバイダー用のカスタム同意ページが求められることがよくあります。
これらのいずれかに当てはまる場合は、上記の条件のいずれかを満たす各組織に対して、個別の Auth0 テナントを作成することを推奨します。
複数の Auth0 テナントを維持するとシステムが複雑になる可能性があるため、絶対に必要な場合を除いて実施しないでください。
すべてのテナントが Auth0 との契約に関連付けられ 、同じ機能を利用できるようにするには、すべてのテナントが会社アカウントに関連付けられていることを確認してください。テスト用に独自のサンドボックスを作成したい開発者がいる場合も、同じ権限を持てるよう、そのサンドボックスを会社アカウントに関連付けてください。これを行うには、Auth0 の担当者または Auth0 Support Center にお問い合わせください。Auth0 テナントを設定すると、そのテナントにアクセスするための URL は https://{yourTenant}.auth0.com の形式になります。Auth0 テナントに カスタムドメイン (バニティ URL とも呼ばれます) を設定することは、ブランディング要件を満たすうえで重要であるだけでなく、さらに重要な点として、セキュリティ上のメリットももたらします。
1 つの Auth0 テナントで使用できるカスタムドメインは 1 つだけです。これは、Auth0 のテナントがユーザーの「ドメイン」を表すことを意図しているためです。複数のバニティ URL が必要な場合は、複数のユーザードメインが存在する可能性が高いため、複数のテナントを使用する必要があります。
カスタムドメイン名は、認証情報を入力するのに適切な場所であるという安心感をユーザーに与えるものであるべきです。また、環境間で一貫したテストを行えるようにするため、すべての環境で早い段階からカスタムドメインを作成することを推奨します。 認証情報を入力する際に、不審な URL に注意するようユーザーを教育することは極めて重要です。
ベストプラクティス Auth0 テナント用のカスタムドメイン (別名 CNAME) を作成し、さらに開発環境にも 1 つ作成して、CNAME を正しく管理できていることを確認してください。たとえば、login.mycompany.com を mycompany-prod.auth0.com にマッピングする CNAME を作成できます。 ほとんどの場合、複数の製品ブランドやサービスブランドにまたがる認証に対して、一元化されたドメイン戦略を採用した顧客が最も成功しています。この戦略により、ユーザーに一貫した UX を提供できるだけでなく、本番環境で複数の Auth0 テナントを展開および維持する複雑さも軽減できます。ブランドごとに複数のドメインを持つことを検討している場合は、実装を始める前に ブランディング のガイダンスを参照してください。
どの企業にも何らかの Software Development Life Cycle (SDLC) があり、開発プロセス全体を通じてその戦略に合わせる必要があります。たとえば、アプリケーション自体をテストするのと同じように、Auth0 との統合もテストできる必要があります。そのため、SDLC に対応できるように Auth0 テナントを構成する ことが重要です。これを実現するためのテナントレイアウトのベストプラクティスとしては、多くのお客様が共通のパターンに従っています。
環境 テナント名の例 説明 開発 company-dev 開発作業の大半を行う共有環境 QA/テスト company-qa または company-uat 加えた変更を正式にテストするための環境 本番環境 company-prod 本番テナント
場合によっては、開発環境に影響を与えずに変更をテストできるよう、1 つ以上のサンドボックス (例: company-sandbox1 、company-sandbox2 ) を作成することもあります。こうした環境は、デプロイスクリプトなどのテストに利用できます。
Enterprise サブスクリプションをご利用のお客様は、SDLC をサポートするために設定したテナントが適切にサブスクリプションにリンクされている ことを確認してください。これにより、各テナントで同じ機能セットが有効になります。 推奨戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドを提供しています。
B2B IAM プロジェクト計画ガイド 多くの B2B プラットフォームでは、顧客の組織ごとに何らかの分離やブランディングを実装しています。そのため、Identity and Access Management (IAM) システムが複雑になることがあります。これに該当する場合は、この種の環境向けのガイダンスやベストプラクティスを確認することをお勧めします。
複数組織アーキテクチャ 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム