Gestion des permissions dans les Actions

Utilisez les méthodes api.transaction.* pour modifier les permissions cibles dans les Actions Post Login et Credentials Exchange. Avant d’émettre les jetons, Auth0 évalue les permissions obtenues en fonction des politiques d’autorisation applicables. Post Login permet également de modifier directement le jeton d’accès avec api.accessToken.addScope() et removeScope(), sans passer par l’évaluation des politiques d’autorisation. Ces méthodes indépendantes ne sont pas offertes dans Credentials Exchange.

Fonctionnement des permissions cibles

event.transaction.target_scopes contient l’ensemble cible actuel de permissions, qui est filtré par les politiques d’autorisation après l’exécution des Actions afin de déterminer les permissions finales accordées. event.transaction.target_scopes contient initialement les permissions demandées dans Post Login ou les permissions autorisées de l’application pour l’API cible dans Credentials Exchange. Les modifications s’accumulent d’une Action à l’autre. Chaque méthode de permissions cibles met immédiatement à jour event.transaction.target_scopes, autant dans l’Action en cours que dans les Actions subséquentes de la même transaction. event.transaction.requested_scopes demeure inchangé. Lisez l’ensemble cible à partir de l’événement, puis modifiez-le au moyen des méthodes de l’API :

Méthode	Effet	Référence de l’API
`addTargetScope(scope)`	Ajoute une permission.	Post Login, Credentials Exchange
`removeTargetScope(scope)`	Retire une permission.	Post Login, Credentials Exchange
`setTargetScopes(scopes)`	Remplace l’ensemble au complet.	Post Login, Credentials Exchange
`clearTargetScopes()`	Vide l’ensemble.	Post Login, Credentials Exchange

Auth0 évalue l’ensemble cible final en fonction des politiques d’autorisation une fois toutes les Actions terminées. Les ajouts non autorisés sont ignorés sans avertissement. Les permissions retirées ne sont pas appliquées, à moins qu’une opération ultérieure ne les rétablisse ou ne remplace l’ensemble.

Les quatre méthodes s’appliquent aux permissions de l’API, aux permissions OIDC et aux permissions du jeton d’actualisation, y compris openid, profile et offline_access, selon les capacités du flux. L’ajout ou le retrait de ces permissions peut modifier l’émission des jetons ou les renseignements du profil.setTargetScopes() et clearTargetScopes() remplacent l’ensemble au complet; elles peuvent donc aussi retirer des permissions par inadvertance. Retirer ou omettre openid peut empêcher l’émission du jeton d’ID; retirer ou omettre offline_access peut empêcher l’émission du jeton d’actualisation. Utilisez removeTargetScope() pour retirer une seule permission précise.

Les contrôles existants s’appliquent toujours :

Accès des applications : les politiques d’accès aux API et les autorisations client, y compris les autorisations tierces par défaut.
Autorisations des utilisateurs : lorsque le RBAC est activé, Auth0 vérifie les rôles et les autorisations attribuées directement. Pour les connexions d’Organization, ce sont les rôles de l’utilisateur dans cette Organization qui sont utilisés.
Consentement : lorsque le consentement est requis, toutes les permissions qui restent après le filtrage des autorisations figurent dans l’invite de consentement, y compris celles ajoutées par des Actions. Les permissions retirées de l’ensemble cible final ou rejetées par une politique ne sont pas affichées. Le fait d’effacer les permissions ne permet pas de contourner le consentement.

Credentials Exchange n’implique ni utilisateur ni consentement de l’utilisateur. Son ensemble cible est croisé avec l’autorisation client. Les méthodes de permissions cibles sont les seules méthodes qui permettent d’y modifier les permissions : api.accessToken.addScope() et removeScope() ne sont pas disponibles.

Exemples

Ajouter une permission dans le respect des politiques d’autorisation

Ajoutez l’accès en lecture aux rapports, sous réserve des politiques applicables et de tout consentement requis :

exports.onExecutePostLogin = async (event, api) => {
  api.transaction.addTargetScope('read:reports');
};

Retirer l’accès en écriture pour les transactions à risque

Retirez l’accès en écriture lorsqu’Auth0 détecte un déplacement impossible entre deux connexions consécutives. Les autres permissions ciblées demeurent inchangées. Pour en apprendre davantage sur les codes d’évaluation, consultez Personnaliser Adaptive MFA.

exports.onExecutePostLogin = async (event, api) => {
  const travel = event.authentication?.riskAssessment?.assessments?.ImpossibleTravel;
  if (travel?.code === 'impossible_travel_from_last_login') {
    api.transaction.removeTargetScope('write:reports');
  }
};

Retirer l’accès administrateur pour les requêtes déléguées

Utilisez event.transaction.actor pour détecter une requête déléguée, quel que soit le flux ayant fourni l’actor. Retirez l’accès administrateur sans modifier les autres permissions, y compris openid :

exports.onExecutePostLogin = async (event, api) => {
  if (event.transaction?.actor) {
    api.transaction.removeTargetScope('admin:reports');
  }
};

Appliquer des modifications d’une Action à l’autre

Pour une requête comportant write:reports, l’Action 1 ajoute l’accès en lecture. L’événement affiche aussitôt les deux permissions :

Action 1

exports.onExecutePostLogin = async (event, api) => {
  api.transaction.addTargetScope('read:reports');
  console.log(event.transaction.target_scopes);
  // ['write:reports', 'read:reports']
};

L’Action 2 reçoit cet ensemble cumulé et retire l’accès en écriture :

Action 2

exports.onExecutePostLogin = async (event, api) => {
  api.transaction.removeTargetScope('write:reports');
  console.log(event.transaction.target_scopes);
  // ['read:reports']
};

Auth0 évalue ensuite read:reports. Sa présence dans l’ensemble cible n’en garantit pas l’émission.

Limiter l’accès de communication entre machines à l’écriture de rapports

Ne conservez que l’accès en écriture dans Credentials Exchange. La permission doit tout de même être autorisée par l’autorisation client :

exports.onExecuteCredentialsExchange = async (event, api) => {
  api.transaction.setTargetScopes(['write:reports']);
};

Modifier directement les permissions du jeton d’accès

Pour les applications internes, Post Login permet de modifier directement le jeton au moyen de api.accessToken.addScope() et de removeScope(). Ces deux méthodes s’exécutent après l’autorisation, sans passer par le RBAC, la politique d’accès de l’application ni l’évaluation du consentement. Ni l’une ni l’autre ne modifie event.transaction.target_scopes. addScope() ajoute une permission sans effectuer ces vérifications et sans l’afficher sur l’écran de consentement. removeScope() ne fait que restreindre le jeton d’accès final; la permission demeure affichée dans l’invite de consentement. Faites ces modifications directes en connaissance de cause, avec des valeurs de permissions fiables et le public d’API attendu. Les modifications apportées aux permissions cibles ne peuvent pas annuler un ajout forcé :

exports.onExecutePostLogin = async (event, api) => {
  if (event.resource_server?.identifier === 'https://example.com/api') {
    api.accessToken.addScope('audit:reports');
    api.transaction.removeTargetScope('audit:reports');
  }
};

audit:reports se retrouve tout de même dans le jeton d’accès, même s’il ne figure ni dans l’ensemble cible ni sur l’écran de consentement. Ce comportement s’applique à toutes les Actions, peu importe l’ordre des appels.

Les applications tierces ne prennent pas en charge api.accessToken.addScope(); les ajouts ne peuvent donc pas contourner les autorisations de l’application ni le consentement. removeScope() demeure disponible, puisqu’elle ne fait que réduire l’accès. Utilisez les méthodes de permissions cibles si vous voulez que les modifications se reflètent à la fois dans l’autorisation et dans le consentement.

Flux pris en charge

Flux	Comportement
Code d’autorisation, implicite, hybride	Pris en charge.
Mot de passe du propriétaire de la ressource, domaine de mot de passe, OTP sans mot de passe	Pris en charge.
Échange de jeton d’actualisation hors ligne	Pris en charge. Part des permissions de l’échange ou, si elles sont omises, de l’ensemble accordé précédemment. Les limites d’autorisation du jeton d’actualisation continuent de s’appliquer.
Autorisation d’appareil	Pris en charge.
MFA (OTP, hors bande, code de récupération), clé d’identification / WebAuthn	Pris en charge.
Échange de jetons (Échange personnalisé de jetons, au nom de, connexion sociale native)	Pris en charge.
Cross App Access (ID-JAG)	Pris en charge.
Canal de lien Web CIBA	Pris en charge.
Identifiants du client	Pris en charge au moyen des Actions Credentials Exchange.
Canal de notification poussée MFA CIBA	Les modifications sont ignorées.
SAML, WS-Fed, anciens points de terminaison, ancien modèle d’autorisation	Les modifications sont ignorées.
Échange de jeton d’accès de connexion fédérée Token Vault	Les méthodes de permissions cibles génèrent une erreur.

Pour les Actions partagées, n’appelez pas les méthodes de permissions cibles lorsque event.transaction.protocol === 'oauth2-token-exchange-federated-connection'. Ne vous fiez pas aux modifications des permissions cibles pour restreindre les flux non pris en charge.

Personnalisation de l’image de marque

Personnalisation du code

Personnalisation par des tiers

Gestion des permissions dans les Actions

Fonctionnement des permissions cibles

Exemples

Ajouter une permission dans le respect des politiques d’autorisation

Retirer l’accès en écriture pour les transactions à risque

Retirer l’accès administrateur pour les requêtes déléguées

Appliquer des modifications d’une Action à l’autre

Limiter l’accès de communication entre machines à l’écriture de rapports

Modifier directement les permissions du jeton d’accès

Flux pris en charge

En savoir plus

​Fonctionnement des permissions cibles

​Autorisation et consentement

​Exemples

​Ajouter une permission dans le respect des politiques d’autorisation

​Retirer l’accès en écriture pour les transactions à risque

​Retirer l’accès administrateur pour les requêtes déléguées

​Appliquer des modifications d’une Action à l’autre

​Limiter l’accès de communication entre machines à l’écriture de rapports

​Modifier directement les permissions du jeton d’accès

​Flux pris en charge

​En savoir plus

Fonctionnement des permissions cibles

Autorisation et consentement

Exemples

Ajouter une permission dans le respect des politiques d’autorisation

Retirer l’accès en écriture pour les transactions à risque

Retirer l’accès administrateur pour les requêtes déléguées

Appliquer des modifications d’une Action à l’autre

Limiter l’accès de communication entre machines à l’écriture de rapports

Modifier directement les permissions du jeton d’accès

Flux pris en charge

En savoir plus