テスト完了 (B2B)

お客様が利用を開始する前に、Auth0 のテストポリシーに従ってすべてのテナントで単体テスト、連携テスト、モックテスト、ペネトレーションテスト、負荷テストを完了し、Auth0 B2B 実装がローンチ可能な状態であることを確認します。

ローンチ前に、ご利用の環境に該当するすべてのテストを完了しておく必要があります。

品質保証は、お客様に影響が及ぶ前に問題を特定するうえで重要です。また、プロジェクトの内容によっては、Auth0 との連携の一環として検討すべき品質保証テストにはいくつかの種類があります。

• 障がいのある方を含め、誰にとってもアプリケーションはわかりやすく使いやすいものになっていますか？
• アプリケーションは、さまざまなブラウザーやデバイスで動作する必要がありますか？
• アプリケーションは、多国籍または国際的な環境で動作する必要がありますか？
• 想定外の本番負荷がかかった場合、アプリケーションのパフォーマンスはどうなりますか？
• アプリケーションをセキュリティ関連の脆弱性からどのように保護しますか？

Auth0 Universal Login と関連する UI ウィジェット (Lock など) は、すでにユーザビリティとアクセシビリティのベストプラクティスに従って設計・構築されており、多数の ブラウザーおよびデバイス に対する、テスト済みですぐに利用できるサポートを提供しています。さらに、国際化  (I18N) もそのまま利用できる形で提供されており、カスタムの多言語化やローカライズ (L10N) に対応するための組み込みの拡張も備えています。

機能要件が満たされ、想定外の事象が適切に処理されることを確実にするために、アプリケーションと Auth0 の間の 連携 テストに関するガイダンスと、個々の拡張モジュール (ルール、フック、および Custom DB スクリプトなど) の 単体テスト に関するガイダンスが提供されています。また、セキュリティ脆弱性のテストを行う際に役立つ Auth0 の ペネトレーションテストポリシー に関するガイダンスや、想定外の負荷がかかった状況でもアプリケーションが適切に動作することを確認できるよう、モック テストを当社の 負荷テストポリシー と組み合わせて活用する方法についてのガイダンスも提供されています。

​

単体テスト

単体テストの目的は、コードの個々の単位を検証することです。Auth0 で、ルール、フック、または Custom DB スクリプト としてカスタムコードを作成する場合は、そのコードをテストするために、Mocha のようなテストフレームワークの利用を検討してください。Auth0 を最も効果的に活用している企業では、Auth0 テナントの設定や関連リソースを自動的にデプロイする前に、これらの単体テストを実行することが有用だとされています。

​

統合テスト

SDLC のサポートに関する Architecture ガイダンスで説明しているように、開発、テスト、本番用にそれぞれ異なるテナントを設定することを推奨します。Auth0 では、カスタムな拡張内で利用できる変数を設定できます。これらは Auth0 テナントの環境変数と考えることができます。開発、テスト、本番の各環境間でコードを移行するたびに変更が必要になる参照をハードコードするのではなく、テナントで設定した変数名をカスタム拡張コードから参照できます。これにより、実行時にテナント固有の値が設定される変数をコードから参照できるため、同じカスタムコードを変更せずに異なるテナントで動作させやすくなります。

• ルールでの変数の使用については、値を設定する方法を参照してください
• フックでの変数の使用については、エディターでシークレットを設定する方法を参照してください
• Actions での変数の使用については、Flows とトリガーを参照してください
• Custom DB スクリプトでの変数の使用については、構成パラメータを参照してください

​

ベストプラクティス

テナント固有の値に加え、カスタムコード内で公開すべきではない機密性の高いシークレットを保持するためにも、変数を使用することを推奨します。カスタムコードを GitHub で管理している場合、テナント固有の変数を使用することで、GitHub リポジトリを通じて機密値が公開されるのを防げます。

​

テスト自動化

デプロイの自動化に加えてテスト自動化も組み込むことで、ビルドプロセス全体を自動化できます。これにより、設定やカスタムコードの新しいバージョンを Auth0 にデプロイし、自動テストを実行できます。テストで不具合が見つかった場合は、デプロイ自動化の機能を使って、最後に正常に動作していたバージョンに戻すことができます。詳しくは、デプロイ自動化のガイダンスを参照してください。

​

モックテスト

Auth0 の 負荷テストポリシー に配慮しつつ負荷テストも実施したい場合、Auth0 のお客様の間では Auth0 のエンドポイントをモック化するのが一般的です。これは、テストを制限することなく、想定どおりのインターフェースでアプリケーションが動作することを確認するための有効な方法です。 MockServer、 JSON Server、さらには Postman などのツールも活用できます。

​

ペネトレーションテスト (任意)

ペネトレーションテストを実施する場合は、Auth0 のペネトレーションテストポリシーを確認し、これに従ってください。テストが悪意のあるアクティビティと誤認されて停止されないようにするため、ペネトレーションテストを実施する際は事前に Auth0 へ通知する必要があります。

​

負荷テスト (任意)

負荷テストを実施する予定がある場合は、Auth0 の負荷テストポリシーを理解し、それに従う必要があります。負荷テストを実施するには、事前に Auth0 へ通知する必要があります。負荷テストを計画する際は、Auth0 の API rate limits についても把握しておく必要があります。

負荷テストを行うには、Auth0 の負荷テストポリシーに記載されているとおり、事前に Auth0 の承認を得る必要があります。リクエストの審査に必要なリードタイムを必ず確認し、審査とテスト実施の両方に十分な時間を確保してください。負荷テストのリクエストが承認された場合は、次のガイダンスがエラーや不正確なテスト結果の回避に役立ちます。

• アプリケーションのテスト実行時に HTTP trace を取得し、アプリケーションまたは予定しているテストで必要となるすべての呼び出しを特定してください。また、本番環境で実際に発生する内容を適切に反映できるよう、それらがテストに含まれていることを確認してください。
• Auth0 API のレート制限を考慮してテストを設計してください。
• Auth0 内のカスタムコード (Actions、ルール、フック、Custom DB スクリプト、カスタム OAuth 接続) を使用すると、Auth0 のカスタムコード sandbox が呼び出されるため、パフォーマンス面でコストが増える可能性があります。テストに不可欠でない限り、ルールはオフにしてください。オフにすると、オンの場合よりも高いスループットが得られます。
• 本番環境で想定される全体的な負荷と、各 endpoint への呼び出しの割合を見積もり、それに応じてパフォーマンステストを構成してください。そうすることで、現実的なテスト結果が得られます。endpoint ごとにパフォーマンスコストは異なります。実態を反映したテストを設計しないと、誤解を招く結果になります。
• 先行する呼び出しの結果に依存する呼び出しは、前提となる呼び出しや応答が完了したことを確認する前に実行しないでください。単に遅延を入れるだけでは不十分な場合があります。
• 十分なエラーハンドリングを実装してください。テスト中の問題でよくある原因は、カスタムコード (Actions、ルール、フック、Custom DB スクリプト、カスタム OAuth 接続スクリプト) 内の未処理例外によって発生するエラーです。
• 最も有用な結果を得るため、負荷テストは低いレベルから開始し、各レベルでデータを取得しながら徐々に負荷を増やすように作成してください。高いレベルから開始してすぐに失敗すると、システムがどの程度まで耐えられるかについて得られる情報は少なくなります。
• パフォーマンステストは複数回実行する必要があるのが普通で、その際にはテスト対象のコードやテストハーネス／構成を調整することもあります。複数回の反復に十分な時間を確保できるよう、早めにテストを開始してください。
• 独自のメールプロバイダーアカウントを使用し、十分なメール送信 quota を事前に確保するよう手配してください。そうしないと、メールプロバイダー側でレート制限を受ける可能性があります。メール送信を使用しない場合は、オフにしてください。
• すべてのソーシャル接続で、Auth0 の開発用キーではなく、必ず独自のアカウント資格情報を使用してください。Auth0 Dashboard で、Connections -> Social -> {name of connection} に移動すると、接続に独自のソーシャルプロバイダーアカウントの資格情報を追加する方法を確認できます。注: 一部のソーシャルプロバイダーでは負荷テストが許可されていません。ポリシーについては各プロバイダーで確認してください
• レート制限を避け、実際の負荷をより正確に再現するために、テストでは同じユーザーに対するリクエストばかりではなく、異なるユーザーに対するリクエストを送る必要があります。1 人または少数のユーザーしか使用しない場合、キャッシュによって実効負荷が下がり、現実的な結果が得られないことがあります。
• テストについて合意されたパラメータと Auth0 の負荷テストポリシーの範囲内に必ずとどめてください。Auth0 は、合意されたパラメータの範囲を逸脱する、または予定されたテスト時間枠を超えるパフォーマンス／負荷テストを終了させる権利を留保します。

​

プロジェクト計画ガイド

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

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