テナントチェック（B2C）

B2C IAM 実装のリリース前に実施するテナントチェック。

このセクションでは、テナントで確認すべき設定項目の一覧を示します。これらの確認は開発中に定期的に行い、問題があれば修正する時間を確保できるよう、リリースの十分前にも実施してください。

​

一般的なテナントの確認

​

テナント準備チェック

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

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

環境	テナント名の例	説明
開発	company-dev	開発作業の大半を行う共有環境
QA/テスト	company-qa または company-uat	加えた変更を正式にテストするための環境
本番	company-prod	本番テナント

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

​

ベストプラクティス

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

​

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

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

​

本番テナントを指定する

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

​

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

Auth0 には、多くの一般的なエラーを検出できる Production Check 機能があります。リリース前にこれを実行し、レポートで指摘された事項に対処しておくようにしてください。

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

​

テナント設定の確認

​

テナント設定

問題が発生した際にユーザーがサポートを受ける方法をわかるよう、ブランディングに加え、サポート用メールアドレスとサポート URL を設定する際は、Auth0 の テナント設定 の推奨事項に必ず従ってください。また、SSO セッションのタイムアウト設定と、本番テナントにアクセスできる Dashboard 管理者の一覧も確認してください。

​

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

ユーザーが操作するワークフロー (例: ユーザー登録やログイン) の途中で問題が発生すると、Auth0 は内部的に何が原因かを示すエラーメッセージを返します。デフォルトのメッセージはやや分かりにくく、特にエンドユーザーにとっては、必要な文脈情報を補えるのがあなただけであることもあり、理解しづらい場合があります。そのため、不足している状況に応じた情報をユーザーに直接提供できるよう、エラーページをカスタマイズすることをお勧めします。さらに、エラーページをカスタマイズすると、Auth0 ではなく独自のブランディングを表示できるほか、次に何をすべきかについてユーザーに役立つ情報も提供できます。たとえば、FAQ へのリンクや、会社のサポートチームまたはヘルプデスクへの連絡方法などを含めることができます。

​

ベストプラクティス

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

​

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

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

​

Delegated Admin 拡張機能

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

​

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

デフォルトでは、テナントに関連付けられた URL には、その名前と、場合によってはリージョン固有の識別子が含まれます。たとえば、米国のテナントの URL は https://example.auth0.com のようになり、ヨーロッパのテナントでは https://example.eu.auth0.com のようになります。カスタムドメイン を使用すると、組織のブランディングに合った名前を使って、ユーザーに一貫した体験を提供できます。

1 つの Auth0 テナントに適用できるカスタムドメイン名は 1 つだけです。そのため、ドメイン名のブランディングをどうしても個別に分ける必要がある場合は、本番環境に複数の Auth0 テナントをデプロイする アーキテクチャ が必要になります。

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

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

​

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

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

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

SAML 接続を使用している場合は、SAML リクエストに署名するように接続を設定することを推奨します。

​

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

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

​

Universal Login ページ

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

​

ベストプラクティス

Universal Login ページのスクリプトをカスタマイズする場合は、バージョン管理を使用することを強くお勧めします。これを行うには、デプロイ自動化 または 別の方法 のいずれかを使用して、スクリプトを Auth0テナントにデプロイしてください。

​

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

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

​

Guardian

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

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

​

認可の確認

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

​

API 設定の確認

​

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

本番環境の各 API に対して適切な設定になっていることを確認するために、API アクセストークンの有効期限設定をあらためて確認してください。

​

API のオフラインアクセス

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

​

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

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

​

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

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

​

API スコープ

いずれかの API に対してアプリケーションがマシン間呼び出しを行っている場合は、API に指定されているスコープを見直し、本番環境に適したものだけが含まれていることを確認してください。詳細については、クライアントクレデンシャルグラント に関するドキュメントを参照してください。

​

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

Auth0 は、ユーザーへの通知や、安全なアイデンティティ管理に必要な機能 (たとえば、メールアドレス確認、アカウント復旧、ブルートフォース対策) を実現するために、メールを幅広く活用しており、そのための各種テンプレートを提供しています。

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

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

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

​

アタックプロテクションの構成

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

​

ベストプラクティス

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

​

プロジェクト計画ガイド

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

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