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

​
一般テナントチェック

​
テナント準備チェック

テナント環境がSDLCライフサイクルをサポートするように設定されていること、また開発、テスト、運用のテナントが明確に分離されており、ローンチ後の継続的な開発作業が運用環境に悪影響を与えないことを確認してください。 どの会社にも何らかの形のソフトウェア開発ライフサイクル（SDLC）があり、開発プロセス全体を通じてその戦略に沿って進める必要があります。たとえば、アプリケーション自体をテストするのと同様の方法で、Auth0との統合をテストできる必要があります。したがって、SDLCをサポートするようにAuth0テナントを構築することが重要です。そのためのテナントレイアウトに関連するベストプラクティスとして、通常、弊社のお客様は以下のような一貫したパターンに従います。
環境サンプルテナント名説明
開発company-dev主に開発作業が行われる共有環境
QA/テストcompany-qaまたはcompany-uat変更内容の正式なテストを行う環境
運用company-prod運用環境のテナント
場合によっては、変更をテストするために複数のサンドボックス（例：［company-sandbox1］ 、［company-sandbox2］ ）を作成することも考えられます。これにより、運用環境を損なうことなくテストを行うことができます。これが、デプロイメントスクリプトなどをテストする場所になるかもしれません。

​
ベストプラクティス

実装のプロジェクトニーズに合わせてダウンロードしてカスタマイズできる「実装チェックリスト」も活用できます。

​
テナントの関連付けチェック

お客様のテナントがすべて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テナントをデプロイしたアーキテクチャが必要となります。
さらにカスタムドメインの機能は、証明書管理プロセスを完全に制御できます。デフォルトでは、Auth0は標準のSSL証明書を提供しますが、カスタムドメインを設定すると、拡張検証（EV）SSL証明書などを使用してブラウザーに視覚的な手がかりを与え、訪問者にさらなる安心感を提供することができます。 一般的に、本サービスの利用者は認証に中央集中型のドメインを使用する場合に最も成功を収めています。これは、特に複数の製品やサービスブランドを提供している企業に当てはまります。中央集中型のドメインを使用することで、エンドユーザーに一貫したユーザーエクスペリエンスを提供し、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管理に必要な機能（メール検証、アカウント復旧、総当たり攻撃防御など）を提供するためにメールを幅広く利用しており、これらの用途のテンプレートも多数用意しています。
メールテンプレートをカスタマイズする前に、メールプロバイダーをセットアップしてください。
すぐに使えるこれらのメールテンプレートには、標準の文言とAuth0のブランディングが含まれています。しかし、テンプレートはほぼすべての側面を自由に構成し、最適なトーンやユーザーエクスペリエンスを反映させたり、必要な言語やアクセシビリティオプションなどを変更したりすることができます。 メールテンプレートはLiquid構文を使用してカスタマイズされます。ユーザーの好みに基づいてテンプレートをカスタマイズしたい場合は、ユーザープロファイル内のメタデータや特定のアプリケーションメタデータにもアクセスできます。

​
攻撃防御の構成

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

​
ベストプラクティス

Auth0では異常の検出を水面下で行っており、お客様の製品に優れた安全機能を提供しています。この機能を活用するには、ユーザーへのメール配信を開始する前に、メールプロバイダーのセットアップと、メールテンプレートの構成を行ってください。

​
プロジェクト計画ガイド

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