パフォーマンスのベストプラクティス

Documentation Index

Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt

Use this file to discover all available pages before exploring further.

ルールはパイプラインの一部として実行されます。ここでは、「カスタムデータベースの構造に関するベストプラクティス」に説明するように、信頼性の高いアーティファクトが生成されます。このため、有効になったルールは、ログイン操作（インタラクティブかどうかを問わず）とサイレント認証を行うときと、ユーザーの資格情報関連のアクセストークンがAPI呼び出しに対して生成されるときに毎回実行されます。つまり、小規模のデプロイメントでも、パフォーマンスが懸念され、デプロイメントの規模が大きくなれば、低下の一途をたどる可能性があります。 条件付きロジックに基づいて実行することを選択します。たとえば、特定のアプリケーションのみに対してルールを実行するには、特定のclientIDについて調べるか、複数アプリケーションに共通する、特定のclientMetadata（特に、1つのclientMetadataという値に対して確認を行う場合）が存在するかどうか確認します。clientMetadataを使うと、新しいクライアントの追加（およびルールコードの読み取り）もさらに簡単になります。特に、大量のアプリケーションが定義されている場合は、環境間で必要なコード変更または構成値を減らすことで行えます。 Auth0 Dashboardでアプリケーションのクライアントメタデータを手動で設定するには、［Application Settings（アプリケーション設定）］>［Advanced Settings（詳細設定）］>［Application Metadata（アプリケーションメタデータ）］の順に進むか、Auth0 Management APIのクライアント更新エンドポイントを使ってプログラムによって実行します。 最適なパフォーマンスを得るには、できるだけ早くに完了するルールを書きます。たとえば、ルールに実行するべきかどうかを判定するチェック項目が3つある場合、初回のチェックで大半のケースを削除し、その後のチェックで次に最も大きなケースを削除するなどします。各チェックの終わりでは、コールバック関数を必ず実行します。この際、（ルール）関数を終了するために、(JavaScript) returnと組み合わせるとよいでしょう。詳細については、「ルールの実行に関するベストプラクティス APIへの呼び出し、特に、サードパーティAPIへの呼び出しを実行すると、ログイン応答時間が低下する恐れがあります。呼び出しが遅れたことで、ルールタイムアウトエラーが発生し、最終的に認証エラーが発生する可能性があります。弊社では、API要求をルール内で可能な限り最小限に抑え、有料サービスへの過剰な呼び出しを避けるようお勧めします。さらに、APIサードパーティなどへの送信を制限することで、潜在的なセキュリティリスクへの曝露も回避するようお勧めします。 globalオブジェクトを使って、API呼び出しから情報をキャッシュし、これを後でパイプラインで実行されるすべてのルールにわたって使用することができます。APIを繰り返し呼び出すのでなく、これを使って情報を保存することを選択します。さらに、globalオブジェクトを使って、ルールの実行間で他の情報をキャッシュすることもできます。 SMSメッセージをTwilioで送信するなどの有料サービスを呼び出すルールがある場合は、これらのサービスを必要な場合にのみ使用するようにします。こうすることで、パフォーマンスが向上するだけでなく、追加料金を避けることにもなります。有料サービスへの呼び出しを減らすには、以下のようにします。

• パブリックサインアップを禁止し、サインアップして有料サービスへの呼び出しをトリガーできるユーザー数を減らします。
• ルールが許可されたユーザーのサブセットまたは他の適切な条件に対してのみトリガーされることを確認します。たとえば、有料サービスへの呼び出しをトリガーする前に、ユーザーが特定のメールドメイン、ロール/グループ、またはサブスクリプションレベルを持っているかどうかをチェックするロジックを追加したい場合もあるでしょう。

Auth0 Management APIへの呼び出しを避けるようにしてください。Auth0 Management APIにはレート制限がかかっています。これは、auth0オブジェクトを使用する場合でも考えられます（このため、控えめに使用してください）。詳細については、「Management APIエンドポイントレート制限」をお読みください。 さらに、Management API関数に実行にかかる時間はさまざまです。そのため、さまざまな程度で遅延が発生します。たとえば、Management APIのユーザーの表示・検索エンドポイントの呼び出しにかかる時間を最小限に抑え、auth0オブジェクトを介して実行するときでも、どうしても必要な場合にのみ行ってください。 ルールのcontextオブジェクトに使用できる接続関連のプロパティを拡張したため、contextオブジェクトから接続情報を取得でき、Auth0 Management APIを呼び出す必要がなくなりました。詳細については、「ルールのコンテキストオブジェクトプロパティ」をお読みください。 実際の動きを確認するには、「ユーザーのメールドメインが構成されたドメインのルールテンプレートに一致するかどうか確認する 」というルールテンプレートを使用している場合は、Githubで最新バージョンのチェックアウトを行うか、［Auth0 Dashboard］>［Auth Pipeline（Authパイプライン）］>［Rules（ルール）］の順に移動し、［Create（作成）］ を選択します。注意：最近行った変更によって機能が変わることはありませんが、Management APIへの呼び出しをこれまで利用してきたルールのパフォーマンスは向上します。 Management APIへの呼び出し（および適切なアクセストークンの取得に必要な追加の呼び出し）を削除すると、ルールコードのパフォーマンスが向上し、信頼性が高くなります。 APIを呼び出したり、外部サービスにアクセスしたりする場合、明示的なタイムアウトを指定することを検討してください。選択する特定のタイムアウトは通常、ユースケースに応じて異なりますが、一般的には、外部サービスのパフォーマンス特性を念頭に置きながら、できるだけ低いものを選択することが推奨されます。 明示的または暗示的なタイムアウト処理のどちらを選ぶにしても、タイムアウトが期限切れになったために発生する可能性のあるエラーや例外の状態に必ず応じるようにします。詳細については、「エラー処理に関するベストプラクティス」をお読みください。 レート制限を超えた場合は、Auth0への呼び出し回数を減らす必要があります。具体的な方法はユースケースによって異なりますが、いくつか推奨事項を挙げておきます。

• /.well-known/*応答をキャッシュする：この情報の変更は頻度が少ないため、通常はキャッシュして、Auth0に呼び出す回数を減らすことができます。
• ユーザーに関する情報の取得には、 /userinfoの呼び出しではなく、 id_tokenの要求を検討します。
• 一括削除や一括ロック解除など、一括での呼び出しを減らします。

• ルールのベストプラクティス
• エラー処理のベストプラクティス
• デバッグのベストプラクティス