テナントチェック（B2B）

このセクションでは、チェックすべきテナント内の構成を一覧にして説明します。開発中に定期的に確認し、ローンチ前には十分な時間を確保して問題点を修正できるようにしておく必要があります。

テナント環境がSDLCライフサイクルをサポートするように設定されていること、また開発、テスト、運用のテナントが明確に分離されており、ローンチ後の継続的な開発作業が運用環境に悪影響を与えないことを確認してください。

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

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

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

Auth0が運用テナントを認識するように、サポートセンターで「production」フラグを運用テナントに設定してください。

Auth0は、一般的なエラーを検出するための運用チェック機能を用意しています。この機能を実行し、レポートのエラーをローンチ前にすべて解消・軽減していることを確認する必要があります。

さらに、自動チェックができない項目についても、構成のベストプラクティスに関するアドバイスを確認してください。

ロゴの構成やサポート用のメールアドレス、サポートURLを構成する際には、Auth0が推奨するテナント設定に従い、ユーザーが問題発生時にどのようにサポートを受けられるかを明確に示すようにしてください。SSOセッションのタイムアウト設定や、運用テナントにアクセスできるダッシュボード管理者のリストも確認する必要があります。

ユーザーの対話型ワークフロー（例：ユーザーのサインアップやログイン）中に問題が発生した場合、Auth0は内部でどのような問題が起きているかを示すエラーメッセージを提供します。デフォルトのメッセージはやや難解で、特にエンドユーザーにとっては、あなたしか提供できない文脈が欠けているため、理解しづらい場合があります。そこで、エラーページをカスタマイズして、欠けている、文脈に特化した情報をエンドユーザーに直接提供することをお勧めします。エラーページをカスタマイズすることで、さらに、Auth0のブランディングの代わりに自社のブランディングを表示でき、ユーザーが次に何をすべきかに関する有益な情報を提供することも可能です。この情報には、FAQへのリンク、会社のサポートチームやヘルプデスクへの連絡方法が含まれる場合があります。

古いテナントをお持ちの場合、［Tenant Settings（テナント設定）］の［Advanced（詳細設定）］タブで、多くのレガシー機能フラグがオンになっていることがあります。このタブの［Migrations（移行）］セクションで有効になっているトグルがある場合は、使用状況を確認し、レガシー機能から移行する計画を立てる必要があります。

運用テナントにアクセスできるユーザーのリストを確認する際に、委任管理拡張機能で指定したすべてのユーザーの確認を行うようにしてください。

デフォルトでは、テナントに関連付けられたURLは、その名前と、場合によっては地域固有の識別子を含むことになります。たとえば、アメリカに拠点を置くテナントは、https://example.auth0.comのようなURLになりますが、ヨーロッパに拠点を置くテナントは、https://example.eu.auth0.comのような形式になります。カスタムドメインは、組織のブランドに一致する名前を使用することで、ユーザーに一貫したエクスペリエンスを提供する方法です。

さらにカスタムドメインの機能は、証明書管理プロセスを完全に制御できます。デフォルトでは、Auth0は標準のSSL証明書を提供しますが、カスタムドメインを設定すると、拡張検証（EV）SSL証明書などを使用してブラウザーに視覚的な手がかりを与え、訪問者にさらなる安心感を提供することができます。

一般的に、本サービスの利用者は認証に中央集中型のドメインを使用する場合に最も成功を収めています。これは、特に複数の製品やサービスブランドを提供している企業に当てはまります。中央集中型のドメインを使用することで、エンドユーザーに一貫したユーザーエクスペリエンスを提供し、Auth0内で複数の運用テナントを維持する必要を最小限に抑えることができます。

各接続設定は、「接続設定のベストプラクティス」に照らして確認する必要があります。

さらに、すべての接続が適切であり、実験的な接続が運用テナントに残されていないことを確認してください。これにより、認可されていないアクセスを防ぐことができます。

SAML接続を使用する場合、接続を構成してSAML要求に署名することがベストプラクティスです。

Auth0のユニバーサルログインページ、パスワードリセットページ、またはGuardianの多要素認証を使用する場合は、エンドユーザーに表示されるページが適切にカスタマイズされているか確認する必要があります。

ユニバーサルログインは、ユーザー認証で推奨される方法であり、ログインページの使用を中心にしています。組織のブランディング要件に合わせてログインページはカスタマイズできます。

パスワードリセットページは、ユーザーがパスワード変更機能を利用する際に使用され、ログインページと同様に、組織の特定のブランディング要件を反映するようにカスタマイズできます。

多要素認証ページは、［Universal Login Settings（ユニバーサルログイン設定）］セクションでユニバーサルログインのブランディングオプションを変更してカスタマイズすることができます。

さらなるカスタマイズが必要な場合は、HTMLコンテンツの全体をカスタマイズして、組織に固有なユーザーエクスペリエンス要件を反映させることもできます。

Auth0の認可機能を使用している場合は、認可が運用環境に適していることを確認するために、付与されている権限を再確認してください。

APIアクセストークンの有効期限設定が運用環境の各APIに適していることを再確認してください。

アプリケーションがリフレッシュトークンを要求しない場合は、これがオフになっている必要があります。

署名鍵の露出を最小化するために、APIアクセストークンの署名アルゴリズムをHS256ではなくRS256に設定することをお勧めします。

カスタムAPIがある場合は、受信するアクセストークンの検証を適切に行ってからその情報を使用していることを確認してください。

マシンツーマシンでAPIに呼び出しを行うアプリケーションがある場合は、APIに指定されているスコープを確認して、すべてが運用環境に適切であることを確認してください。詳細については、クライアント資格情報の付与に関するドキュメントをお読みください。

ルールが、Auth0が提供している「ルールのベストプラクティス」に沿っていることを確認してください。

Auth0は、ユーザー通知や、安全なID管理に必要な機能（メール検証、アカウント復旧、総当たり攻撃防御など）を提供するためにメールを幅広く利用しており、これらの用途のテンプレートも多数用意しています。

すぐに使えるこれらのメールテンプレートには、標準の文言とAuth0のブランディングが含まれています。しかし、テンプレートはほぼすべての側面を自由に構成し、最適なトーンやユーザーエクスペリエンスを反映させたり、必要な言語やアクセシビリティオプションなどを変更したりすることができます。

メールテンプレートはLiquid構文を使用してカスタマイズされます。ユーザーの好みに基づいてテンプレートをカスタマイズしたい場合は、ユーザープロファイル内のメタデータや特定のアプリケーションメタデータにもアクセスできます。

認証システムが重要な理由は、悪意のある行為者が権限のないアプリケーションやユーザーデータにアクセスすることを防ぐためです。我々は、悪意のある行為者とシステムへのアクセスの間に、できる限り多くの障壁を配備したいと考えます。最も簡単な方法は、Auth0で攻撃防御を確実に正しく構成することです。そのためにも、このトピックに関するガイダンスを注意して読み、正しく動作していることを確認してください。

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