Saltar al contenido principal
La fecha de fin de vida útil (EOL) de Rules y Hooks será el 18 de noviembre de 2026, y ya no están disponibles para nuevos inquilinos creados a partir del 16 de octubre de 2023. Los inquilinos existentes con Hooks activos conservarán el acceso al producto Hooks hasta su fin de vida útil.Recomendamos encarecidamente que use Actions para ampliar Auth0. Con Actions, tiene acceso a información de tipos completa, documentación integrada y paquetes públicos de npm, y puede conectar integraciones externas que mejoran su experiencia general de extensibilidad. Para obtener más información sobre lo que ofrece Actions, lea Understand How Auth0 Actions Work.Para ayudarle con la migración, ofrecemos guías que le ayudarán a migrar de Rules a Actions y migrar de Hooks a Actions. También tenemos una página dedicada, Move to Actions, que destaca comparaciones de funciones, una demostración de Actions y otros recursos para ayudarle en su proceso de migración.Para obtener más información sobre la desaprobación de Rules y Hooks, lea nuestra entrada de blog: Preparing for Rules and Hooks End of Life.
Con Rules, puede modificar o complementar el resultado de la decisión tomada por la política de autorización preconfigurada para manejar casos más complejos de lo que permite por sí solo el control de acceso basado en roles (RBAC). Según el orden en que se ejecuten, las Rules pueden cambiar el resultado de la decisión de autorización antes de que los permisos se agreguen al . También pueden permitirle personalizar el contenido de sus tokens.

Permitir el acceso solo entre semana a una aplicación específica

Supongamos que tiene una aplicación y quiere asegurarse de que solo se pueda acceder a ella entre semana. Para ello, cree la siguiente regla:
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);
}
Si un usuario intenta acceder a la aplicación durante el fin de semana, se le denegará el acceso, aunque se autentique y tenga los privilegios adecuados.

Permita el acceso solo a usuarios que estén dentro de la red corporativa

Supongamos que quiere permitir el acceso a una aplicación, pero solo a los usuarios que acceden a ella desde dentro de su red corporativa. Para ello, cree la siguiente regla:
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);
}
Si el usuario está fuera de la red corporativa, se le denegará el acceso aunque se autentique correctamente y tenga los privilegios adecuados.

Deniega el acceso a cualquiera que llame a una API

Supongamos que quieres denegar el acceso a todos los usuarios que llaman a una API. Esto significa que debes denegar el acceso en función del valor de audience de tu API, que puedes encontrar en el campo API de tu API en Dashboard > Applications > APIs. Para ello, crearías la siguiente regla:
function (user, context, callback) {
  /*
   *  Deniega el acceso a flujos basados en usuario según la audiencia
   */
  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);
}
En este caso, el valor de audience para la API es http:://todoapi2.api, por lo que esta es la audiencia que rechazaremos. Si alguien intenta acceder a la API con este valor de audience, se le denegará el acceso y recibirá una respuesta HTTP 401.

Agregar roles de usuario a los tokens

Si habilita RBAC para las APIs junto con “Add Permissions in the Access Token” (o habilita RBAC mediante la y configura Token Dialect como access_token_authz), recibirá permisos del usuario en sus Tokens de acceso. Para agregar roles de usuario a los tokens, debe usar el objeto context.authorization al crear la siguiente regla:
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);
}

Administre los roles de Delegated Administration Extension con el conjunto de funciones de Authorization Core

Aunque Delegated Administration Extension (DAE) y el conjunto de funciones de Authorization Core son características completamente independientes, puede usar el conjunto de funciones de Authorization Core para crear y administrar roles para DAE si utiliza una regla.
  1. Cree roles de DAE con el conjunto de funciones de Authorization Core. Los nombres de los roles que cree deben coincidir con los nombres de los roles de DAE predefinidos.
  2. Asigne los roles de DAE que creó a los usuarios correspondientes con el conjunto de funciones de Authorization Core.
  3. Agregue los roles de usuario al espacio de nombres de DAE en el ID Token. Para hacerlo, cree la siguiente regla y recuerde reemplazar el valor del marcador de posición CLIENT_ID por el ID de cliente de su aplicación:
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 devuelve la información del perfil en un formato estructurado de claims, tal como lo define la especificación OpenID Connect (OIDC). Esto significa que los claims personalizados añadidos a los ID Token o los tokens de acceso deben ajustarse a las directrices y restricciones para evitar posibles conflictos.