Skip to main content
Le déclencheur post-login s’exécute lorsqu’un utilisateur s’authentifie avec succès auprès d’une application dans un tenant Auth0, notamment après une inscription, ou lorsqu’un est échangé.
Schéma illustrant le Login Flow des Actions.
Les Actions de ce flow sont bloquantes (synchrones) : elles s’exécutent dans le cadre du processus du déclencheur et empêchent le reste du pipeline Auth0 de s’exécuter jusqu’à ce que l’Action soit terminée.

Références

  • Objet Event : fournit des renseignements contextuels sur un utilisateur qui se connecte à l’aide d’Auth0.
  • Objet API : fournit des méthodes pour modifier le comportement du flux.

Cas d’utilisation courants

Contrôle d’accès

Vous pouvez utiliser une Action post-login pour mettre en œuvre une logique personnalisée afin de rejeter l’accès d’un utilisateur qui tente d’accéder à une application :

Autoriser l’accès à une application précise uniquement les jours de semaine

Si vous avez une application à laquelle vous souhaitez limiter l’accès aux jours de semaine, vous pouvez créer l’Action suivante :

Rejeter l’accès à toute personne qui appelle une API

Supposons que vous souhaitiez rejeter l’accès à tous les utilisateurs qui appellent une API. Vous devez alors rejeter l’accès en fonction de la valeur de l’ de votre API, que vous trouverez dans le champ API Audience de votre API, sous Dashboard > Applications > APIs. Pour ce faire, créez l’Action suivante :

Ajouter les rôles utilisateur aux jetons d’ID et d’accès

Pour ajouter des rôles utilisateur aux jetons émis par Auth0, utilisez l’objet event.authorization ainsi que les méthodes api.idToken.setCustomClaim et api.accessToken.setCustomClaim :
  • Une revendication personnalisée ne peut pas inclure certains termes. Nous recommandons fortement d’utiliser une revendication avec espace de noms sous la forme d’un URI. Pour en savoir plus, consultez Create Custom Claims.
  • Le renvoyé à l’application demandeuse est créé et signé à la fin du traitement du déclencheur. Le JWT final signé n’est pas accessible dans une Action.

Enrichir le profil utilisateur

Auth0 offre un système permettant de stocker des métadonnées dans un profil utilisateur. Pour définir user_metadata ou app_metadata dans le profil d’un utilisateur lors de sa connexion, utilisez les fonctions api.user.setUserMetadata ou api.user.setAppMetadata :
Une fois toutes les Actions post-connexion exécutées, le profil utilisateur sera mis à jour en une seule opération. Cette opération est soumise à la limite de débit “Write Users” rate limit.

Appliquer une politique MFA personnalisée

Une Action post-login peut servir à exiger dynamiquement la pour un utilisateur selon les besoins de votre application :
Un fournisseur MFA doit être configuré pour activer l’authentification multifacteur lors d’une connexion. Pour en savoir plus, consultez l’authentification multifacteur.

Réduire les frictions grâce aux passkeys

Une Action post-login peut réduire les frictions en contournant dynamiquement la MFA pour un utilisateur qui s’est authentifié à l’aide d’une passkey :
La connexion doit avoir les passkeys et la MFA activées. Pour en savoir plus, consultez Passkeys et Multi-Factor Authentication.

Rediriger l’utilisateur vers un site externe

À l’instar des Redirect Rules, une Action post-login peut être utilisée pour rediriger l’utilisateur vers un site externe. Une fois l’opération terminée, l’utilisateur peut être redirigé vers Auth0 pour poursuivre son login flow. Dans l’exemple ci-dessous, une Redirect Action invite l’utilisateur à indiquer sa couleur préférée :
Le pipeline Actions est suspendu pendant la redirection de l’utilisateur. Lorsque l’utilisateur poursuit son processus de connexion à Auth0, le pipeline Actions reprend là où il a été suspendu. Les Actions exécutées avant la redirection ne sont pas exécutées de nouveau. Pour en savoir plus sur les Actions de redirection, consultez Redirection avec Actions.

Modifier les permissions d’un jeton d’accès

Utilisez api.transaction.addTargetScope() et removeTargetScope() pour modifier les permissions sans contourner l’autorisation. Les modifications s’accumulent d’une Action à l’autre, et event.transaction.target_scopes reflète immédiatement l’ensemble en vigueur. Auth0 vérifie ensuite que l’ensemble final respecte les politiques applicables et les exigences de consentement :
Pour en apprendre davantage, notamment sur la façon dont les ajouts et les suppressions interagissent avec le reste du pipeline d’autorisation, consultez Gestion des permissions dans les Actions.

Forcer l’ajout d’une permission en contournant l’autorisation

api.accessToken.addScope() ajoute une permission directement au jeton d’accès après l’autorisation. Cette méthode contourne le RBAC, les politiques d’accès de l’application et le consentement, sans mettre à jour les permissions cibles. Réservez-la aux contournements délibérés, avec des entrées fiables et le public d’API prévu :
api.accessToken.addScope() n’est pas pris en charge pour les applications tierces strictes. La modification des permissions cibles ne permet pas d’annuler une permission ajoutée de force au moyen de cette méthode. api.accessToken.removeScope() retire une permission du jeton d’accès après l’autorisation, sans modifier l’ensemble cible.

Rejeter l’accès en fonction d’empreintes JA3/JA4 précises

L’objet event.security_context contient les valeurs d’empreinte JA3/JA4 de la transaction en cours :

En savoir plus