Tenant Check（B2C）

B2C IAM 実装のローンチ前に実施する Tenant Check。

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

​

一般的なテナントの確認

​

テナント準備チェック

ソフトウェア開発ライフサイクルを支えられるようにテナント環境が設定されており、Dev、Test、Prod の各テナントが明確に分離されていることを確認してください。こうすることで、ローンチ後も続く開発作業が本番環境に悪影響を及ぼすのを防げます。

どの企業にも何らかの形のソフトウェア開発ライフサイクル (SDLC) があり、開発プロセス全体を通じてその進め方に合わせる必要があります。たとえば、アプリケーション自体をテストするのと同じように、Auth0 との連携もテストできるようにしておく必要があります。そのため、SDLC を支えられるように Auth0 テナントを構成することが重要です。これを実現するためのテナント構成については、ベストプラクティスとして多くのお客様が採用している一般的なパターンがあります。

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

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

​

ベストプラクティス

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

​

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

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

​

本番テナントを指定する

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

​

テナント本番チェック

Auth0 には、多くの一般的なエラーを検出するための本番チェック機能があります。ローンチ前に、これが実行されており、レポートで指摘された事項にすべて対処されていることを確認してください。

さらに、自動では確認できないベストプラクティスの設定に関するアドバイスも確認する必要があります。

​

テナント設定の確認

​

テナント設定

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

​

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

ユーザーによる対話型ワークフロー (たとえば、ユーザー登録やログイン) の途中で問題が発生すると、Auth0 は内部的に何が問題なのかを示すエラーメッセージを表示します。既定のメッセージはやや分かりにくく、特にエンドユーザーにとっては難解になりがちです。というのも、そこには通常、あなたしか補えないコンテキストが欠けているからです。そのため、不足している状況に応じた情報をユーザーに直接伝えられるよう、エラーページをカスタマイズすることをお勧めします。さらに、エラーページをカスタマイズすれば、Auth0 ではなく自社のブランディングを表示できるほか、次に何をすべきかについて役立つ情報もユーザーに提供できます。たとえば、FAQ へのリンクや、自社のサポートチームまたはヘルプデスクへの連絡方法などを含めることができます。

​

Best Practice

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

​

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

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

​

Delegated Admin Extension

本番テナントにアクセスできるユーザーの一覧を確認する際は、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 テナントにデプロイする必要があります。

​

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

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 では、ユーザーへの通知だけでなく、安全なアイデンティティ管理に必要な機能 (たとえば、メールアドレスの確認、アカウント復旧、ブルートフォース対策) にもメールが幅広く使われており、そのためのテンプレートが多数用意されています。

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

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

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

​

攻撃対策の設定

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

​

ベストプラクティス

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

​

プロジェクト計画ガイド

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

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