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