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