Skip to main content
ルールおよび Hooks の提供終了 (EOL) 日は 2026年11月18日 です。また、2023年10月16日 以降に作成された新規テナントでは、これらはすでに利用できません。既存のテナントで有効な Hooks を使用している場合は、提供終了まで Hooks 機能を引き続き利用できます。Auth0 を拡張するには、Actions の使用を強くお勧めします。Actions では、豊富な型情報、インラインドキュメント、公開 npm パッケージを利用できるほか、外部連携にも接続できるため、全体的な拡張体験が向上します。Actions の詳細については、Understand How Auth0 Actions Work をご覧ください。移行を支援するために、ルールから Actions への移行 と フックから Actions への移行 のガイドを用意しています。また、機能比較、Actions のデモ、および移行に役立つその他のリソースを紹介する専用の Move to Actions ページもあります。ルールおよび Hooks の非推奨化について詳しくは、ブログ記事 Preparing for Rules and Hooks End of Life をご覧ください。
Client Credentials Exchange 拡張ポイントでは、クライアント認証情報フローを使用して Authentication API の POST /oauth/token エンドポイント から が発行される際に、Hooks を使ってカスタムアクションを実行できます。たとえば、トークンの発行を拒否したり、Access Token にカスタムクレームを追加したり、scope を変更したりできます。詳しくは、Client Credentials Flow をご覧ください。 この拡張ポイントの Hooks はブロッキング (同期) 型です。つまり、トリガーの処理の一部として実行され、Hook が完了するまで Auth0 パイプラインの残りの処理は実行されません。
Client Credentials Exchange 拡張ポイントの triggerId は credentials-exchange です。この拡張ポイント用の Hook を作成する方法については、Create Hooks をご覧ください。
ほかの拡張ポイントについては、Extensibility Points をご覧ください。

スターターコードとパラメータ

Client Credentials Exchange の拡張ポイントで実行される Hook を作成する際は、以下のスターターコードが参考になります。Hook 関数に渡して利用できるパラメータは、コードサンプルの冒頭に記載されています。
以下の点にご注意ください。
  • サンプルコードの末尾にあるコールバック関数 (cb) は、処理の完了を通知するためのもので、必ず含める必要があります。
  • access_token.scope = scope という行は、付与されたすべてのスコープがアクセストークンに含まれるようにするためのものです。これを削除すると、すべてのスコープがリセットされ、トークンにはスクリプトで追加したスコープだけが含まれます。

デフォルトレスポンス

Client Credentials Exchange 拡張ポイントで Hook を実行すると、デフォルトのレスポンスオブジェクトは次のとおりです。

スターターコードのレスポンス

スコープと追加のクレームを使ってスターターコードをカスタマイズしたら、Hook Editor に組み込まれているランナーで Hook をテストできます。ランナーは、Client Credentials Exchange で取得されるものと同じリクエスト本文とレスポンスを使って、Hook の呼び出しをシミュレートします。
ランナーでコードを実行するには保存が必要なため、元のコードは上書きされます。
スターターコードに基づく Hook を実行すると、レスポンスオブジェクトは次のようになります。

サンプルスクリプト: アクセストークンにスコープを追加する

この例では、Hook を使用して、アクセストークンにすでに含まれているスコープに追加のスコープを加えます。
詳しくは、スコープをご覧ください。

レスポンス

このHookを実行すると、レスポンスオブジェクトは次のようになります。

サンプルスクリプト: アクセストークンにクレームを追加する

この例では、名前空間付きのカスタムクレームとその値をアクセストークンに追加します。詳細については、Create Namespaced Custom Claimsを参照してください。 発行されたトークンには、次の内容をクレームとして追加できます。
  • レスポンスオブジェクトの scope プロパティ
  • 名前空間付きのプロパティ名を持つ任意のプロパティ
拡張ポイントでは、レスポンスオブジェクトのそのほかのプロパティはすべて無視されます。
フック内から設定済みの Hook Secret にアクセスするには、context.webtask.secrets.SECRET_NAME を使用します。

レスポンス

このHookを実行したときのレスポンスオブジェクトは次のとおりです。

サンプルスクリプト: エラーを返す、またはアクセストークンを拒否する

この例では、独自の Error オブジェクトを使用して、OAuth 2.0 のエラーレスポンスを生成します。 (詳しくは、IETF Datatracker の OAuth2 RFC - セクション 5.2を参照してください。) 次のように、通常の JavaScript エラーがコールバックで返されると:
その後、/oauth/token エンドポイントに client_credentials グラントをリクエストすると、Auth0 は次のように応答します:
ただし、OAuth 2.0 のエラーレスポンスをより細かく制御したい場合は、代わりに使用できる 3 つのカスタム Error オブジェクトが用意されています。

InvalidScopeError

続いて、/oauth/token エンドポイントに client_credentials グラントをリクエストすると、Auth0 は次のように応答します:

InvalidRequestError

その後、/oauth/token エンドポイントに client_credentials グラントをリクエストすると、Auth0 からは次のような応答が返されます。

ServerError

次に、/oauth/token エンドポイントに対して client_credentials グラントをリクエストすると、Auth0 は次のように応答します:
現時点では、組み込みの JavaScript Error クラスと ServerError の動作は同じですが、ServerError クラスを使うと、返される OAuth 2.0 エラーを明示的に指定できます。

さらに詳しく