メインコンテンツへスキップ
RulesとHooksのサポート終了（EOL）日は2026年11月18日 であり、2023年10月16 日の時点で作成された新しいテナントは使用できなくなります。Hooksが有効な既存のテナントは、サポート終了までHooksを利用できます。今後はActionsに移行して、Auth0の機能を拡張することを強くお勧めします。Actionsを使用すると、豊富な情報やインラインドキュメント、パブリックnpmパッケージにアクセスして、外部統合を使って全体的な拡張エクスペリエンスを強化することができます。Actionsの詳細については、「Auth0 Actionsの仕組みを理解する」をお読みください。当社では、移行の参考資料として、RulesからActionsへの移行とHooksからActionsへの移行に関するガイドを提供しています。また、専用の「Actionsへの移行」ページでは、機能の比較やActionsのデモ、その他のリソースを掲載して、円滑な移行をサポートしています。RulesとHooksの廃止の詳細については、当社のブログ記事「RulesとHooksの提供終了について」をお読みください。
ルールを使うことで、事前構成された認可ポリシーの決定結果を修正または補完できるため、Role-based Access Control（RBAC）だけでは対応できないより複雑なケースを処理することができます。ルールは実行順序に基づいて、アクセストークンにアクセス許可が追加される前に、認可での決定を変更することができます。また、トークンの内容をカスタマイズすることもできます。

​
特定のアプリケーションに平日のみのアクセスを許可する

たとえば、平日のみにアクセスを許可したいアプリケーションがあるとします。これを行うには、以下のルールを作成します。 
function (user, context, callback) {

  if (context.clientName === 'APP_NAME') {
    const d = Date.getDay();

    if (d === 0 || d === 6) {
      return callback(new UnauthorizedError('This app is only available during the week.'));
    }
  }

  callback(null, user, context);
}
ユーザーが週末にアプリケーションにアクセスしようとした場合には、たとえ認証され、適切な権限があったとしても、アクセスが拒否されます。

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

たとえば、アプリケーションへのアクセスを許可するのに、企業ネットワークの内側からアクセスするユーザーに限定したいとします。これを行うには、以下のルールを作成します。 
function (user, context, callback) {
  const ipaddr = require('ipaddr.js@1.9.0');
  const corp_network = "192.168.1.134/26";
  const current_ip = ipaddr.parse(context.request.ip);

  if (!current_ip.match(ipaddr.parseCIDR(corp_network))) {
    return callback(new UnauthorizedError('This app is only available from inside the corporate network.'));
  };

  callback(null, user, context);
}
ユーザーが企業ネットワークの外側にいる場合には、たとえ認証に成功して、適切な権限があったとしても、アクセスが拒否されます。

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

たとえば、APIを呼び出すユーザーのすべてに対して、アクセスを拒否したいとします。つまり、［Dashboard］ > ［Applications（アプリケーション）］ > ［APIs］のAPIオーディエンス フィールドに記載されたAPIのオーディエンスの値に基づいてアクセスを拒否する必要があります。これを行うには、以下のルールを作成します。 
function (user, context, callback) {
  /*
   *  Denies access to user-based flows based on audience
   */
  var audience = '';
  audience = audience
              || (context.request && context.request.query && context.request.query.audience)
              || (context.request && context.request.body && context.request.body.audience);
  if (audience === 'http://todoapi2.api' || !audience) {
    return callback(new UnauthorizedError('end_users_not_allowed'));
  }
  return callback(null, user, context);
}
この場合、APIのオーディエンスの値はhttp:://todoapi2.apiであり、これが拒否する対象となるオーディエンスです。誰かがこのオーディエンス値でAPIへのアクセスを試みた場合、アクセスが拒否され、HTTP 401応答を受け取ります。

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

「Add Permissions in the （アクセストークンに許可を追加）」と一緒にAPIのRBACを有効にした場合（またはを介してRBACを有効にし、［Token Dialect（トークンダイアレクト）］ をaccess_token_authzに設定した場合）、アクセストークンでユーザー権限を受け取ります。ユーザーのロールをトークンに追加するには、以下のルールを作成するときにcontext.authorizationオブジェクトを使用します。 
function (user, context, callback) {
  const namespace = 'http://demozero.net';
  const assignedRoles = (context.authorization || {}).roles;

  let idTokenClaims = context.idToken || {};
  let accessTokenClaims = context.accessToken || {};

  idTokenClaims[`${namespace}/roles`] = assignedRoles;
  accessTokenClaims[`${namespace}/roles`] = assignedRoles;

  context.idToken = idTokenClaims;
  context.accessToken = accessTokenClaims;

  callback(null, user, context);
}

​
Authorization Core（認可コア）機能セットでDelegated Administration Extension（DAE、委任管理拡張機能）を管理する

Delegated Administration Extension（DAE：委任管理拡張機能）とAuthorization Core（認可コア）は全く別の機能ですが、ルールを使用する場合、Authorization Core（認可コア）機能セットを使用すると、DAEのロールを作成し、管理することができます。
  1. Authorization Core（認可コア）機能セットを使用してDAEロールを作成します。作成したロールの名前は必ず、あらかじめ定義されたDAEロールと一致しなければなりません。
  2. Authorization Core（認可コア）機能セットを使用して、作成したDAEロールを適切なユーザーに割り当てます。
  3. ユーザーのロールをIDトークンにあるDAEの名前空間に追加します。これを行うには、以下のルールを作成します。CLIENT_IDプレースホルダー値をアプリケーションのクライアントIDに置き換えることを忘れないでください。 
    function (user, context, callback) {
    if (context.clientID === 'CLIENT_ID') {
        const namespace = 'https://example.com/auth0-delegated-admin';
        context.idToken[namespace] = {
            roles: (context.authorization || {}).roles
        };
    }
    callback(null, user, context);
}
    Auth0は、プロファイル情報をOpenID Connect（OIDC）仕様で定義されている構造化クレーム形式で返します。つまり、IDトークンまたはアクセストークンに追加するカスタムクレームは、衝突を避けるためにガイドラインと制限に従わなければなりません。