> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Aprenda a usar Rules con el control de acceso basado en roles (RBAC). Para usarlo con nuestro conjunto de funciones Authorization Core.

# Casos de uso de ejemplo: Rules con Authorization

<Warning>
  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](/es/docs/customize/actions/actions-overview).

  Para ayudarle con la migración, ofrecemos guías que le ayudarán a [migrar de Rules a Actions](/es/docs/customize/actions/migrate/migrate-from-rules-to-actions) y [migrar de Hooks a Actions](/es/docs/customize/actions/migrate/migrate-from-hooks-to-actions). También tenemos una página dedicada, [Move to Actions](https://auth0.com/extensibility/movetoactions), que destaca comparaciones de funciones, [una demostración de Actions](https://www.youtube.com/watch?v=UesFSY1klrI) 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](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/).
</Warning>

Con [Rules](/es/docs/customize/rules), puede modificar o complementar el resultado de la decisión tomada por la [política de autorización](/es/docs/manage-users/access-control/authorization-policies) preconfigurada para manejar casos más complejos de lo que permite por sí solo el [control de acceso basado en roles (RBAC)](/es/docs/manage-users/access-control/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 <Tooltip tip="Token de acceso: Credencial de autorización, en forma de una cadena opaca o JWT, utilizada para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=Access+Token">Token de acceso</Tooltip>. También pueden permitirle personalizar el contenido de sus tokens.

<div id="allow-access-only-on-weekdays-for-a-specific-application">
  ## Permitir el acceso solo entre semana a una aplicación específica
</div>

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](/es/docs/customize/rules/create-rules):

```js lines theme={null}
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.

<div id="allow-access-only-to-users-who-are-inside-the-corporate-network">
  ## Permita el acceso solo a usuarios que estén dentro de la red corporativa
</div>

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:

```js lines theme={null}
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.

<div id="deny-access-to-anyone-calling-an-api">
  ## Deniega el acceso a cualquiera que llame a una API
</div>

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 <Tooltip tip="Audiencia: identificador único de la audiencia de un token emitido. Se denomina aud en un token; su valor contiene el ID de una aplicación (ID de cliente) para un ID Token o de una API (identificador de API) para un Token de acceso." cta="Ver glosario" href="/es/docs/glossary?term=Audience">Audiencia</Tooltip>** de tu API en [Dashboard > Applications > APIs](https://manage.auth0.com/#/apis). Para ello, crearías la siguiente regla:

```js lines theme={null}
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`.

<div id="add-user-roles-to-tokens">
  ## Agregar roles de usuario a los tokens
</div>

Si [habilita RBAC para las APIs](/es/docs/get-started/apis/enable-role-based-access-control-for-apis) junto con "Add Permissions in the Access Token" (o habilita RBAC mediante la <Tooltip tip="Management API: un producto que permite a los clientes realizar tareas administrativas." cta="Ver glosario" href="/es/docs/glossary?term=Management+API">Management API</Tooltip> 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:

```js lines theme={null}
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);
}
```

<div id="manage-delegated-administration-extension-roles-using-the-authorization-core-feature-set">
  ## Administre los roles de Delegated Administration Extension con el conjunto de funciones de Authorization Core
</div>

Aunque [Delegated Administration Extension (DAE)](/es/docs/customize/extensions/delegated-administration-extension) 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](/es/docs/manage-users/access-control/configure-core-rbac/roles/create-roles) 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](/es/docs/customize/extensions/delegated-administration-extension#assign-roles-to-users).
2. [Asigne los roles de DAE que creó a los usuarios correspondientes](/es/docs/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-users) 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](/es/docs/customize/rules/create-rules) y recuerde reemplazar el valor del marcador de posición `CLIENT_ID` por el ID de cliente de su aplicación:

```js lines theme={null}
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);
}
```

<Warning>
  Auth0 devuelve la información del perfil en un formato estructurado de claims, tal como lo define la [especificación OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Esto significa que los claims personalizados añadidos a los ID Token o los tokens de acceso deben [ajustarse a las directrices y restricciones](/es/docs/secure/tokens/json-web-tokens/create-custom-claims) para evitar posibles conflictos.
</Warning>