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

> Auth0のテナントアーキテクチャの設定が、Business to Consumer (B2C) のIdentity and Access Management (IAM) 実装にどのように影響するかを学びます。

# アーキテクチャ (B2C)

Auth0を認証およびID管理に利用するあなたの<Tooltip tip="認証とID管理をAuth0に依存しているソフトウェアです。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Application">application</Tooltip>を理解することは、Auth0をどのように活用して要件を満たせるかを把握するうえで重要です。経験上、最も成功しているお客様は、提案中のアーキテクチャ、または多くの場合は既存のアーキテクチャをまず可視化し、その後の検討を進める際の基準として活用しています。アプリケーションが組織内でどのような位置づけにあるかを理解することも重要です。Auth0の[Accounts and Tenants](/docs/ja-jp/get-started/auth0-overview/create-tenants)は、Auth0資産をグループ化し構成する基盤となるものであり、[Single Sign-on (SSO)](/docs/ja-jp/authenticate/single-sign-on)、集約されたユーザーの[Profile Management](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/profile-management)、請求の一元化などと統合するために、既存のAuth0導入環境を活用する必要がある場合もあります。

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

アーキテクチャ全体の見取り図を最初に整理しておくことは、長期的に見て大きな効果をもたらします。機能やワークフローを検討する際には、特に次の点を考慮するとよいでしょう。

* Auth0がユーザーにWebページを表示する必要がある場合、URLはどのような形にすべきでしょうか？
* SDLC (Software Development Lifecycle) を支えるために、Auth0をどのように構成できるでしょうか？
* Auth0のテナントが契約に適切に関連付けられていることを、どのように確認できるでしょうか？
* 組織内の他のプロジェクトもAuth0と統合している場合、何を考慮する必要があるでしょうか？特に、独自の、または別のユーザードメインを対象とするプロジェクト (たとえば、従業員だけが使うアプリケーション) です。

<Tooltip tip="B2Bの顧客がエンドユーザーを分類し、特定の役割、ログイン体験、リソースへのアクセスを定義できるAuth0製品です。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Organizations">
  Organizations
</Tooltip>

は、多くの場合、複数のユーザードメインに対応します。最もよく見られるのは顧客、従業員、関連会社で、通常は相互の重なりがほとんど、あるいはまったくありません。たとえば、従業員は顧客と同じ
applicationsを使わず、その逆も同様です。場合によっては、1つのドメイン内をさらに分ける必要があることもあります。たとえば、異なる独立した製品を利用する別々の顧客グループです。
Auth0は、ユーザーとそれに関連する資産を分離する方法を提供しており、[テナントのプロビジョニング](#tenant-provision)でこれをさらに詳しく説明しています。独立した

<Tooltip tip="単一のソフトウェアインスタンスに対して、特定の権限を持つ共通アクセスを共有する、論理的に分離されたユーザーグループです。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Tenant">
  テナント
</Tooltip>

をプロビジョニングする必要がある場合は、これを既存のAuth0アカウントに[関連付ける](#tenant-association)ことも必要です。そうすることで、組織が契約している

<Tooltip tip="各テナントで利用可能な機能とクォータを定義する契約です。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Subscription">
  subscription
</Tooltip>

レベルで提供される利点を最大限に活用できます。

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

さらに、Software Development Lifecycle (SDLC) の一環として、すでに確立されたプロセスや手順があるはずです。そのため、それを支えるAuth0 Tenantのプロビジョニングに関する[SDLC のサポート](#sdlc-support)のガイダンスも確認するとよいでしょう。

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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  組織内の他のグループでも Auth0 を利用している場合があります。異なるユーザーコミュニティに対応する部門が分かれていることは、お客様の組織では珍しくありません。こうした点を把握しておくと、設計上の選択肢に影響する可能性があり、早い段階で明確にしておけば、後になって大きなコストにつながりかねない判断を避けられます。
</Callout>

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

すべては Auth0 テナントから始まります。ここで Auth0 の利用設定を行い、[Applications](/docs/ja-jp/get-started/applications)、[Connections](/docs/ja-jp/authenticate/identity-providers)、[user profiles](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/profile-management) などの Auth0 のアセットを定義、管理、保存します。Auth0 テナントには Auth0 の [Dashboard](/docs/ja-jp/get-started/auth0-overview/dashboard) からアクセスし、Dashboard では追加の関連テナントを作成することもできます。Auth0 テナントは複数作成できるため、異なるユーザードメインを分離しつつ、[Software Development Life Cycle](#sdlc-support) (SDLC) にも対応できるようにテナントを構成できます。

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

ユーザードメインをどの程度分離する必要があるかを見極めることは重要なステップです。これはブランディング要件とあわせて、本番環境で必要になる Auth0 テナント数を判断する助けになります。さらに、Auth0 では本番環境で運用する各 Auth0 テナントに対して、完全な [SDLC supporting tenants](#sdlc-support) を作成することを推奨しているため、管理が必要な Auth0 テナントの数はすぐに増える可能性があります。したがって、本番用に複数の Auth0 テナントを作成する前に慎重に検討し、最終決定を行う前に [Branding](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/branding) に関するガイダンスを参照してください。

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

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

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

Auth0テナントを設定すると、そのテナントにアクセスするためのURLは `https://yourTenant.auth0.com` の形式になります。Auth0テナントに [Custom Domain](/docs/ja-jp/customize/custom-domains) (別名 vanity URL) を設定すると、ブランディング要件への対応に役立つだけでなく、さらに重要なことに、セキュリティ面でもメリットがあります。

* 一部のブラウザーでは、共有ドメインがないと、デフォルトで iFrame 内での通信が難しくなります。たとえば、[Safari's ITP causes Auth0 token renewal issues](https://support.auth0.com/center/s/article/troubleshoot-auth0-token-renewal-issues-in-safari-with-itp-enabled)。
* [vanity URL を使用すると、ドメインのフィッシングが難しくなります](https://auth0.com/blog/introducing-custom-domains-preview-with-auth0/)。これは、フィッシングを行う側も、あなたのものを模倣する vanity URL を作成しなければならないためです。たとえば、<Tooltip tip="Custom Domain: 特別な、または vanity の名前を持つサードパーティードメイン。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=custom+domain">カスタムドメイン</Tooltip> を使えば、独自の証明書を使用して「Extended Validation」を取得できるため、フィッシングはさらに難しくなります。

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

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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Auth0テナント用のカスタムドメイン (すなわち `CNAME`) を作成し、さらに開発環境にも作成して、`CNAME` を正しく管理できていることを確認してください。たとえば、`login.mycompany.com` を `mycompany-prod.auth0.com` にマッピングする `CNAME` を作成できます。
</Callout>

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

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

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

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

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

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

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

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

[B2C IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)