アーキテクチャ（B2B）

アプリケーションを理解することは、ニーズを満たすためにAuth0をどのように活用できるかを理解する上で重要な鍵となります。経験上、当社で最も成功しているお客様は、提案された（または多くの場合、既存の）アーキテクチャの視覚化から開始し、これを作業を進める際の参照の基礎としています。アプリケーションが組織内でどの位置付けにあるかを理解することも重要です。Auth0のアカウントとテナントは、Auth0資産のグループ化と構造化の基盤を形成しており、シングルサインオン（SSO）、集中管理されたユーザープロファイル管理、統合された請求などと統合するために、既存のAuth0導入を活用する必要がある場合があります。

アーキテクチャのランドスケープに事前に時間を投資すれば、長期的に見て利益をもたらすことがわかっています。また、機能やワークフローを検討する際には、考慮すべきことが数多くあります。

• Auth0がユーザーにWebページを表示する必要がある場合、URLはどのようなものであるべきか。

• SDLC（ソフトウェア開発ライフサイクル）をサポートするには、Auth0をどのように構成すればよいか。

• Auth0テナントが契約に適切に関連付けられていることを確認するにはどうすればよいか。

• 組織内にAuth0と統合する他のプロジェクトがある場合、何を考慮すればよいか。特に、自身のドメイン、または別のドメインのユーザーを対象としたプロジェクト（たとえば、従業員だけが使用するアプリケーション）です。

• 顧客の組織の構造やドメインをAuth0のデプロイメントに対してどのように合わせることができるか。

多くの場合、組織は複数のドメインのユーザーにサービスを提供します。顧客、従業員、関連会社が最も頻繁に利用しますが、通常、交差することはほぼありません。たとえば、従業員が顧客と同じアプリケーションを使用することはなく、その逆も同様です。場合によっては、ドメイン内をさらに分割する必要がある場合もあります。たとえば、接続されていない異なる製品を使用する顧客をグループに分ける場合などです。Auth0は、ユーザーと関連するコラテラルを分離する方法を提供しており、これについては、「テナントプロビジョニング」でさらに詳しく記載されています。独立したテナントをプロビジョニングする必要がある場合、既存のAuth0アカウントにそのテナントを関連付けることで、組織の契約しているサブスクリプションレベルの利点を最大限に活用することができます。

さらに、ソフトウェア開発ライフサイクル（SDLC）の一部として、一連のプロセスと手順を確立することはおそらく間違いないでしょう。そのため、Auth0テナントのプロビジョニングに関するSDLCサポートガイダンスも確認することをお勧めします。

顧客向けアプリケーションでは、一般的にOpenID Connect（OIDC）が最も頻繁に使用されるプロトコルです。OIDCは、ユーザーに対して表示されるブラウザーURLを使ったWebベースのワークフローを利用します。Auth0 OIDCサポートの一環としてそのまま使えるクライアント向けのURLはAuth0のブランディングになっていますが、ユーザーの懸念を生じさせないために、Auth0のカスタムドメイン機能を使って会社のブランディングに統一させることをお勧めします。

顧客組織の一部またはすべてが独自のカスタムURLを必要とする場合、または組織のブランド化されたカスタム同意ページが必要なソーシャルプロバイダーを使用している場合は、それらの組織に対して個別のAuth0テナントを作成することをお勧めします。詳細については、「複雑な組織向けのテナントプロビジョニング」をご覧ください。

すべてはAuth0テナントから始まります。ここはAuth0の使用を構成する場所であり、アプリケーションや接続、ユーザープロファイルなどのアセットが定義、管理、保存される場所です。Auth0テナントへのアクセスはAuth0 Dashboardを通じて行われ、Dashboardを通じて追加の関連テナントを作成することもできます。複数のAuth0テナントを作成できるため、さまざまなユーザードメインを分離し、Software Development Life Cycle（ソフトウェア開発ライフサイクル）（SDLC）のサポートもします。

ユーザードメインに関して必要な分離レベルを決定することは重要なステップであり、ブランディング要件と合わせて、運用環境で必要なAuth0テナントの数を決定するのに役立ちます。SDLCがサポートするテナントの完全なスイートを作成することを推奨しています。そのため、管理する必要のあるAuth0テナントの数が急速に増加する可能性があります。したがって、運用のための複数のAuth0テナントを作成する前に慎重に検討する必要があります。また、最終的な決定を下す前に「ブランディング」をご確認ください。

ほとんどの場合、顧客の組織に個別のAuth0テナントをプロビジョニングする必要はありません。新しいOrganization機能の導入により、これはさらに簡単になりました。ただし、特定の状況では、これはセットアップの複雑さを軽減するのに役立つ場合があります。たとえば、次の場合には、ベストプラクティスとして顧客の組織に別のAuth0テナントをプロビジョニングすることをお勧めします。

• 顧客組織に、組織に固有のカスタムログインURLが必要な場合。これは通常、組織が共通のログインURLを使用する代わりに独自のバニティーURLを持つことを許可している場合にのみ当てはまります。Auth0は、1つのテナントにつき1つのカスタムドメインをサポートします。

• 顧客組織がログインにソーシャルプロバイダーを使用する場合。この場合、組織は、組織のブランド化されたソーシャルプロバイダー用のカスタム同意ページを持つことが望ましいとされることが多いです。

以上のどちらかの状況に該当する場合は、上記の基準に当てはまる組織ごとに個別のAuth0テナントを作成することをお勧めします。

お客様のテナントがすべてAuth0の契約に基づいており、同じ機能を持つことを確認するために、すべてのテナントを会社のアカウントに関連付けてください。テスト用に独自のサンドボックスを作成したい開発者が他にいる場合は、それらの開発者にも同じ権限が付与されるように、お持ちのアカウントにそれらの開発者を関連付けてください。これを行うには、Auth0の担当者またはAuth0サポートセンターにご連絡ください。

Auth0テナントをセットアップすると、そのテナントにアクセスするためのURLの形式はhttps://{yourTenant}.auth0.comになります。カスタムドメイン（バニティーURLとも呼ばれる）を提供することは、ブランディング要件をサポートするための重要な要素になるだけでなく、さらに重要なこととして、セキュリティ上の利点ももたらします。

• 一部のブラウザーでは、デフォルトで、共有ドメインがない場合、デフォルトでiFrameでの通信が困難になります。

• バニティーURLがある場合、URLを模倣するにはバニティーURLを作成する必要があるため、ドメインのフィッシング詐欺が難しくなります。たとえば、カスタムドメインを使用すると、独自の証明書を使用して「拡張認証」を取得できるため、フィッシングがより困難になります。

また、カスタムドメイン名は、これが資格情報を入力する適切な場所であるという確信をユーザーに与える必要があります。したがって、環境間で一貫したテストを確実に行うために、早い段階ですべての環境でカスタムドメインを作成することをお勧めします。資格情報を入力するときに、疑わしいURLを探すようにユーザーをトレーニングすることが非常に重要です。

ほとんどの場合、顧客は複数の製品またはサービスブランドにわたって認証を行うための集中型ドメインの戦略を採用したときに最も成功しています。この戦略により、ユーザーに一貫したUXが提供され、運用環境で複数のAuth0テナントを展開および維持する際の複雑さも軽減されます。異なるブランドに対して複数のドメインの使用を検討している場合は、実装を開始する前に「ブランディング」のガイダンスをご参照ください。

どの会社にも何らかの形のソフトウェア開発ライフサイクル（SDLC）があり、開発プロセス全体を通じてその戦略に従うのが普通です。たとえば、アプリケーション自体をテストするのと同様の方法で、Auth0との統合をテストできる必要があります。したがって、SDLCをサポートするためにAuth0テナントを構築することが重要です。そのためのテナントレイアウトに関連するベストプラクティスに関しては、顧客が通常従う一貫したパターンがあります。

場合によっては、変更をテストするために複数のsandbox（例：company-sandbox1、company-sandbox2）を作成することも考えられます。これにより、運用環境を損なうことなくテストを行うことができます。これが、デプロイメントスクリプトなどをテストする場所になるかもしれません。

当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。

B2Bプラットフォームの多くが顧客のOrganizationを何らかの形で分離・ブランディングし、これがIDおよびアクセス管理（IAM）システムをさらに複雑にしています。この問題でお困りであれば、当社がそのような環境に合ったガイダンスとベストプラクティスをご紹介していますので、時間を割いてお読みになることをお勧めします。

複数Organizationアーキテクチャ