Actions の基本
- ログイン中にリクエストが積み重なるのを避けるため、HTTP リクエストはできるだけ少なくし、妥当なタイムアウト (10 秒未満) を設定します。
-
特定のアプリケーションに対して Action を実行するかどうかを判断するには、application metadata を使用して対象のアプリケーションを絞り込みます。
- 例: Action の実行内容を部分的または全面的に変えるために使う、アプリケーション固有の値やアプリケーションのグループ値。
-
ユーザープロファイルにカスタムデータを保存するには、
user_metadata/app_metadataを使用します。- 例: ユーザー設定や state の値。
-
同じ実行内で post-login triggers 間でデータを共有するには、transaction metadata を使用します。
- 例: 外部サービスから取得した値や計算した値のうち、後続の Actions で再利用する必要があり、現在の実行に関連するもの。
-
異なる実行に属する Actions 間で共有するデータには、キャッシュを使用します。
- 例: 外部サービスから取得した値や計算した値のうち、Actions で再利用する必要があり、ユーザーや現在の特定の実行とは無関係なもの。
- 検証を行ったり をトリガーしたりする Actions が、意図せず、または悪意を持って回避されないようにしてください。
-
Actions で意図的にエラーをスローしてはいけません。エラーや条件によって処理を停止する場合は、
api.access.deny()などの適切なapiメソッドを使用します。 -
Authentication API 呼び出しで使用されるドメインには
event.request.hostnameを使用します。これは既定の Auth0 テナントドメイン、または custom domain の場合があります。
Actions Modules
- 異なる Action 間で関数を再利用する必要があり、コードの重複を避けたい場合は、Actions Modules を使用します。
- 可能な場合は、Singleton pattern を実装して Action Module でオブジェクトインスタンスを再利用し、インスタンス化にかかる時間を削減します。
- コーディング、セキュリティ、ログ、依存関係、ユーザーデータに関しては、このドキュメントに記載されている該当ガイドラインに従ってください。
- Action から Action Module を使用する際は、使用しているモジュールのバージョンを常に把握しておいてください。
新しい Action Module のバージョンを公開しても、Auth0 が Actions で参照されているバージョンを自動的に更新することはありません。これにより、アップグレード後のバージョンが Action と互換性がない場合に不具合が発生するのを防げます。
コーディングの基本
- 受信または保存するデータでは、必ず厳密等価演算子
===を使用します。 - Action の処理を停止する必要がある場合は、
return文を使用します。 - コードの品質向上と問題の自動検出のために、ESLint のようなコードリンターや、Semgrep のようなアナライザーを実行します。
セキュリティの基本
- Actions のコード内に、シークレットや機密性の高いコード成果物を平文で記述しないでください。代わりに、Secrets Manager を使用するか、独自のマネージャーを Actions のコードに統合して利用してください。
- URL やエラーメッセージなど、外部から見える場所で、暗号化されていない個人を特定できる情報 (PII) を送信しないでください。
- リダイレクトと API 呼び出しには、必ず HTTPS URL を使用してください。
- 可能な場合は、IP アドレスを許可リストに登録してください。
- 改ざんされる可能性のある受信データ (URL パラメーター、ユーザーエージェントなど) に注意してください。
防御的コーディング
- エラーを捕捉し、必要に応じて適切に処理します。
- Action の処理を続行すべきでない場合は、ガード節を使って早めに return します。
ログ
- 機密データ、シークレット、または PII は決してログに記録しないでください。
- 1 つの Action に記録するログは、最大 256 文字以内にしてください。
依存関係
- 信頼でき、適切に保守されているパッケージを使用します。
npmの監査機能や、リポジトリと連携した自動依存関係チェッカーを使って、未対応の CVE がないか確認します。- 可能であれば、パッケージの最新バージョンを使用します。
ユーザーデータ
- 機密性の高い用途や高セキュリティが求められる場面で使用する場合は、
event.user.email_verifiedを使って、メールアドレスが確認済みかどうかを確認してください。 - Connection によって提供されるユーザープロファイルデータは異なります。唯一保証されている ユーザープロファイルフィールド は
user_idだけです。
ログインフローでのリダイレクトActions
-
api.redirect.encodeTokenが返すトークンは署名されていますが暗号化はされていないため、機密データや個人を特定できる情報 (PII) をペイロードに含めるべきではありません。 -
ログインフローはログイン成功後に実行され、これには次のケースが含まれます:
- SSO (ログインフォームは表示されない)
- サイレント認証 (認可 URL で
prompt=noneを使用してセッションを確認する) - リフレッシュトークンの交換 (ユーザーの操作なし)
- RO パスワードグラント (アプリケーションが収集した認証情報をトークンエンドポイントに送信して交換する)
- リダイレクトを行うActionsでは、上記のケースを考慮し、ユーザーによる操作が必要な場合はアクセスを拒否するか、あるいは意図的にバイパスを許可する必要があります。後者の場合、ログインを要求するアプリケーション側がその責任を負うことになります。