> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-feat-init-gt-translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# ビジネス間アーキテクチャ

> Auth0 テナントのアーキテクチャをどのように構成するかは、B2B IAM の実装に影響します。

アプリケーションを理解することは、Auth0 をどのように活用して要件を満たせるかを理解するうえで重要です。経験上、最も成功しているお客様は、提案中のアーキテクチャ、あるいは多くの場合すでに存在するアーキテクチャをまず可視化し、その後の検討を進める際の参照基盤として活用しています。アプリケーションが組織内でどのような位置づけにあるのかを理解することも重要です。Auth0 の [アカウントとテナント](/docs/ja-jp/get-started/auth0-overview/create-tenants) は、Auth0 の各種資産をグループ化し構造化する基盤となるものであり、既存の Auth0 環境を活用して、[シングルサインオン (SSO)](/docs/ja-jp/authenticate/single-sign-on)、一元化されたユーザー [プロファイル管理](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/profile-management)、請求の統合などと連携する必要がある場合もあります。

<Tip>
  複数のアプリケーションがあり、SSO を活用する必要がある場合は、先に進む前に [How to Implement Single Sign-On](https://auth0.com/learn/how-to-implement-single-sign-on/) のトレーニングガイダンスを確認することをおすすめします。
</Tip>

アーキテクチャ全体を最初に整理しておくことに時間をかける価値は、長い目で見ると十分に見合うものです。機能やワークフローを検討する際には、考慮すべき点がいくつもあります。

* Auth0 がユーザーに Web ページを表示する必要がある場合、URL はどのようなものにすべきでしょうか？
* SDLC (ソフトウェア開発ライフサイクル) を支えるために、Auth0 をどのように構成できますか？
* Auth0 テナントが契約に適切にひも付いていることを、どのように確保できますか？
* 組織内の他のプロジェクトも Auth0 と連携している場合、何を考慮する必要がありますか？特に、独自の、または異なるユーザードメインを対象とするプロジェクト (たとえば、従業員のみが使用するアプリケーション) についてです。
* 顧客組織の構造やドメインを、Auth0 の構成とどのように対応付けられますか？

組織はしばしば複数のユーザードメイン、つまり顧客、従業員、提携先などにサービスを提供しています。こうしたドメインはよく見られるものですが、通常は相互の重なりがほとんど、あるいはまったくありません。たとえば、従業員が顧客と同じアプリケーションを使うことはなく、その逆も同様です。場合によっては、1 つのドメイン内でさらに分ける必要があることもあります。たとえば、異なる独立した製品を利用する別々の顧客グループがある場合です。Auth0 には、ユーザーと関連する資産を分離する方法が用意されており、 [テナントのプロビジョニング](#tenant-provision) でこれをさらに詳しく説明しています。独立したテナントをプロビジョニングする必要がある場合は、 [これを既存の Auth0 アカウントに関連付ける](#tenant-association) ことも必要です。そうすることで、組織の契約済みサブスクリプションレベルで提供されるメリットを最大限に活用できます。

<Tip>
  企業が複数のユーザーコミュニティ (顧客、パートナー、従業員など) に対応する ID 要件を持つことは珍しくありません。そのため、アーキテクチャを設計する際には、他のプロジェクトや将来の要件も必ず考慮してください。
</Tip>

さらに、ソフトウェア開発ライフサイクル (SDLC) の一環として、すでに確立された一連のプロセスや手順があるはずです。そのため、それを支える Auth0 テナントのプロビジョニングに関する [SDLC のサポート](#sdlc-support) ガイダンスも確認することをおすすめします。

顧客向けアプリケーションでは、通常、最もよく使われるプロトコルは [OpenID Connect (OIDC)](/docs/ja-jp/authenticate/protocols/openid-connect-protocol) です。OIDC は、ユーザーに表示されるブラウザー URL を用いた Web ベースのワークフローを利用します。標準では、Auth0 の OIDC サポートで使用される顧客向け URL は Auth0 ブランドのものですが、一貫した企業ブランドを提供し、ユーザーの不安を未然に防ぐためにも、Auth0 の [カスタムドメイン](#custom-domains) 機能を使用することをおすすめします。

<Tip>
  組織内の他のグループも Auth0 を利用している可能性があります。異なるユーザーコミュニティに対応する別々の部門を持つお客様は珍しくありません。これらを特定することで設計上の選択肢に影響が出る可能性があり、早い段階で把握しておけば、後になって高くつく判断を避けられるかもしれません。
</Tip>

顧客組織の一部またはすべてが、それぞれ独自のカスタム URL を必要とする場合や、組織に合わせてブランド化されたカスタム同意ページを必要とするソーシャルプロバイダーを使用している場合は、それらの組織向けに別個の Auth0 テナントを作成することをおすすめします。詳細については [複雑な組織向けのテナントのプロビジョニング](#tenant-provision-for-complex-organizations) を参照してください。

<h2 id="tenant-provision">
  テナントのプロビジョニング
</h2>

すべては Auth0 テナントから始まります。Auth0 の利用設定はこのテナントで行い、[アプリケーション](/docs/ja-jp/get-started/applications)、[Connections](/docs/ja-jp/authenticate/identity-providers)、[ユーザープロファイル](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/profile-management) などの Auth0 の資産もここで定義、管理、保存されます。Auth0 テナントには Auth0 の [Dashboard](/docs/ja-jp/get-started/auth0-overview/dashboard) からアクセスします。また、Dashboard から追加の関連テナントを作成することもできます。Auth0 テナントは複数作成できるため、異なるユーザードメインを分離しつつ、[ソフトウェア開発ライフサイクル](#sdlc-support) (SDLC) にも対応できるようにテナントを構成できます。

<Warning>
  テナント名は変更できず、削除後に再利用することもできません。Auth0 テナントを作成する前に、その名前で問題ないことを必ず確認してください。
</Warning>

ユーザードメインについて必要な分離レベルを見極めることは重要なステップです。さらに、これはブランディング要件とあわせて、本番環境で必要になる Auth0 テナント数を判断する際の助けにもなります。本番環境で運用する Auth0 テナントごとに、[SDLC を支えるテナント一式](#sdlc-support) を作成することを推奨しているため、管理が必要な Auth0 テナント数はすぐに増える可能性があります。そのため、本番用に複数の Auth0 テナントを作成する前に十分検討し、最終判断を下す前に [Branding](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/branding) に関するガイダンスを確認してください。

<h3 id="tenant-provision-for-complex-organizations">
  複雑な組織におけるテナントのプロビジョニング
</h3>

ほとんどの場合、顧客の組織ごとに個別の Auth0 テナントをプロビジョニングする必要はありません。これは、新しい[Organizations 機能](/docs/ja-jp/manage-users/organizations/organizations-overview)のリリースによって、さらに簡単になりました。ただし、状況によっては、構成の複雑さを軽減するうえで有効な場合もあります。たとえば、次のような場合は、ベストプラクティスとして顧客の組織ごとに個別の Auth0 テナントをプロビジョニングすることを推奨します。

* 顧客の組織で、その組織専用のカスタムログイン URL が必要な場合。通常これは、共通のログイン URL を使用するのではなく、各組織が独自のバニティ URL を持てるようにしている場合に限られます。Auth0 では、1 つのテナントにつき 1 つの<Tooltip tip="カスタムドメイン: 特別な、またはバニティ名を持つサードパーティーのドメイン。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=custom+domain">カスタムドメイン</Tooltip>をサポートしています。
* 顧客の組織がログインにソーシャルプロバイダーを使用している場合。この場合、その組織向けにブランディングされたソーシャルプロバイダー用のカスタム同意ページを用意することが望ましいケースがよくあります。

これらのいずれかに当てはまる場合は、上記の条件のいずれかを満たす各組織について、個別の Auth0 テナントを作成することを推奨します。

<Warning>
  複数の Auth0 テナントを維持するとシステムが複雑になる可能性があるため、どうしても必要な場合を除き、そうすべきではありません。
</Warning>

<h2 id="tenant-association">
  テナントの関連付け
</h2>

ご利用の[すべてのテナントが Auth0 との契約に関連付けられ](/docs/ja-jp/get-started/auth0-overview/create-tenants/child-tenants)、同じ機能を利用できるようにするには、すべてのテナントが貴社アカウントに関連付けられていることを確認してください。各開発者がテスト用に独自のサンドボックスを作成したい場合は、それらにも同じ権限が付与されるよう、貴社アカウントに関連付けてください。これを行うには、Auth0 の担当者または [Auth0 Support Center](https://support.auth0.com) にお問い合わせください。

<h2 id="custom-domains">
  カスタムドメイン
</h2>

Auth0テナントを設定すると、そのテナントにアクセスするためのURLは `https://{yourTenant}.auth0.com` の形式になります。Auth0テナントに [カスタムドメイン](/docs/ja-jp/customize/custom-domains) (バニティURLとも呼ばれます) を設定することは、ブランディング要件を満たすうえで重要なだけでなく、さらに重要なこととして、セキュリティ上のメリットももたらします。

* 一部のブラウザーでは、共有ドメインがないと、デフォルトで iFrame 内での通信が難しくなります。たとえば、[SafariのITPはAuth0のトークン更新に関する問題を引き起こします](https://support.auth0.com/center/s/article/troubleshoot-auth0-token-renewal-issues-in-safari-with-itp-enabled)。
* [バニティURLがあると、ドメインはフィッシングされにくくなります](https://auth0.com/blog/introducing-custom-domains-preview-with-auth0/)。これは、攻撃者もあなたのURLをまねるためにバニティURLを作成しなければならないためです。たとえば、カスタムドメインを使えば独自の証明書を使用して「Extended Validation」を取得でき、フィッシングをさらに困難にできます。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Auth0テナントごとに許可されるカスタムドメインは1つだけです。これは、Auth0のテナントが「ユーザードメイン」を表すことを想定しているためです。複数のバニティURLが必要な場合は、複数のユーザードメインがある可能性が高いため、複数のテナントを使用するべきです。
</Callout>

また、カスタムドメイン名は、ここが認証情報を入力すべき適切な場所であるという安心感をユーザーに与えるものであるべきです。そのため、環境間で一貫したテストを行えるように、すべての環境で早い段階からカスタムドメインを作成することを推奨します。 **認証情報を入力する際に、不審なURLがないか確認するようユーザーに周知することは非常に重要です。**

<Tip>
  Auth0テナント用のカスタムドメイン (別名 `CNAME`) を作成し、開発環境にも作成してください。そうすることで、`CNAME` を正しく管理できていることを確認できます。たとえば、`login.mycompany.com` を `mycompany-prod.auth0.com` に対応付ける `CNAME` を作成できます。
</Tip>

ほとんどの場合、複数の製品ブランドやサービスブランドにまたがって、認証用の一元化されたドメインを採用する戦略が、顧客にとって最も成功しやすいものとなっています。この戦略により、ユーザーには一貫したUXが提供されるほか、本番環境で複数のAuth0テナントを展開・維持する複雑さも軽減されます。ブランドごとに複数のドメインを持つことを検討している場合は、実装を始める前に [Branding](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/branding) のガイダンスを参照してください。

<h2 id="sdlc-support">
  SDLC のサポート
</h2>

どの企業にも何らかの形で ソフトウェア開発ライフサイクル (SDLC) があり、開発プロセス全体を通して、その戦略に沿って進める必要があります。たとえば、アプリケーション自体をテストするのと同じように、Auth0 との統合もテストできなければなりません。そのため、[SDLC をサポートできるように Auth0 テナントを構成する](/docs/ja-jp/get-started/auth0-overview/create-tenants/set-up-multiple-environments)ことが重要です。これを実現するためのテナント構成のベストプラクティスには、お客様が一般的に採用している一定のパターンがあります。

| Environment | Sample Tenant Name                 | Description         |
| ----------- | ---------------------------------- | ------------------- |
| 開発          | **company-dev**                    | 開発作業の大半を行う共有環境      |
| QA/テスト      | **company-qa** または **company-uat** | 加えた変更を正式にテストするための環境 |
| 本番          | **company-prod**                   | 本番テナント              |

場合によっては、開発環境に影響を与えずに変更をテストできるよう、1 つ以上のサンドボックス (例: **company-sandbox1**, **company-sandbox2**) を作成することもあります。ここでは、デプロイスクリプトなどをテストすることになるでしょう。

<Tip>
  ダウンロードして実装プロジェクトのニーズに合わせてカスタマイズできる [Implementation Checklists](/docs/ja-jp/get-started/architecture-scenarios/checklists) も活用できます。
</Tip>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Enterprise サブスクリプションをご利用のお客様は、SDLC をサポートするために設定したテナントが、適切に[サブスクリプションに関連付けられている](/docs/ja-jp/get-started/auth0-overview/create-tenants/child-tenants)ことを確認してください。これにより、各テナントで一貫した機能セットが有効になります。
</Callout>

<h2 id="project-planning-guide">
  プロジェクト計画ガイド
</h2>

推奨する戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドをご用意しています。

[B2B IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)

<h2 id="multiple-organization-architecture-multitenancy">
  複数組織アーキテクチャ (マルチテナンシー)
</h2>

多くのB2Bプラットフォームでは、顧客組織ごとに何らかの分離やブランディングを行っており、その結果、Identity and Access Management (IAM) システムが複雑になることがあります。これに当てはまる場合は、この種の環境に関するガイダンスやベストプラクティスをぜひご一読ください。

[複数組織アーキテクチャ](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture)