テナントチェック（B2C）

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

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

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

場合によっては、開発環境に支障を来すことなく変更をテストできるよう、1つ以上のサンドボックス（例：company-sandbox1、company-sandbox2）を作成することができます。これが、デプロイメントスクリプトなどをテストする場所になるかもしれません。

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

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

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

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

問題が発生した場合にユーザーがサポートを受ける方法を知ることができるように、URLブランディング、サポートメール、サポートを構成する際には、Auth0テナント設定の推奨事項に必ず従ってください。SSOセッションのタイムアウト設定や、運用テナントにアクセスできるダッシュボード管理者のリストも確認する必要があります。

インタラクティブなワークフロー（ユーザーサインアップやログインなど）中に問題が発生した場合は、内部の問題を示したエラーメッセージが表示されます。既定のメッセージは、とりわけエンドユーザーにとっては、やや不可解なものです。これは、貴社だけが提供できるコンテキストが不足している可能性があるためです。そのため、不足しているコンテキスト固有の情報をユーザーに直接提供するように、エラーページをカスタマイズすることを推奨します。加えて、エラーメッセージをカスタマイズすると、Auth0でなく貴社のブランディングを表示できるほか、次に実行すべき操作に関して、ユーザーに有益な情報を提供することができます。この情報には、FAQへのリンク、会社のサポートチームやヘルプデスクへの連絡方法などが含まれます。

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

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

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

さらに、カスタムドメイン機能を使用することで、証明書管理プロセスを完全に掌握することができます。デフォルトで、Auth0は標準SSL証明書を発行しますが、カスタムドメインを構成する場合は、拡張検証（EV）SSL証明書またはそれに類似するものを使用して、ブラウザーベースの視覚的合図を出します。これによって、訪問者にさらなる安心感を与えてくれます。

一般に、認証に集中型ドメインを使用すると、顧客満足度が一番高くなります。これは、会社が複数の製品またはサービスブランドを提供する場合に特に言えることです。中央集中型のドメインを使用することで、エンドユーザーに一貫したユーザーエクスペリエンスを提供し、Auth0内で複数の運用テナントを維持する必要を最小限に抑えることができます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そのまま使えるメールテンプレートには、標準的な言い回しとAuth0のブランディングが含まれています。しかし、希望する言い回しやユーザーエクスペリエンスを反映するように、これらのテンプレートのほぼすべての側面を構成し、優先的に使用する言語やアクセシビリティオプションなどの項目に変更を加えることができます。

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

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

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