メインコンテンツへスキップ
Rules と Hooks のサポート終了 (EOL) 日は 2026年11月18日 です。また、2023年10月16日 以降に作成された新しいテナントでは、すでに利用できなくなっています。アクティブな Hooks を持つ既存のテナントは、サポート終了まで Hooks へのアクセスを維持できます。Auth0 の拡張には、Actions の使用を強くお勧めします。Actions では、豊富な型情報、インラインドキュメント、公開 npm パッケージを利用できるほか、外部統合に接続して、拡張性に関する全体的な開発体験を向上させることができます。Actions の詳細については、Understand How Auth0 Actions Work を参照してください。移行を支援するために、Rules から Actions への移行Hooks から Actions への移行 のガイドを用意しています。また、機能比較、Actions のデモ、および移行に役立つその他のリソースをまとめた専用の Move to Actions ページもあります。Rules と Hooks の非推奨化について詳しくは、ブログ記事 Preparing for Rules and Hooks End of Life を参照してください。
Rules を使用すると、事前構成された認可ポリシーによる判定結果を変更または補完し、ロールベースのアクセス制御 (RBAC) だけでは対応できない、より複雑なケースを処理できます。実行順序に応じて、Rules は権限が に追加される前に、認可の判定結果を変更できます。また、トークンの内容をカスタマイズすることもできます。

特定のアプリケーションへのアクセスを平日に限定する

たとえば、あるアプリケーションを平日のみアクセス可能にしたい場合は、次のルールを作成します:
ユーザーが週末にアプリケーションへのアクセスを試みた場合、認証に成功し、適切な権限を持っていても、アクセスは拒否されます。

社内ネットワーク内のユーザーにのみアクセスを許可する

たとえば、アプリケーションへのアクセスを許可する対象を、社内ネットワーク内からそのアプリケーションにアクセスしているユーザーのみに制限したいとします。その場合は、次のルールを作成します。
ユーザーが社内ネットワークの外部にいる場合は、認証に成功し、適切な権限を持っていても、アクセスは拒否されます。

API を呼び出すすべてのユーザーのアクセスを拒否する

たとえば、API を呼び出しているすべてのユーザーのアクセスを拒否したいとします。つまり、API の audience の値に基づいてアクセスを拒否する必要があります。この値は、Dashboard > Applications > APIs の API にある API フィールドで確認できます。これを行うには、次の ルール を作成します。
この場合、API の audience 値は http:://todoapi2.api であるため、このオーディエンスを拒否します。誰かがこの audience 値を使用して API へのアクセスを試みた場合、アクセスは拒否され、HTTP 401 レスポンスが返されます。

トークンにユーザーのロールを追加する

API の RBAC を有効化し、あわせて “Add Permissions in the Access Token” も有効にするか (または を使用して RBAC を有効にし、Token Dialectaccess_token_authz に設定すると) 、アクセストークンにユーザーの権限が含まれるようになります。トークンにユーザーのロールを追加するには、次の ルール を作成するときに context.authorization オブジェクトを使用します。

Authorization Core 機能セットを使用して Delegated Administration Extension のロールを管理する

Delegated Administration Extension (DAE) と Authorization Core 機能セットは完全に別個の機能ですが、ルールを使用することで、Authorization Core 機能セットを使って DAE のロールを作成および管理できます。
  1. Authorization Core 機能セットを使用して DAE ロールを作成します。作成するロールの名前は、事前定義された DAE ロールの名前と一致している必要があります。
  2. Authorization Core 機能セットを使用して、作成した DAE ロールを適切なユーザーに割り当てます
  3. ユーザーのロールを IDトークンの DAE 名前空間に追加します。そのためには、次のルールを作成し、CLIENT_ID プレースホルダーの値をアプリケーションのクライアントIDに置き換えてください。
Auth0 は、OpenID Connect (OIDC) 仕様で定義された構造化クレーム形式でプロファイル情報を返します。つまり、IDトークンまたはアクセストークンに追加するカスタムクレームは、競合の可能性を避けるため、ガイドラインと制限事項に準拠する必要があります。