> ## 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.

> Découvrez comment utiliser les Rules avec le contrôle d’accès basé sur les rôles (RBAC). À utiliser avec notre ensemble de fonctionnalités Authorization Core.

# Exemples de cas d’utilisation : Rules avec Authorization

<Warning>
  La date de fin de vie (EOL) de Rules et Hooks est fixée au **18 novembre 2026**, et ils ne sont plus offerts aux nouveaux tenants créés à compter du **16 octobre 2023**. Les tenants existants avec des Hooks actifs conserveront l’accès à Hooks jusqu’à la fin de vie.

  Nous vous recommandons fortement d’utiliser Actions pour étendre Auth0. Avec Actions, vous avez accès à des renseignements de type détaillés, à de la documentation intégrée et à des packages `npm` publics, et vous pouvez connecter des intégrations externes qui améliorent votre expérience globale en matière d’extensibilité. Pour en savoir plus sur ce qu’offre Actions, consultez [Comprendre le fonctionnement d’Auth0 Actions](/docs/fr-ca/customize/actions/actions-overview).

  Pour vous aider dans votre migration, nous proposons des guides qui vous aideront à [passer de Rules à Actions](/docs/fr-ca/customize/actions/migrate/migrate-from-rules-to-actions) et à [passer de Hooks à Actions](/docs/fr-ca/customize/actions/migrate/migrate-from-hooks-to-actions). Nous avons également une page dédiée, [Move to Actions](https://auth0.com/extensibility/movetoactions), qui présente des comparaisons de fonctionnalités, [une démo d’Actions](https://www.youtube.com/watch?v=UesFSY1klrI) et d’autres ressources pour vous accompagner tout au long de votre migration.

  Pour en savoir plus sur la dépréciation de Rules et Hooks, consultez notre article de blogue : [Preparing for Rules and Hooks End of Life](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/).
</Warning>

Avec les [Rules](/docs/fr-ca/customize/rules), vous pouvez modifier ou compléter le résultat de la décision prise par la [politique d’autorisation](/docs/fr-ca/manage-users/access-control/authorization-policies) préconfigurée afin de gérer des cas plus complexes que ce qu’il est possible de faire avec le [contrôle d’accès basé sur les rôles (RBAC)](/docs/fr-ca/manage-users/access-control/rbac) à lui seul. Selon l’ordre dans lequel elles s’exécutent, les Rules peuvent modifier le résultat de la décision d’autorisation avant que les autorisations ne soient ajoutées au <Tooltip tip="Jeton d’accès : justificatif d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Access+Token">jeton d’accès</Tooltip>. Elles vous permettent aussi de personnaliser le contenu de vos jetons.

<div id="allow-access-only-on-weekdays-for-a-specific-application">
  ## Autoriser l’accès à une application précise uniquement les jours de semaine
</div>

Supposons que vous ayez une application à laquelle vous voulez limiter l’accès aux jours de semaine. Pour ce faire, [créez la règle suivante](/docs/fr-ca/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 utilisateur tente d’accéder à l’application pendant la fin de semaine, l’accès lui sera refusé, même s’il s’authentifie et qu’il possède les privilèges appropriés.

<div id="allow-access-only-to-users-who-are-inside-the-corporate-network">
  ## Autoriser l’accès uniquement aux utilisateurs se trouvant à l’intérieur du réseau d’entreprise
</div>

Supposons que vous souhaitiez autoriser l’accès à une application, mais uniquement aux utilisateurs qui y accèdent depuis l’intérieur de votre réseau d’entreprise. Pour ce faire, vous créeriez la règle suivante :

```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 l’utilisateur se trouve à l’extérieur du réseau d’entreprise, l’accès lui sera refusé même s’il réussit à s’authentifier et qu’il dispose des privilèges appropriés.

<div id="deny-access-to-anyone-calling-an-api">
  ## Rejeter l’accès à quiconque appelle une API
</div>

Supposons que vous souhaitiez rejeter l’accès à tous les utilisateurs qui appellent une API. Cela signifie que vous devez rejeter l’accès en fonction de la valeur `audience` de votre API, que vous trouverez dans le champ **Audience de l’API <Tooltip tip="Audience : identifiant unique de l’audience d’un jeton émis. Nommée aud dans un jeton, sa valeur contient l’ID d’une application (Client ID) pour un ID Token, ou d’une API (identifiant de l’API) pour un jeton d’accès." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Audience">Audience</Tooltip>** de votre API dans [Dashboard > Applications > APIs](https://manage.auth0.com/#/apis). Pour ce faire, vous créeriez la règle suivante :

```js lines theme={null}
function (user, context, callback) {
  /*
   *  Refuse l'accès aux flux basés sur les utilisateurs selon l'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);
}
```

Dans ce cas, la valeur `audience` de l’API est `http:://todoapi2.api`; c’est donc cette audience que nous refuserons. Si quelqu’un tente d’accéder à l’API avec cette valeur `audience`, l’accès lui sera refusé et il recevra une réponse `HTTP 401`.

<div id="add-user-roles-to-tokens">
  ## Ajouter les rôles d’un utilisateur aux jetons
</div>

Si vous [activez RBAC pour les API](/docs/fr-ca/get-started/apis/enable-role-based-access-control-for-apis) et l’option "Ajouter les autorisations dans le jeton d’accès" (ou si vous activez RBAC au moyen de l’<Tooltip tip="Management API : un produit qui permet aux clients d’effectuer des tâches administratives." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Management+API">Management API</Tooltip> et définissez le **Dialecte du jeton** sur `access_token_authz`), vous recevrez les autorisations de l’utilisateur dans vos jetons d’accès. Pour ajouter les rôles d’un utilisateur aux jetons, utilisez l’objet `context.authorization` lorsque vous créez la règle suivante :

```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">
  ## Gérer les rôles de Delegated Administration Extension à l’aide de l’ensemble de fonctionnalités Authorization Core
</div>

Bien que la [Delegated Administration Extension (DAE)](/docs/fr-ca/customize/extensions/delegated-administration-extension) et l’ensemble de fonctionnalités Authorization Core soient deux fonctionnalités entièrement distinctes, vous pouvez utiliser l’ensemble de fonctionnalités Authorization Core pour créer et gérer des rôles pour la DAE si vous utilisez une règle.

1. [Créez des rôles DAE](/docs/fr-ca/manage-users/access-control/configure-core-rbac/roles/create-roles) à l’aide de l’ensemble de fonctionnalités Authorization Core. Les noms des rôles que vous créez doivent correspondre à ceux des [rôles DAE prédéfinis](/docs/fr-ca/customize/extensions/delegated-administration-extension#assign-roles-to-users).
2. [Attribuez les rôles DAE que vous avez créés aux utilisateurs appropriés](/docs/fr-ca/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-users) à l’aide de l’ensemble de fonctionnalités Authorization Core.
3. Ajoutez les rôles des utilisateurs à l’espace de noms DAE dans l’ID Token. Pour ce faire, [créez la règle suivante](/docs/fr-ca/customize/rules/create-rules), en n’oubliant pas de remplacer la valeur de l’espace réservé `CLIENT_ID` par le Client ID de votre application :

```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 retourne les informations du profil dans un format structuré de claims, tel que défini par la [spécification OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Cela signifie que les custom claims ajoutés aux ID tokens ou aux access tokens doivent [respecter les directives et les restrictions](/docs/fr-ca/secure/tokens/json-web-tokens/create-custom-claims) afin d’éviter d’éventuelles collisions.
</Warning>