ルール環境のベストプラクティス

ルールは一連のJavaScript関数を呼び出して、Auth0のサーバーレスWebtaskコンテナーのインスタンスで実行します。これに関して、コンテナーとAuth0認証サーバー（ご利用のAuth0テナント）による各種のアーティファクトと共に、特定の環境が提供されます。

Auth0のサーバーレスWebtaskコンテナーでは、さまざまなnpmモジュールを利用することができます。npmモジュールはルールのコード実装で総サイズを低減するだけでなく、予め構築された幅広い機能を活用できるようにします。

デフォルトで、公開されているnpmモジュールの広範なリストが、変更することなくそのままで使用できます。このリストは、潜在的なセキュリティ関連の懸念を調査した上でまとめられています。リストを表示するには、「必要性の判断：Auth0の拡張性」をお読みください。

必要なnpmモジュールが提供されていない場合には、Auth0のサポートポータルまたはAuth0の担当者までリクエストを提出してください。Auth0がリクエストを検討して、適合性を判断します。プライベートリポジトリで提供されているnpmモジュールについては、その使用に関して、Auth0は現在サポートを提供していません。リクエストされた場合、新しいパッケージは通常2週間ごとに追加されます。ルールで破壊的変更の原因となるため、既存のパッケージが削除されることはめったにありません。Auth0のパッケージとバージョンは内部レジストリに保管され、npmとは同期していない点に注意してください。

npmモジュールで外部サービスにアクセスしている場合は、API要求を最小限に抑え、有料サービスへの過剰な呼び出しを控え、送信内容を制限して潜在的なセキュリティ露出を回避してください。詳細については、「パフォーマンスのベストプラクティス」をお読みください。

ルールでモジュールを必須にするときに、バージョンが指定されていない場合、パッケージマネージャーは内部リストで見つかった最初のバージョンを使用します。パッケージマネージャーがデフォルト以外のバージョンを使用するように、バージョンを指定することもできます。そうすることで、ルールコードは、指定されたバージョンでは提供され、デフォルトのバージョンでは提供されていない修正や機能を活用することができます。

Auth0 Rulesは環境変数に対応しており、グローバルに使用可能な構成オブジェクトを介して使うことができます。構成は読み取り専用として扱い、資格情報やAPIキーなど、外部サービスへのアクセスに使う機密性の高い情報を保管するために使用します。そうすれば、ルールで機密性の高い値をコードに埋め込まなくてすみます。変数にテナント特定の値が定義できるようなるため、ソフトウェア開発ライフサイクル（SDLC）のベストプラクティス戦略に対応させることができます。これにより、ルールの実行テナントに依存して変わる値を、コードの中に埋め込む必要性が軽減されます。

Auth0のサーバーレスWebtaskコンテナーは、各Auth0テナントに関連付けられているプールからプロビジョニングされます。コンテナーインスタンスはそれぞれglobalオブジェクトを使用可能にして、コンテナーインスタンス内で実行されるすべてのルールからアクセスできるようにします。globalオブジェクトはグローバル変数として機能し、情報や関数を定義するのに使用できます。これは、パイプラインインスタンスにかからわず、（コンテナーで実行される）ルール全般に使用することができます。

global.tokenVerify = global.tokenVerify || function(token, secret) {
      /* The 'jwt.verify' function is synchronous, however wrapping with a promise
      * provides for better error management and integration within the logic
      * flow.
      */
      return new Promise(function(resolve, reject) {
      jwt.verify(
    token,
    secret,{
    clockTolerance: 5},
    function(err, decoded) {
      if (err) {
    reject(err);
      } else {
    resolve(decoded);
      }
      });
    });
    };

globalオブジェクトは、ユーザーに特定されない機能性を提供するサードパーティ（ログなど）APIのアクセストークンや、Auth0で定義され、クライアントの資格情報フローで取得される独自のAPIへのアクセストークンなど、コストのかかるリソースのキャッシュにも使用できます。

パイプラインの実行では、ルールを複数回実行することができますが、運用のコンテキストによって異なります。ルールが実行されるコンテキストでは、既存のコンテナーインスタンスがAuth0テナントのプールからプロビジョニングされるか、新たにインスタンス化されます。Webtaskコンテナーの新しいインスタンスでは、globalオブジェクトがリセットされます。このため、globalオブジェクト内のすべての宣言には、初期化のプロビジョニング（上の例を参照）も含める必要があります。理想的には、その宣言はできるだけ早期（実行順で早期に実行されるルール内）に行います。

auth0オブジェクトは、ManagementClientの特別に制限されたインスタンス（Auth0以外のNode.jsクライアントライブラリーで定義）で、Auth0 Management APIへの限定アクセスを提供します。このオブジェクトは主に、ルール内のuserオブジェクトに関連付けられたメタデータを更新するの使用されます。

このように制限されているだけでなく（限られた数のManagementClientメソッドをuserアクセスのみに対応）、auth0オブジェクトに関連付けれらたアクセストークンでもスコープがread:usersとupdate:usersに制限されます。通常、ルール内からの実行が推奨される大半の操作では、これで十分になります。ただし、対応している全種類のメソッドと追加のスコープにアクセスする必要がある場合は、別の方法でManagement APIを使う必要があります。

ルール内から別の方法でManagement APIにアクセスするには通常、ManagementClientの独立したインスタンスを初期化します。これにより、レート制限ポリシーによる429エラー発生時の自動再試行ロジックを含む、すべての現行機能にアクセスすることができます。さらに、デフォルトのスコープのみが必要な場合は、auth0オブジェクトに関連付けられたアクセストークンを使って、新しいインスタンスを初期化することもできます。

contextオブジェクトと同様に、auth0オブジェクトには機密性の高い情報が含まれているため、外部またはサードパーティサービスに渡してはなりません。その上、Auth0 Management API にはレート制限に加えて、遅延も関与するため、呼び出す頻度を慎重に考慮する必要があります。contextオブジェクトについては、「ルール実行のベストプラクティス」をお読みください。

auth0オブジェクト（およびAuth0 Management APIを呼び出す他のメカニズム）は控えめに使用し、例外とエラーの扱いを適切に行い、パイプライン実行の予期しない中断は防くようにしてください。

• ルールの構造に関するベストプラクティス
• ルールの実行に関するベストプラクティス
• ルールセキュリティのベストプラクティス
• ルールのテストに関するベストプラクティス
• エラー処理のベストプラクティス