ベストプラクティス
複数のアプリケーションがあって、SSOを活用する必要がある場合、次に進む前に「シングルサインオンの実装方法」のトレーニングガイダンスを確認することをお勧めします。- Auth0がユーザーにWebページを表示する必要がある場合、URLはどのようなものであるべきか。
- SDLC（ソフトウェア開発ライフサイクル）をサポートするには、Auth0をどのように構成すればよいか。
- Auth0テナントが契約に適切に関連付けられていることを確認するにはどうすればよいか。
- 組織内にAuth0と統合する他のプロジェクトがある場合、何を考慮すればよいか。特に、自身のドメイン、または別のドメインのユーザーを対象としたプロジェクト（たとえば、従業員だけが使用するアプリケーション）です。
- 顧客の組織の構造やドメインをAuth0のデプロイメントに対してどのように合わせることができるか。
ベストプラクティス
たとえば、会社に、顧客、パートナー、従業員といった複数のユーザーグループに対応するためのID要件があることは、珍しいことではありません。アーキテクチャを設計する際に別のプロジェクトまたは将来の要件を検討するようにしてください。ベストプラクティス
組織内にAuth0を使用するグループが他にもあるケースがあります。弊社の顧客の中には、ユーザーコミュニティ別に個別の部署を設けてサービスを提供している会社も少なくありません。こういった要素を早い段階で特定して意思決定に反映させれば、後でコストが生じるような判断を防ぐことができます。テナントプロビジョニング
すべてはAuth0テナントから始まります。ここはAuth0の使用を構成する場所であり、アプリケーションや接続、ユーザープロファイルなどのアセットが定義、管理、保存される場所です。Auth0テナントへのアクセスはAuth0 Dashboardを通じて行われ、Dashboardを通じて追加の関連テナントを作成することもできます。複数のAuth0テナントを作成できるため、さまざまなユーザードメインを分離し、Software Development Life Cycle（ソフトウェア開発ライフサイクル）（SDLC）のサポートもします。テナント名は、変更できず、削除したものを再利用することもできません。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を作成する必要があるため、ドメインのフィッシング詐欺が難しくなります。たとえば、カスタムドメインを使用すると、独自の証明書を使用して「拡張認証」を取得できるため、フィッシングがより困難になります。
1つのAuth0テナントに許可されるカスタムドメインは1つのみです。これは、Auth0のテナントがユーザーの「ドメイン」を意図しているためです。複数のバニティーURLが必要な場合は、ユーザーのドメインが複数あるはずですので、複数のテナントを使用してください。
ベストプラクティス
Auth0テナント用のカスタムドメイン（またはCNAME）を作成し、開発用にも1つ作成して、CNAMEを適切に管理しているかを確認してください。たとえば、login.mycompany.comをmycompany-prod.auth0.comにマッピングするCNAMEを作成できます。SDLCサポート
どの会社にも何らかの形のソフトウェア開発ライフサイクル（SDLC）があり、開発プロセス全体を通じてその戦略に従うのが普通です。たとえば、アプリケーション自体をテストするのと同様の方法で、Auth0との統合をテストできる必要があります。したがって、SDLCをサポートするためにAuth0テナントを構築することが重要です。そのためのテナントレイアウトに関連するベストプラクティスに関しては、顧客が通常従う一貫したパターンがあります。| 環境 | サンプルテナント名 | 説明 |
|---|---|---|
| 開発 | company-dev | 主に開発作業が行われる共有環境 |
| QA/テスト | company-qaまたはcompany-uat | 変更内容の正式なテストを行う環境 |
| 運用 | company-prod | 運用環境のテナント |
ベストプラクティス
実装のプロジェクトニーズに合わせてダウンロードしてカスタマイズできる「実装チェックリスト」も活用できます。エンタープライズサブスクリプションをご利用の場合は、SDLCをサポートするテナントのセットアップが正しくサブスクリプションにリンクされていることを確認してください。そうすれば、各テナントで一貫して同じ機能セットが有効化されます。