一般的なテナントの確認
テナント準備チェック
ソフトウェア開発ライフサイクルを支えられるようにテナント環境が設定されており、Dev、Test、Prod の各テナントが明確に分離されていることを確認してください。こうすることで、ローンチ後も続く開発作業が本番環境に悪影響を及ぼすのを防げます。 どの企業にも何らかの形のソフトウェア開発ライフサイクル (SDLC) があり、開発プロセス全体を通じてその進め方に合わせる必要があります。たとえば、アプリケーション自体をテストするのと同じように、Auth0 との連携もテストできるようにしておく必要があります。そのため、SDLC を支えられるように Auth0 テナントを構成することが重要です。これを実現するためのテナント構成については、ベストプラクティスとして多くのお客様が採用している一般的なパターンがあります。
場合によっては、開発環境に影響を与えずに変更をテストできるよう、1 つ以上のサンドボックス (例: company-sandbox1、company-sandbox2) を作成することもあります。ここでは、デプロイスクリプトなどをテストできます。
テナントの関連付けの確認
すべてのテナントが Auth0 の契約に関連付けられ、同じ機能を利用できるようにするには、すべてのテナントが会社アカウントに関連付けられていることを確認してください。テスト用に各開発者が独自のサンドボックスを作成する場合も、同じ権限を利用できるよう、そのテナントが自社アカウントに関連付けられるようにしてください。これを行うには、Auth0 の担当者または Auth0 Support Center にお問い合わせください。本番テナントを指定する
Auth0 が 本番テナントを認識できるようにするには、Support Center で「production」フラグを設定して、必ず 本番テナントを設定 してください。テナント本番チェック
Auth0 には、多くの一般的なエラーを検出するための本番チェック機能があります。ローンチ前に、これが実行されており、レポートで指摘された事項にすべて対処されていることを確認してください。 さらに、自動では確認できないベストプラクティスの設定に関するアドバイスも確認する必要があります。テナント設定の確認
テナント設定
問題が発生した際にユーザーがサポートの受け方をすぐに分かるよう、ブランディング、サポートメール、サポート URL を設定する際は、Auth0 の テナント設定 の推奨事項に必ず従ってください。あわせて、 セッションのタイムアウト設定と、本番テナントにアクセスできるダッシュボード管理者の一覧も確認しておくとよいでしょう。エラーページのカスタマイズ
ユーザーによる対話型ワークフロー (たとえば、ユーザー登録やログイン) の途中で問題が発生すると、Auth0 は内部的に何が問題なのかを示すエラーメッセージを表示します。既定のメッセージはやや分かりにくく、特にエンドユーザーにとっては難解になりがちです。というのも、そこには通常、あなたしか補えないコンテキストが欠けているからです。そのため、不足している状況に応じた情報をユーザーに直接伝えられるよう、エラーページをカスタマイズすることをお勧めします。さらに、エラーページをカスタマイズすれば、Auth0 ではなく自社のブランディングを表示できるほか、次に何をすべきかについて役立つ情報もユーザーに提供できます。たとえば、FAQ へのリンクや、自社のサポートチームまたはヘルプデスクへの連絡方法などを含めることができます。レガシー機能フラグをオフにする
以前からあるテナントをご利用の場合は、テナント設定のAdvancedタブで、さまざまなレガシー機能フラグが有効になっていることがあります。このタブの「Migrations」セクションでいずれかのトグルがオンになっている場合は、利用状況を確認し、レガシー機能から移行する計画を立ててください。Delegated Admin Extension
本番テナントにアクセスできるユーザーの一覧を確認する際は、Delegated Admin Extension で指定されたユーザーも忘れずに確認してください。カスタムドメイン名の設定
デフォルトでは、テナントに関連付けられた URL には、その名前と、場合によってはリージョン固有の識別子が含まれます。たとえば、米国のテナントの URL はhttps://example.auth0.com のようになり、ヨーロッパのテナントでは https://example.eu.auth0.com のようになります。カスタムドメイン を使用すると、自社ブランドに合った名前を使って、ユーザーに一貫した体験を提供できます。
さらに、 機能を使うと、証明書管理プロセスを完全に制御できます。デフォルトでは Auth0 が標準の SSL 証明書を提供しますが、カスタムドメインを設定すると、Extended Validation (EV) SSL 証明書などを使用して、訪問者により大きな安心感を与えるブラウザベースの視覚的な संकेतを提供できます。
一般に、認証には一元化されたドメインを使用しているお客様が最も高い成果を上げています。これは特に、その企業が複数の製品やサービスブランドを提供している場合に当てはまります。一元化されたドメインを使用することで、エンドユーザーに一貫したユーザー体験を提供できるだけでなく、Auth0 で複数の本番テナントを維持する必要性も最小限に抑えられます。
アプリケーションと接続の設定の確認
各接続の設定は、接続設定のベストプラクティスに照らして確認してください。 また、すべての接続が適切なものであること、および試験用の接続が本番テナントに残っていないことも確認してください。そうした接続があると、不正アクセスを許してしまうおそれがあります。 接続を使用している場合は、SAMLリクエストに署名するよう接続を設定しておくことがベストプラクティスです。ページのカスタマイズ確認
Auth0 の ページ、パスワードリセットページ、または Guardian の を使用している場合は、エンドユーザーに表示されるページが適切にカスタマイズされているか確認してください。Universal Login ページ
Universal Login は、ユーザーを認証するための推奨される方法であり、その中心となるのが Login ページです。Login ページは、組織のブランド要件に合わせてカスタマイズできます。パスワードリセットページ
Password Resetページは、ユーザーがパスワード変更機能を利用する際に使用されます。ログインページと同様に、組織固有のブランド要件を反映するようカスタマイズできます。Guardian
多要素認証のページは、Universal Login Settings セクションで Universal Login のブランディングオプションを調整することでカスタマイズできます。 さらにカスタマイズが必要な場合は、organization 固有の UX 要件を反映するために、HTML コンテンツ全体 をカスタマイズすることもできます。認可の確認
Auth0の認可機能を使用している場合は、付与されているすべての権限を必ず見直し、本番環境に適した認可設定になっていることを確認してください。API設定の確認
アクセストークンの有効期限
本番環境の各APIに適した設定になっていることを確認するため、APIアクセストークンの有効期限設定を必ず再確認してください。API オフラインアクセス
ご利用のアプリケーションでを要求しない場合は、これをオフにしてください。アクセストークンの署名アルゴリズム
署名鍵の露出を最小限に抑えるため、API アクセストークンの署名アルゴリズムは、HS256 ではなく RS256 に設定することを推奨します。API アクセストークンのバリデーション
カスタム API がある場合は、その中の情報を利用する前に、受け取った アクセストークンを適切にバリデーション していることを必ず確認してください。API スコープ
いずれかの API に対して machine-to-machine 通信を行うアプリケーションがある場合は、API に指定されたスコープを見直し、本番環境に適したものになっているかどうかを確認してください。詳しくは、クライアントクレデンシャルグラント に関するドキュメントを参照してください。メールテンプレートをカスタマイズ
Auth0 では、ユーザーへの通知だけでなく、安全なアイデンティティ管理に必要な機能 (たとえば、メールアドレスの確認、アカウント復旧、ブルートフォース対策) にもメールが幅広く使われており、そのためのテンプレートが多数用意されています。メールテンプレートをカスタマイズする前に、メールプロバイダーを設定してください。