一般テナントチェック
テナント準備チェック
テナント環境がSDLCライフサイクルをサポートするように設定されていること、また開発、テスト、運用のテナントが明確に分離されており、ローンチ後の継続的な開発作業が運用環境に悪影響を与えないことを確認してください。 どの会社にも何らかの形のソフトウェア開発ライフサイクル（SDLC）があり、開発プロセス全体を通じてその戦略に沿って進める必要があります。たとえば、アプリケーション自体をテストするのと同様の方法で、Auth0との統合をテストできる必要があります。したがって、SDLCをサポートするようにAuth0テナントを構築することが重要です。そのためのテナントレイアウトに関連するベストプラクティスとして、通常、弊社のお客様は以下のような一貫したパターンに従います。| 環境 | サンプルテナント名 | 説明 |
|---|---|---|
| 開発 | company-dev | 主に開発作業が行われる共有環境 |
| QA/テスト | company-qaまたはcompany-uat | 変更内容の正式なテストを行う環境 |
| 運用 | company-prod | 運用環境のテナント |
ベストプラクティス
実装のプロジェクトニーズに合わせてダウンロードしてカスタマイズできる「実装チェックリスト」も活用できます。テナントの関連付けチェック
お客様のテナントがすべてAuth0の契約に基づいており、同じ機能を持つことを確認するために、すべてのテナントが会社のアカウントに関連付けられていることを確認してください。テスト用に独自のサンドボックスを作成したい開発者が他にいる場合は、それらの開発者にも同じ権限が付与されるように、お持ちのアカウントにそれらの開発者を関連付けてください。これを行うには、Auth0の担当者またはAuth0サポートセンターにご連絡ください。運用テナントを指定する
Auth0が運用テナントを認識するように、サポートセンターで「production」フラグを運用テナントに設定してください。テナントの運用チェック
Auth0は、一般的なエラーを検出するための運用チェック機能を用意しています。この機能を実行し、レポートのエラーをローンチ前にすべて解消・軽減していることを確認する必要があります。 さらに、自動チェックができない項目についても、構成のベストプラクティスに関するアドバイスを確認してください。テナント設定のチェック
テナント設定
ロゴの構成やサポート用のメールアドレス、サポートURLを構成する際には、Auth0が推奨するテナント設定に従い、ユーザーが問題発生時にどのようにサポートを受けられるかを明確に示すようにしてください。セッションのタイムアウト設定や、運用テナントにアクセスできるダッシュボード管理者のリストも確認する必要があります。エラーページのカスタマイズ
ユーザーの対話型ワークフロー（例：ユーザーのサインアップやログイン）中に問題が発生した場合、Auth0は内部でどのような問題が起きているかを示すエラーメッセージを提供します。デフォルトのメッセージはやや難解で、特にエンドユーザーにとっては、あなたしか提供できない文脈が欠けているため、理解しづらい場合があります。そこで、エラーページをカスタマイズして、欠けている、文脈に特化した情報をエンドユーザーに直接提供することをお勧めします。エラーページをカスタマイズすることで、さらに、Auth0のブランディングの代わりに自社のブランディングを表示でき、ユーザーが次に何をすべきかに関する有益な情報を提供することも可能です。この情報には、FAQへのリンク、会社のサポートチームやヘルプデスクへの連絡方法が含まれる場合があります。ベストプラクティス
最初は、Auth0提供のエラーページをカスタマイズするユーザーインターフェイスはありませんが、「Management APIのテナント設定エンドポイント」を使用して、構成することができます。または、独自のエラーページを作成してホストできる場合、Auth0がホストするオプションを使用する代わりに、そのページにユーザーをリダイレクトすることも可能です。レガシー機能フラグのチェックと移行
古いテナントをお持ちの場合、［Tenant Settings（テナント設定）］の［Advanced（詳細設定）］タブで、多くのレガシー機能フラグがオンになっていることがあります。このタブの［Migrations（移行）］セクションで有効になっているトグルがある場合は、使用状況を確認し、レガシー機能から移行する計画を立てる必要があります。委任管理拡張機能
運用テナントにアクセスできるユーザーのリストを確認する際に、委任管理拡張機能で指定したすべてのユーザーの確認を行うようにしてください。カスタムドメイン名のセットアップ
デフォルトでは、テナントに関連付けられたURLは、その名前と、場合によっては地域固有の識別子を含むことになります。たとえば、アメリカに拠点を置くテナントは、https://example.auth0.comのようなURLになりますが、ヨーロッパに拠点を置くテナントは、https://example.eu.auth0.comのような形式になります。カスタムドメインは、組織のブランドに一致する名前を使用することで、ユーザーに一貫したエクスペリエンスを提供する方法です。
Auth0テナントでは、それぞれ1つのカスタムドメイン名しか適用できません。そのため、独立したドメイン名のブランディングがどうしても必要な場合は、運用環境に複数のAuth0テナントをデプロイしたアーキテクチャが必要となります。
アプリケーションと接続設定のチェック
各接続設定は、「接続設定のベストプラクティス」に照らして確認する必要があります。 さらに、すべての接続が適切であり、実験的な接続が運用テナントに残されていないことを確認してください。これにより、認可されていないアクセスを防ぐことができます。 接続を使用する場合、接続を構成してSAML要求に署名することがベストプラクティスです。ページカスタマイズのチェック
Auth0のユニバーサルログインページ、パスワードリセットページ、またはGuardianの多要素認証を使用する場合は、エンドユーザーに表示されるページが適切にカスタマイズされているか確認する必要があります。ユニバーサルログインページ
ユニバーサルログインは、ユーザー認証で推奨される方法であり、ログインページの使用を中心にしています。組織のブランディング要件に合わせてログインページはカスタマイズできます。ベストプラクティス
ユニバーサルログインをカスタマイズするには、 ページテーマの変更と、動的なページテンプレートの作成が可能です。クラシックログインを実装しつつログインのページスクリプトをカスタマイズする場合は、バージョンコントロールを行うことを強くお勧めします。この作業に伴うAuth0テナントでのスクリプトのデプロイは、デプロイメントの自動化または代わりのストラテジーのいずれかを経由して行ってください。パスワードリセットページ
パスワードリセットページは、ユーザーがパスワード変更機能を利用する際に使用され、ログインページと同様に、組織の特定のブランディング要件を反映するようにカスタマイズできます。Guardian
多要素認証ページは、［Universal Login Settings（ユニバーサルログイン設定）］セクションでユニバーサルログインのブランディングオプションを変更してカスタマイズすることができます。 さらなるカスタマイズが必要な場合は、HTMLコンテンツの全体をカスタマイズして、組織に固有なユーザーエクスペリエンス要件を反映させることもできます。認可のチェック
Auth0の認可機能を使用している場合は、認可が運用環境に適していることを確認するために、付与されている権限を再確認してください。API構成のチェック
アクセストークンの有効期限
APIアクセストークンの有効期限設定が運用環境の各APIに適していることを再確認してください。APIのオフラインアクセス
アプリケーションがリフレッシュトークンを要求しない場合は、これがオフになっている必要があります。アクセストークンの署名アルゴリズム
署名鍵の露出を最小化するために、APIアクセストークンの署名アルゴリズムをHS256ではなくRS256に設定することをお勧めします。APIアクセストークンの検証
カスタムAPIがある場合は、受信するアクセストークンの検証を適切に行ってからその情報を使用していることを確認してください。APIスコープ
マシンツーマシンでAPIに呼び出しを行うアプリケーションがある場合は、APIに指定されているスコープを確認して、すべてが運用環境に適切であることを確認してください。詳細については、クライアント資格情報の付与に関するドキュメントをお読みください。ルール/フックのチェック
ルールが、Auth0が提供している「ルールのベストプラクティス」に沿っていることを確認してください。メールテンプレートのカスタマイズ
Auth0は、ユーザー通知や、安全なID管理に必要な機能（メール検証、アカウント復旧、総当たり攻撃防御など）を提供するためにメールを幅広く利用しており、これらの用途のテンプレートも多数用意しています。メールテンプレートをカスタマイズする前に、メールプロバイダーをセットアップしてください。