Marquez la tentative de connexion en cours comme rejetée. L’utilisateur final ne pourra alors pas terminer
le flux de connexion. Cela n’annulera PAS les autres effets secondaires liés à l’utilisateur (comme les modifications
de métadonnées) demandés par cette action. Le flux de connexion s’arrêtera immédiatement après
l’exécution de cette action, et aucune autre action ne sera exécutée.Paramètres
Une explication compréhensible du rejet de la connexion. Celle-ci peut être affichée
directement dans les interfaces destinées aux utilisateurs finaux.
Demande un défi d’authentification multifacteur à l’aide du facteur fourni et, éventuellement, de facteurs supplémentaires.Lorsqu’un défi d’authentification multifacteur est demandé, les Actions suivantes ne sont pas exécutées tant que l’utilisateur n’y a pas répondu. Un utilisateur aura répondu à l’invitation de vérification dans l’une ou l’autre des situations suivantes :
Il réussit la vérification associée au facteur par défaut.
Il réussit la vérification associée à l’un des facteurs facultatifs décrits dans additionalFactors.
Si l’un des facteurs demandés a déjà été vérifié avec succès dans la transaction en cours, il est ignoré.Si un facteur demandé n’est pas activé dans le tenant, il est ignoré. Si un facteur demandé auquel l’utilisateur ne s’est pas inscrit est demandé, il est ignoré. Si aucun des facteurs demandés n’est activé ou inscrit, la transaction d’authentification échoue (c.-à-d. que la connexion ne se termine pas).
Cette méthode affiche un écran de vérification de facteur si l’utilisateur n’a pas déjà satisfait aux exigences de l’invitation de vérification. Si des additionalFactors sont fournis, l’utilisateur peut sélectionner un autre facteur s’il le souhaite.
Type de facteur d’authentification, par exemple push-notification, phone, email, otp, webauthn-roaming, webauthn-platform et recovery-code.
Valeurs permises : otp, email, webauthn-platform, webauthn-roaming, recovery-code
Options supplémentaires pouvant aussi inclure additionalFactors comme propriété. Les options spécifiques à un facteur (par exemple, otpFallback pour push-notification) doivent être définies dans factor.options.
Facultatif.
Demande un défi d’authentification multifacteur à l’aide de l’un des facteurs fournis (en affichant d’abord un écran de sélection du facteur).Lorsqu’un défi d’authentification multifacteur est demandé, les Actions suivantes ne s’exécutent pas tant que l’utilisateur n’a pas répondu à cette invite. L’utilisateur aura satisfait à l’invite dans l’un ou l’autre des cas suivants :
Il répond avec succès à l’invite associée à l’un des facteurs.
Si l’un des facteurs demandés a déjà fait l’objet d’une invite réussie dans la transaction en cours, il est ignoré.Si un facteur demandé n’est pas activé dans le tenant, il est ignoré. Si un facteur demandé n’a pas été inscrit par l’utilisateur, il est ignoré. Si aucun des facteurs demandés n’est activé ou inscrit, la transaction d’authentification échoue (c.-à-d. que la connexion ne se termine pas).
Cette méthode affiche l’écran de sélection du facteur si l’utilisateur n’a pas déjà satisfait aux exigences de l’invite. Si un facteur est privilégié, il est préférable d’utiliser la méthode api.authentication.challengeWith(). L’écran de sélection du facteur ne s’affiche pas si un seul facteur est transmis ou valide.
Demande l’inscription à l’authentification multifacteur à l’aide du facteur fourni et de facteurs supplémentaires.Lorsqu’une inscription à l’authentification multifacteur est demandée, les Actions suivantes ne seront exécutées qu’une fois cette inscription
effectuée par l’utilisateur.Si l’un des facteurs demandés a déjà été inscrit ou a fait l’objet d’une demande de vérification réussie dans la transaction en cours, il sera
ignoré.Si un facteur qui n’est pas activé dans le tenant est demandé, il sera ignoré.
Si un facteur auquel l’utilisateur est déjà inscrit est demandé, il sera ignoré.
Si aucun des facteurs demandés n’est à la fois activé et non inscrit, la transaction
d’authentification échouera (c.-à-d. que la connexion ne sera pas terminée).
Type de facteur d’authentification, par exemple push-notification, phone, otp, webauthn-roaming, webauthn-platform ou recovery-code.
Valeurs autorisées : otp, webauthn-platform, webauthn-roaming, recovery-code, push, push-notification
Demande l’inscription à l’authentification multifacteur à l’aide de l’un des facteurs fournis (en affichant d’abord un écran de sélection des facteurs).Lorsqu’une inscription à l’authentification multifacteur est demandée, les Actions suivantes ne s’exécuteront pas tant que l’utilisateur n’aura pas terminé cette inscription.Si l’un des facteurs demandés a déjà été inscrit avec succès dans la transaction en cours, il sera ignoré.Si un facteur qui n’est pas activé dans le tenant est demandé, il sera ignoré.
Si un facteur auquel l’utilisateur est déjà inscrit est demandé, il sera ignoré.
Si aucun des facteurs demandés n’est à la fois activé et non inscrit, la transaction d’authentification échouera (c.-à-d. que la connexion ne se terminera pas).
S’il existe un facteur privilégié, il est préférable d’utiliser la méthode api.authentication.enrollWith(). L’écran de sélection des facteurs ne s’affichera pas si un seul facteur est transmis ou valide.
Indique qu’une méthode d’authentification personnalisée a été complétée au cours de la
session actuelle. Cette méthode sera ensuite disponible dans le tableau
event.authentication.methods lors des prochaines connexions.IMPORTANT : Cette API est accessible uniquement à partir de la fonction
onContinuePostLogin des Actions PostLogin. Autrement dit, elle peut servir à consigner
la complétion d’une méthode d’authentification personnalisée après avoir redirigé l’utilisateur à l’aide de
api.redirect.sendUserTo().Paramètres
Modifiez l’utilisateur principal de la transaction de connexion.Dans les scénarios nécessitant la liaison d’utilisateurs, l’identité utilisée pour amorcer la connexion peut ne plus exister en tant qu’utilisateur distinct. Cette identité peut désormais être une identité secondaire d’un utilisateur existant. Dans de tels cas, la fonction setPrimaryUser() permet d’indiquer que le sujet de la connexion doit être modifié.IMPORTANT : Une liaison de comptes non sécurisée peut permettre à des acteurs malveillants d’accéder à des comptes d’utilisateur légitimes.IMPORTANT : L’identité utilisée pour authentifier la connexion doit faire partie des identités secondaires de l’utilisateur référencé par primary_user_id. Sinon, la connexion échouera et aucun jeton ne sera émis.Paramètres
Activez l’authentification multifacteur pour ce flux de connexion. Une fois activée, les utilisateurs doivent répondre au
défi d’authentification multifacteur configuré. Le défi d’authentification multifacteur proprement dit est reporté à la
fin du flux de connexion.Paramètres
Le nom du fournisseur multifacteur à utiliser ou la valeur "any" pour utiliser n’importe lequel
des fournisseurs configurés.
Valeurs autorisées : none, guardian, google-authenticator, duo, any
Lorsque le fournisseur est défini sur google-authenticator ou duo, l’utilisateur reçoit une invite d’AMF une fois
tous les 30 jours. Lorsque le fournisseur est défini sur guardian, l’invite d’AMF affiche une case à cocher d’inscription
permettant aux utilisateurs de choisir de s’inscrire ou non. La valeur par défaut est false. Pour en savoir plus,
consultez personnaliser les pages d’authentification multifacteur.
Facultatif.
Utilisez un attribut du profil comme nom d’utilisateur dans DuoSecurity. Cela est également utile si vos utilisateurs sont déjà inscrits auprès de Duo.
Facultatif.
Crée un jeton de session pouvant servir de cible de redirection dans un paramètre de chaîne de requête (par l’intermédiaire de sendUserTo),
qui contient des données dont l’authenticité doit pouvoir être vérifiée par le endpoint cible. Le endpoint cible
peut vérifier l’authenticité et l’intégrité des données en vérifiant la signature du JWT
à l’aide d’un secret partagé.Le secret partagé doit être stocké dans un secret de l’Action et peut être lu à l’emplacement
event.secrets['<secret_name>'].Paramètres
Un secret utilisé pour signer un JWT partagé avec la cible de redirection. La
valeur du secret doit être stockée dans un secret et récupérée à l’aide de
event.secrets['<secret_name>'].
Déclenche une redirection du navigateur vers l’url cible dans le pipeline de connexion dès la fin de cette action. La méthode d’assistance createUrl permet de simplifier l’encodage des données sous forme de paramètre de requête dans l’url cible, afin que le endpoint cible puisse en vérifier l’authenticité et l’intégrité.Paramètres
Indique si la transaction actuelle permet de rediriger l’utilisateur. Certains protocoles, comme
oauth2-resource-owner et oauth2-refresh-token, ne prennent pas en charge
la redirection de l’utilisateur. Une requête avec prompt=none ne permet pas non plus de rediriger l’utilisateur.
Récupère les données encodées dans un token JWT transmis au point de terminaison /continue, tout en vérifiant
l’authenticité et l’intégrité de ces données.Paramètres
Définit les métadonnées propres à l’application de l’utilisateur qui se connecte.Remarque : cette méthode ne doit pas être utilisée dans les callbacks. Son appel ne met pas les métadonnées à jour immédiatement.
Vous pouvez l’appeler plusieurs fois dans différentes actions du même flow, et le moteur regroupera les
modifications pour mettre les métadonnées à jour en une seule fois avant la fin du flow. Cette fonction ne fonctionne qu’avec des métadonnées
au format objet.Paramètres
Définit les métadonnées générales de l’utilisateur qui se connecte.Remarque : cette méthode ne doit pas être utilisée dans les callbacks. Son appel ne met pas immédiatement à jour les métadonnées.
Vous pouvez l’appeler plusieurs fois dans différentes actions du même flow; le moteur regroupera les
modifications et mettra à jour les métadonnées en une seule fois avant la fin du flow. Cette fonction ne fonctionne qu’avec des métadonnées au
format objet.Paramètres
Récupère l’enregistrement associé à la clé fournie, s’il existe.
Si un enregistrement est trouvé, la valeur mise en cache se trouve
dans la propriété value de l’objet renvoyé.Paramètres
Stocke ou met à jour une valeur de type chaîne dans le cache à la clé indiquée.Les valeurs stockées dans ce cache sont limitées au Trigger dans lequel elles
sont définies. Elles sont soumises aux limites du cache Actions.Les valeurs stockées de cette façon auront une durée de vie pouvant aller jusqu’aux valeurs
ttl ou expires_at indiquées. Si aucune durée de vie n’est précisée, une durée de vie
par défaut de 15 minutes sera utilisée. Les durées de vie ne peuvent pas dépasser la durée maximale
indiquée dans les limites du cache Actions.Important : Ce cache est conçu pour stocker des données éphémères à courte durée de vie. Les éléments pourraient ne pas être
disponibles lors de transactions ultérieures, même s’ils n’ont pas encore atteint la durée de vie indiquée.Paramètres
La date et l’heure d’expiration absolues, en millisecondes depuis l’époque Unix.
Bien que les enregistrements en cache puissent être évincés plus tôt, ils ne
seront jamais conservés au-delà de la valeur expires_at indiquée.Remarque : Cette valeur ne doit pas être fournie si une valeur a également été
fournie pour ttl. Si les deux options sont fournies, la date d’expiration
la plus rapprochée sera utilisée.
Facultatif.
La durée de vie de cette entrée de cache, en millisecondes.
Bien que les valeurs en cache puissent être évincées plus tôt, elles ne
seront jamais conservées au-delà de la valeur ttl indiquée.Remarque : Cette valeur ne doit pas être fournie si une valeur a également été
fournie pour expires_at. Si les deux options sont fournies, la date d’expiration
la plus rapprochée sera utilisée.
Facultatif.
Destinataire de l’assertion SAML (SubjectConfirmationData).
Par défaut, il s’agit de l’AssertionConsumerUrl de la SAMLRequest ou de l’URL de rappel si aucune SAMLRequest n’a été envoyée.Paramètres
Si la valeur est true (par défaut), Auth0 transmet dans l’assertion de sortie chaque claim qui n’est pas mappé au profil commun.
Si la valeur est false, ces claims ne sont pas mappés.Paramètres
Si passthroughClaimsWithNoMapping est vrai et que cette valeur est fausse (valeur par défaut), Auth0 ajoute le préfixe http://schema.auth0.com à chaque claim qui n’est pas mappé au profil commun.
Si elle est vraie, le claim est transmis tel quel.Paramètres
Si la valeur est true (par défaut), ajoute des renseignements supplémentaires au token, comme le Provider (Google, ADFS, AD, etc.) et le jeton d’accès, s’il est disponible.Paramètres
Destination de la réponse SAML. Si elle n’est pas précisée, la valeur utilisée sera l’AssertionConsumerUrl de SAMLRequest ou l’URL de rappel en l’absence de SAMLRequest.Paramètres
Détermine si la réponse SAML doit être signée.
Par défaut, l’assertion SAML est signée, mais pas la réponse SAML.
Si la valeur est vraie, la réponse SAML est signée plutôt que l’assertion SAML.
La valeur par défaut est faux.Paramètres
Auth0 tentera d’utiliser chacun des attributs de ce tableau, dans l’ordre.
Si l’un d’eux a une valeur, Auth0 l’utilisera comme Subject/NameID.L’ordre est le suivant :
Indique, de façon facultative, le certificat de clé publique utilisé pour valider les requêtes SAML.
S’il est défini, les requêtes SAML devront être signées.
Voici un exemple de valeur : « -----BEGIN CERTIFICATE-----\nMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..toutes les autres lignes..]-----END CERTIFICATE-----\n ».Paramètres
Lorsque cette valeur est définie sur true, le NameFormat est déduit du nom de l’attribut. Les valeurs possibles pour NameFormat sont urn:oasis:names:tc:SAML:2.0:attrname-format:uri, urn:oasis:names:tc:SAML:2.0:attrname-format:basic et urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified.
Lorsqu’elle est définie sur faux, le NameFormat de l’attribut n’est pas inclus dans l’assertion.
La valeur par défaut est true.Paramètres
Lorsque cette option est définie sur true, le xs:type de l’élément est déduit. Les types sont xs:string, xs:boolean, xs:double et xs:anyType.
Lorsqu’elle est définie sur faux, tous les xs:type sont xs:anyType.
La valeur par défaut est true.Paramètres
Spécifiez facultativement un certificat à utiliser pour chiffrer l’assertion SAML.
Le certificat doit être fourni par le fournisseur de services.
Le certificat et la clé publique doivent tous deux être spécifiés.
Voici un exemple de valeur : « -----BEGIN CERTIFICATE-----\nMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..toutes les autres lignes..]-----END CERTIFICATE-----\n ».Paramètres
Vous pouvez spécifier une clé publique servant à chiffrer l’assertion SAML.
La clé publique doit être obtenue auprès du fournisseur de services.
La clé publique et le certificat doivent tous deux être fournis.
Voici un exemple de valeur : “-----BEGIN PUBLIC KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..toutes les autres lignes..]-----END PUBLIC KEY-----\n”.Paramètres
Par défaut, Auth0 utilise la paire de clés privée/publique attribuée à votre tenant pour signer les réponses SAML ou les assertions.
Dans certains scénarios très précis, vous pourriez souhaiter fournir votre propre certificat et votre propre clé privée.Le certificat et la clé privée doivent tous deux être spécifiés.
Voici un exemple de valeur : « -----BEGIN CERTIFICATE-----\nMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..toutes les autres lignes..]-----END CERTIFICATE-----\n ».Paramètres
Par défaut, Auth0 utilise la paire de clés privée/publique attribuée à votre tenant pour signer les réponses SAML ou les assertions.
Dans certains scénarios très précis, vous pourriez souhaiter fournir votre propre certificat et votre propre clé privée.Comme cette clé privée est sensible, nous recommandons d’utiliser la fonctionnalité Add Secret d’Actions.
Pour en savoir plus, consultez cette page : https://auth0.com/docs/customize/actions/write-your-first-action#add-a-secretLe certificat et la clé privée doivent tous deux être fournis.
Voici un exemple de valeur : “-----BEGIN PRIVATE KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..toutes les autres lignes..]-----END PRIVATE KEY-----\n”.Paramètres
[Clients d’entreprise] Révoque le jeton d’actualisation de l’utilisateur actuel et marque la tentative d’échange de jeton d’actualisation en cours comme refusée. Cela empêchera
l’utilisateur final de terminer le flux d’échange de jeton d’actualisation et révoquera le jeton d’actualisation utilisé.
Le flux d’échange de jeton d’actualisation s’arrêtera immédiatement une fois cette action terminée, et aucune autre action ne sera exécutée.Cette méthode peut être utilisée uniquement pendant le flux d’échange de jeton d’actualisation, lorsque event.transaction.protocol === "oauth2-refresh-token".Paramètres
Une explication claire du rejet de l’échange de jeton d’actualisation. Celle-ci peut être affichée
directement dans les interfaces destinées aux utilisateurs finaux.
[Clients d’entreprise] Définit une nouvelle date d’expiration absolue pour le jeton d’actualisation actuel.
L’expiration ne peut pas dépasser la durée de vie maximale du jeton d’actualisation définie dans les paramètres.
Lorsque cette méthode est appelée plusieurs fois, la date d’expiration la plus rapprochée est utilisée.Paramètres
Obligatoire. Nouvelle date d’expiration absolue, en millisecondes depuis l’époque Unix, après laquelle le jeton d’actualisation est considéré comme non valide.
[Clients d’entreprise] Définit un nouveau délai d’expiration d’inactivité pour le jeton d’actualisation actuel.
L’expiration ne peut pas dépasser la durée de vie absolue maximale du jeton d’actualisation définie dans les paramètres.
Lorsqu’elle est appelée plusieurs fois, la date d’expiration la plus proche est utilisée.Paramètres
Obligatoire. Nouveau délai d’inactivité, en millisecondes depuis l’époque Unix, après lequel le jeton d’actualisation est considéré comme non valide
s’il n’est pas utilisé pendant cette période.
[Clients d’entreprise] Révoque la session de l’utilisateur actuel et marque la tentative de connexion en cours comme refusée. Cela empêchera
l’utilisateur final de terminer le flux de connexion et révoquera sa session. Le flux de connexion s’arrêtera immédiatement
à la fin de cette action, et aucune autre Action ne sera exécutée.
Revoke the session while preserving refresh tokens
La valeur par défaut est « faux ». Si la valeur est « vrai », le système met fin à la session et conserve les jetons d’actualisation. L’application peut continuer à obtenir des jetons d’accès pendant toute la durée de validité du jeton d’actualisation.
Facultatif.
[Clients d’entreprise] Définit une nouvelle date d’expiration absolue pour la session actuelle.
L’expiration ne peut pas dépasser la durée de vie maximale de la session définie dans les paramètres du tenant.
Lorsqu’elle est appelée plusieurs fois, la date d’expiration la plus rapprochée est utilisée.Paramètres
[client d’entreprise] Définit un nouveau délai d’expiration d’inactivité pour la session actuelle.
L’expiration ne peut pas être fixée au-delà de la durée de vie maximale absolue de la session configurée dans les paramètres du tenant.
Si elle est appelée plusieurs fois, l’heure d’expiration la plus proche sera utilisée.Paramètres
Obligatoire. Nouvelle heure d’expiration liée à l’inactivité, en millisecondes depuis l’époque Unix, après laquelle la session sera considérée comme non valide en l’absence
d’interaction de l’utilisateur durant cette période.
[Clients d’entreprise] [Accès anticipé] Définit le mode du cookie de la session actuelle, qui peut être « persistent » ou « non-persistent » (éphémère).
Ce paramètre détermine la façon dont le cookie de session est géré dans le navigateur :
« persistent » : le cookie est conservé jusqu’à son expiration ou sa suppression par l’utilisateur.
« non-persistent » (éphémère) : le cookie est supprimé à la fermeture du navigateur.
Si plusieurs appels à setCookieMode sont effectués, seul le dernier est pris en compte. Si « non-persistent » est défini, le cookie est supprimé à la fermeture du navigateur. Toutefois, la session demeure valide jusqu’à l’atteinte de son délai d’expiration absolu ou d’inactivité
ou jusqu’à sa révocation au moyen des API disponibles. Pour en savoir plus sur les modes de cookie, consultez notre documentation.Paramètres
Obligatoire. Mode du cookie de la session actuelle.
Peut être « persistent » ou « non-persistent » (éphémère).
Valeurs autorisées : persistent, non-persistent
Stocke ou met à jour la valeur associée à une clé donnée dans les métadonnées de la transaction.Les métadonnées modifiées à l’aide de cette méthode sont mises à jour en temps réel dans l’objet
event.transaction.metadata.Paramètres
Renvoie tous les rôles attribués à un utilisateur, directement ou par son appartenance à un groupe,
et éventuellement limités à une organisation, avec pagination par checkpoint.
Fetch the first page of roles
const result = await api.roles.getUserEffectiveRoles({ take: 50 });console.log(result.roles);
Paginate through roles
let cursor;do { const result = await api.roles.getUserEffectiveRoles({ take: 100, from: cursor }); console.log(result.roles); cursor = result.next;} while (cursor);
Renvoie les rôles attribués à un utilisateur, directement ou par son appartenance à un groupe,
éventuellement limités à une organisation et filtrés par ID de rôle.
Filter roles by specific IDs
const result = await api.roles.getUserEffectiveRolesByIds([ 'rol_1234567890', 'rol_0987654321']);console.log(result.roles);
Renvoie les rôles attribués à un utilisateur, directement ou par l’intermédiaire de son appartenance à un groupe,
éventuellement limités à une organisation et filtrés par nom de rôle.
Filter roles by specific names
const result = await api.roles.getUserEffectiveRolesByNames([ 'Admin', 'Editor']);console.log(result.roles);
Authentifier
Gérer les utilisateurs
Personnaliser
Plateforme