Tenant Check（B2B）

B2B IAM 実装のローンチ前に実施すべき Tenant Check。

このセクションでは、テナント内で確認すべき設定項目を一覧で紹介します。これらの確認は、開発中に定期的に行うとともに、不備があった場合に修正の時間を確保できるよう、ローンチより十分前に実施してください。

​

一般的なテナント確認

​

テナント準備チェック

SDLC ライフサイクルを支えるテナント環境が適切に設定されていること、また Dev、Test、Prod の各テナントが明確に分離されていることを確認してください。これにより、リリース後も継続する開発作業が本番環境に悪影響を及ぼすのを防げます。

どの企業にも何らかの形で Software Development Life Cycle (SDLC) があり、開発プロセス全体を通してその戦略に沿う必要があります。たとえば、アプリケーション自体をテストするのと同じように、Auth0 との統合もテストできる必要があります。そのため、SDLC を支えられるように Auth0 テナントを構成することが重要です。このためのテナント構成に関するベストプラクティスとして、多くのお客様は通常、次のような一貫したパターンを採用しています。

Environment	Sample Tenant Name	Description
開発	company-dev	開発作業の大半を行う共有環境
QA/テスト	company-qa or company-uat	加えた変更を正式にテストするための環境
本番	company-prod	本番テナント

場合によっては、開発環境に影響を与えずに変更をテストできるよう、1 つ以上のサンドボックス (例: company-sandbox1、company-sandbox2) を作成することもあります。ここでは、デプロイスクリプトなどをテストできます。

​

ベストプラクティス

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

​

テナントの関連付けの確認

すべてのテナントが Auth0 との契約にひも付けられ、同じ機能を利用できるようにするため、すべてのテナントが貴社のアカウントに関連付けられていることを確認してください。各開発者がテスト用に独自のサンドボックスを作成する場合も、同じ権限を持てるよう、必ず貴社のアカウントに関連付けてもらってください。これを行うには、Auth0 の担当者または Auth0 Support Center にお問い合わせください。

​

本番テナントを指定する

Auth0 が本番テナントを正しく認識できるよう、Support Center で 本番テナントを設定 し、「production」フラグを付けてください。

​

テナントの本番環境チェック

Auth0 には、多くの一般的な問題を検出するための Production Check 機能があります。リリース前にこれを実行し、レポートで指摘された項目に対して必要な対策を講じておくようにしてください。

さらに、自動では確認できない項目については、ベストプラクティスに沿った設定に関するガイダンス も確認してください。

​

テナント設定の確認

​

テナント設定

問題が発生したときにユーザーがサポートを受ける方法を把握できるよう、ロゴ、サポート用メールアドレス、サポート URL の設定にあたっては、Auth0 の テナント設定 の推奨事項に必ず従ってください。あわせて、SSO のセッションタイムアウト設定と、本番テナントにアクセスできるダッシュボード管理者の一覧も確認しておきましょう。

​

エラーページのカスタマイズ

ユーザーによる対話型ワークフロー (例: ユーザー登録やログイン) の途中で問題が発生した場合、Auth0 は内部的な原因を示すエラーメッセージを表示します。デフォルトのメッセージはやや分かりにくく、特にエンドユーザーにとっては、あなたにしか補えない文脈情報が欠けていることが多いため、なおさらです。そのため、不足しているコンテキスト固有の情報をユーザーに直接提供できるよう、エラーページをカスタマイズすることをおすすめします。さらに、エラーページをカスタマイズすると、Auth0 ではなく自社のブランドを表示できるほか、次に何をすべきかについて役立つ情報をユーザーに提供できます。たとえば、FAQ へのリンクや、自社のサポートチームまたはヘルプデスクへの問い合わせ方法などを含めることができます。

​

ベストプラクティス

Auth0 が提供するエラーページをカスタマイズするためのユーザーインターフェースは標準では用意されていませんが、設定には Management API の Tenant Settings エンドポイント を使用できます。あるいは、独自のエラーページを作成してホストできる場合は、Auth0 がホストするページの代わりに、そのページへユーザーをリダイレクトするよう Auth0 を設定することもできます。

​

レガシー機能フラグをオフにする

古いテナントを使用している場合は、テナント設定 advanced tab でさまざまなレガシー機能フラグが有効になっている可能性があります。このタブの「Migrations」セクションでいずれかのトグルがオンになっている場合は、利用状況を確認し、そのレガシー機能から移行する計画を立てる必要があります。

​

委任された管理者拡張機能

本番テナントにアクセスできるユーザーの一覧を確認する際は、Delegated Admin Extension で指定されているユーザーについても、忘れずに確認してください。

​

カスタムドメイン名の設定

デフォルトでは、テナントに関連付けられた URL には、その名前に加えて、場合によってはリージョン固有の識別子が含まれます。たとえば、米国ベースのテナントでは https://example.auth0.com のような URL になり、欧州ベースのテナントでは https://example.eu.auth0.com のようになります。 Custom Domain を使用すると、組織のブランドに沿った名前を利用できるため、ユーザーに一貫した体験を提供できます。

Auth0 Tenant ごとに適用できるカスタムドメイン名は 1 つだけです。そのため、ドメイン名のブランディングをどうしても完全に分ける必要がある場合は、複数の Auth0 Tenants を本番環境にデプロイする architecture が必要です。

さらに、Custom Domain 機能では、証明書管理プロセスを完全に制御できます。デフォルトでは Auth0 が標準の SSL 証明書を提供しますが、カスタムドメインを設定すると、Extended Validation (EV) SSL 証明書などを使用して、訪問者により大きな安心感を与えるブラウザ上の視覚的な संकेतを提供できます。

一般に、認証に一元化されたドメインを使用しているお客様が最も高い効果を上げています。これは、企業が複数の製品やサービスブランドを提供している場合に特に当てはまります。一元化されたドメインを使用することで、エンドユーザーに一貫したユーザー体験を提供できるだけでなく、Auth0 で複数の本番テナントを維持する必要も最小限に抑えられます。

​

アプリケーションと接続設定の確認

各接続設定が、接続設定のベストプラクティスに沿っているか確認する必要があります。

また、すべての接続が適切であること、および未承認アクセスを招くおそれがある実験的な接続が本番テナントに残っていないことも確認してください。

SAML 接続を使用している場合は、SAML リクエストに署名するよう接続を設定することがベストプラクティスです。

​

ページのカスタマイズ確認

Auth0のUniversal Loginページ、パスワードリセットページ、または Guardian の多要素認証を使用している場合は、エンドユーザーに表示されるページが適切にカスタマイズされていることを確認してください。

​

Universal Login ページ

Universal Login は、ユーザー認証の推奨方法であり、その中心となるのが Login ページです。Login ページは、組織のブランディング要件に合わせてカスタマイズできます。

​

ベストプラクティス

Universal Login ページをカスタマイズするには、ページテーマを変更するほか、動的なページテンプレートを作成することもできます。

Classic Login を実装し、Login ページのスクリプトをカスタマイズする場合は、バージョン管理を使用することを強く推奨します。そのためには、デプロイ自動化 または 代替手段 のいずれかを使用して、スクリプトを Auth0 テナントにデプロイしてください。

​

パスワードリセットページ

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

​

Guardian

多要素認証ページは、Universal Login Settings セクションで Universal Login のブランディングオプションを調整することで、カスタマイズできます。

さらに細かくカスタマイズする必要がある場合は、組織固有の UX 要件に合わせて、HTML コンテンツ全体 をカスタマイズすることもできます。

​

認可の確認

Auth0 の認可機能を使用している場合は、付与されているすべての権限を必ず再確認し、本番環境に適した認可設定になっていることを確認してください。

​

API設定の確認

​

アクセストークンの有効期限

本番環境の各APIに適した設定になっていることを確認するため、API access token expiration settingsを再度確認してください。

​

API オフラインアクセス

アプリケーションがリフレッシュトークンを要求しない場合は、これをオフにしてください。

​

アクセストークンの署名アルゴリズム

署名キーの漏えいリスクを最小限に抑えるため、API アクセストークンの署名アルゴリズム は、HS256 ではなく RS256 に設定することを推奨します。

​

API アクセストークンの検証

カスタム API がある場合は、それらが受け取ったアクセス トークンに含まれる情報を利用する前に、そのアクセス トークンを適切に検証していることを必ず確認してください。

​

API スコープ

いずれかの API に対してマシンツーマシンの呼び出しを行うアプリケーションがある場合は、API に設定されているスコープを見直し、本番環境に対してすべて適切であることを確認してください。詳細については、client credentials grant に関するドキュメントを参照してください。

​

メールテンプレートのカスタマイズ

Auth0 では、ユーザーへの通知や、安全な ID 管理に必要な機能 (たとえば、メールアドレスの確認、アカウント復旧、ブルートフォース対策) のためにメールを幅広く利用しており、そのためのテンプレートも複数用意されています。

メールテンプレートをカスタマイズする前に、メールプロバイダー を設定してください。

デフォルトでは、使用されるメールテンプレートには標準的な文面と Auth0 のブランド表記が含まれています。ただし、これらのテンプレートはほぼあらゆる要素を設定できるため、希望する文面やユーザー体験を反映したり、優先言語やアクセシビリティオプションなどを変更したりできます。

メールテンプレートは Liquid syntax を使用してカスタマイズします。ユーザーの設定に基づいてテンプレートをカスタマイズしたい場合は、ユーザープロファイル内の metadata に加えて、アプリケーション固有のメタデータにもアクセスできます。

​

攻撃保護の設定

認証システムが重要なのは、悪意のある攻撃者が、本来アクセスすべきでないアプリケーションやユーザーデータにアクセスするのを防ぐためです。こうした攻撃者とシステムへのアクセスの間には、できるだけ多くの障壁を設けることが重要です。その最も簡単な方法の 1 つが、Auth0 の攻撃保護が正しく設定されていることを確認することです。このトピックに関するガイダンスに目を通し、適切に機能していることを確認してください。

​

ベストプラクティス

異常検知は Auth0 によってバックグラウンドで処理され、プロダクトに優れたセキュリティ機能を提供します。これを利用する場合は、ユーザーへのメール送信を有効にする前に、メールプロバイダーを設定し、メールテンプレートを構成しておいてください。

​

プロジェクト計画ガイド

推奨戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドを提供しています。

B2B IAM プロジェクト計画ガイド