> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.
# アーキテクチャ（B2C）
> 企業・消費者間（B2C）にIDおよびアクセス管理（IAM）の実装で影響する、Auth0テナントのアーキテクチャを構成する方法について説明します。
アプリケーションを理解することは、ニーズを満たすためにAuth0をどのように活用できるかを理解する上で重要な鍵となります。経験上、当社で最も成功しているお客様は、提案された（または多くの場合、既存の）アーキテクチャの視覚化から開始し、これを作業を進める際の参照の基礎としています。また、組織内におけるアプリケーションの位置付けを理解することも大切です。Auth0の[アカウントとテナント](/docs/ja-jp/get-started/auth0-overview/create-tenants)はAuth0アセットのグループ化と構造化の基礎となります。[シングルサインオン（SSO）](/docs/ja-jp/authenticate/single-sign-on)、一元化されたユーザー[プロファイル管理](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/profile-management)、統合された請求機能といった各種機能を統合するために、既存のAuth0デプロイメントを活用する必要があるかもしれません。
### ベストプラクティス
複数のアプリケーションがあって、SSOを活用する必要がある場合、次に進む前に[「シングルサインオンの実装方法」](https://auth0.com/learn/how-to-implement-single-sign-on/)のトレーニングガイダンスを確認することをお勧めします。
アーキテクチャのランドスケープに事前に時間を投資すれば、長期的に見て利益をもたらすことがわかっています。また、機能やワークフローを検討する際には、考慮すべきことが数多くあります。
* Auth0がユーザーにWebページを表示する必要がある場合、URLはどのようなものであるべきか。
* SDLC（ソフトウェア開発ライフサイクル）をサポートするには、Auth0をどのように構成すればよいか。
* Auth0テナントが契約に適切に関連付けられていることを確認するにはどうすればよいか。
* 組織内にAuth0と統合する他のプロジェクトがある場合、何を考慮すればよいか。特に、自身のドメイン、または別のドメインのユーザーを対象としたプロジェクト（たとえば、従業員だけが使用するアプリケーション）です。
多くの場合、組織は複数のドメインのユーザーにサービスを提供します。顧客、従業員、関連会社が最も頻繁に利用しますが、通常、交差することはほぼありません。たとえば、従業員が顧客と同じアプリケーションを使用することはなく、その逆も同様です。場合によっては、ドメイン内をさらに分割する必要がある場合もあります。たとえば、接続されていない異なる製品を使用する顧客をグループに分ける場合などです。Auth0は、ユーザーと関連するコラテラルとを分離する方法を提供しており、これについては[テナントプロビジョニング](#tenant-provision)で詳細を説明します。独立したテナントをプロビジョニングする必要がある場合は、[既存のAuth0アカウントにこれを関連付け](#tenant-association)、自社が契約しているサブスクリプションレベルで提供される機能を最大限活用できるようにしてください。
### ベストプラクティス
たとえば、会社に、顧客、パートナー、従業員といった複数のユーザーグループに対応するためのID要件があることは、珍しいことではありません。アーキテクチャを設計する際に別のプロジェクトまたは将来の要件を検討するようにしてください。
さらに、ソフトウェア開発ライフサイクル（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)機能を使って一貫性のある企業IDを使うことをお勧めします。
### ベストプラクティス
組織内にAuth0を使用するグループが他にもあるケースがあります。弊社の顧客の中には、ユーザーコミュニティ別に個別の部署を設けてサービスを提供している会社も少なくありません。こういった要素を早い段階で特定して意思決定に反映させれば、後でコストが生じるような判断を防ぐことができます。
## テナントプロビジョニング
すべてはAuth0テナントから始まります。ここで、Auth0の使用方法を構成し、[アプリケーション](/docs/ja-jp/get-started/applications)や[接続](/docs/ja-jp/connections)、[ユーザープロファイル](/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テナントを作成できるため、さまざまなユーザードメインを分離し、[ソフトウェア開発ライフサイクル](#sdlc-support)（SDLC）をサポートする方法でテナントを構成できます。
テナント名は、変更できず、削除したものを再利用することもできません。Auth0テナントを作成する前に慎重に名前を決めてください。
ユーザードメインに関して必要な分離レベルを決定することは重要なステップであり、ブランディング要件と合わせて、運用環境で必要なAuth0テナントの数を決定するのに役立ちます。運用環境で使用する各Auth0テナントに対して[SDLCをサポートするテナント](#sdlc-support)の完全なスイートを作成することが推奨されるため、管理が必要なAuth0テナントの数が急速に増加する可能性があります。したがって、運用用の複数のAuth0テナントを作成する前に慎重に検討する必要があります。最終的な決定を下す前に「[ブランディング](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/branding)」のガイダンスを参照してください。
## テナントの関連付け
[すべてのテナントがAuth0との契約上の合意に関連付けられており](/docs/ja-jp/get-started/auth0-overview/create-tenants/child-tenants)、かつ同じ機能を有していることを保証するため、すべてのテナントが自社のアカウントに関連付けられていることを確認してください。テスト用に独自のサンドボックスを作成したい開発者が他にいる場合は、それらの開発者にも同じ権限が付与されるように、お持ちのアカウントにそれらの開発者を関連付けてください。これを行うには、Auth0の担当者または[Auth0サポートセンター](https://support.auth0.com)にお問い合わせください。
## カスタムドメイン
Auth0テナントをセットアップすると、そのテナントにアクセスするためのURLの形式は`https://yourTenant.auth0.com`になります。Auth0テナントに[カスタムドメイン](/docs/ja-jp/customize/custom-domains)（バニティーURLとも呼ばれる）を提供することは、ブランディング要件をサポートするための重要な要素になるだけでなく、さらに重要なこととして、セキュリティ上の利点ももたらします。
* 一部のブラウザーではデフォルトで、[共有ドメインがない場合、iFrameでの通信が困難になります](/docs/ja-jp/troubleshoot/authentication-issues/renew-tokens-when-using-safari)。
* [バニティーURLがある場合、ドメインのフィッシング詐欺が困難になります](https://auth0.com/blog/introducing-custom-domains-preview-with-auth0/)。模倣するためにバニティーURLを作成する必要があるからです。たとえば、カスタムドメインを使用すると、独自の証明書を使用して「拡張認証」を取得できるため、フィッシングがより困難になります。
1つのAuth0テナントに許可されるカスタムドメインは1つのみです。これは、Auth0のテナントがユーザーの「ドメイン」を意図しているためです。複数のバニティーURLが必要な場合は、ユーザーのドメインが複数あるはずですので、複数のテナントを使用してください。
また、カスタムドメイン名は、これが資格情報を入力する適切な場所であるという確信をユーザーに与える必要があります。したがって、環境間で一貫したテストを確実に行うために、早い段階ですべての環境でカスタムドメインを作成することをお勧めします。**資格情報を入力するときに、疑わしいURLでないか確認するよう、ユーザーを習慣づけることが非常に重要です。**
### ベストプラクティス
Auth0テナント用のカスタムドメイン（または`CNAME`）を作成し、開発用にも1つ作成して、`CNAME`を適切に管理しているかを確認してください。たとえば、`login.mycompany.com`を`mycompany-prod.auth0.com`にマッピングする`CNAME`を作成できます。
ほとんどの場合、顧客は複数の製品またはサービスブランドにわたって認証を行うための集中型ドメインの戦略を採用したときに最も成功しています。この戦略により、ユーザーに一貫したUXが提供され、運用環境で複数のAuth0テナントを展開および維持する際の複雑さも軽減されます。異なるブランドに対して複数のドメインの使用を検討している場合は、実装を開始する前に「[ブランディング](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/branding)」のガイダンスを参照してください。
## SDLCサポート
どの会社にも何らかの形のソフトウェア開発ライフサイクル（SDLC）があり、開発プロセス全体を通じてその戦略に従うのが普通です。たとえば、アプリケーション自体をテストするのと同様の方法で、Auth0との統合をテストできる必要があります。[SDLCをサポートするためにAuth0テナントを構成](/docs/ja-jp/get-started/auth0-overview/create-tenants/set-up-multiple-environments)することが重要で、そのためのテナントレイアウトに関連するベストプラクティスに関しては、顧客が通常従う一貫したパターンがあります。
| 環境 | サンプルテナント名 | 説明 |
| ------ | -------------------------------- | ---------------- |
| 開発 | **company-dev** | 主に開発作業が行われる共有環境 |
| QA/テスト | **company-qa**または**company-uat** | 変更内容の正式なテストを行う環境 |
| 運用 | **company-prod** | 運用環境のテナント |
場合によっては、開発環境に支障を来すことなく変更をテストできるよう、1つ以上のサンドボックス（例：**company-sandbox1** 、**company-sandbox2** ）を作成することができます。これが、デプロイメントスクリプトなどをテストする場所になるかもしれません。
### ベストプラクティス
実装のプロジェクトニーズに合わせてダウンロードしてカスタマイズできる[「実装チェックリスト」](/docs/ja-jp/architecture-scenarios/checklists)も活用できます。
## プロジェクト計画ガイド
当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。
[B2C IAM Project Planning Guide](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)