Marque la tentative de connexion en cours comme refusée. Cela empêchera l’utilisateur final de terminer
le flux de connexion. Cela N’ANNULERA PAS les autres effets secondaires liés à l’utilisateur (comme les modifications
des 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.
Demandez une vérification d’authentification multifacteur à l’aide du facteur fourni et, facultativement, d’autres facteurs.Lorsqu’une vérification multifacteur est demandée, les Actions suivantes ne seront pas exécutées tant que cette vérification n’aura pas
été remplie par l’utilisateur. Un utilisateur aura satisfait à la vérification dans l’une ou l’autre des situations suivantes :
Il réussit la vérification pour le facteur par défaut.
Il réussit la vérification pour l’un des facteurs facultatifs décrits dans additionalFactors.
Si l’un des facteurs demandés a déjà fait l’objet d’une vérification réussie dans la transaction en cours, il sera
ignoré.Si un facteur demandé n’est pas activé sur le locataire, il sera ignoré. Si un facteur est demandé alors que l’utilisateur
n’y est pas inscrit, il sera ignoré. Si aucun des facteurs demandés n’est activé ou inscrit, la transaction
d’authentification échouera (c.-à-d. que la connexion ne sera pas terminée).
Cette méthode affichera un écran de vérification du facteur si l’utilisateur n’a pas déjà satisfait
aux exigences de la vérification. Si additionalFactors sont fournis, l’utilisateur pourra
sélectionner un autre facteur s’il le souhaite.
Un type de facteur d’authentification comme push-notification, phone, email, otp, webauthn-roaming, webauthn-platform et recovery-code.Valeurs autorisées : otp, email, webauthn-platform, webauthn-roaming, recovery-code
Options supplémentaires pouvant aussi spécifier additionalFactors comme propriété. Les options propres au facteur (par exemple otpFallback pour push-notification) doivent être définies dans factor.options.
Demandez une vérification d’authentification multifacteur à l’aide de l’un des facteurs fournis (en affichant d’abord un
écran de sélection des facteurs).Lorsqu’une vérification d’authentification multifacteur est demandée, les Actions suivantes ne seront pas exécutées tant que cette vérification n’aura pas été
relevée par l’utilisateur. Un utilisateur aura satisfait à la vérification dans l’une des situations suivantes :
Il réussit la vérification pour l’un des facteurs.
Si l’un des facteurs demandés a déjà été validé avec succès dans la transaction en cours, il sera
ignoré.Si un facteur demandé n’est pas activé pour le locataire, il sera ignoré. Si un facteur demandé auquel l’utilisateur
n’est pas inscrit, il sera ignoré. Si aucun des facteurs demandés n’est activé ou si l’utilisateur n’y est pas inscrit, la transaction
d’authentification échouera (c.-à-d. que la connexion ne se terminera pas).
Cette méthode affichera l’écran de sélection des facteurs si l’utilisateur ne satisfait pas déjà
aux exigences de la vérification. S’il existe un facteur privilégié, il est préférable d’utiliser la méthode api.authentication.challengeWith().
L’écran de sélection des facteurs ne sera pas affiché si un seul facteur est transmis ou est valide.
Demande une inscription à l’authentification multifacteur à l’aide du facteur fourni et, facultativement, de facteurs supplémentaires.Lorsqu’une inscription multifacteur est demandée, les Actions suivantes ne sont pas exécutées tant que cette inscription n’a pas été
menée à terme par l’utilisateur.Si l’un des facteurs demandés a déjà été inscrit ou a déjà fait l’objet d’une vérification réussie dans la transaction en cours, il sera
ignoré.Si un facteur qui n’est pas activé dans le locataire 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 l’ouverture de session ne se terminera pas).
Demande une inscription à l’authentification multifacteur à l’aide de n’importe lequel des facteurs fournis (en affichant d’abord un
écran de sélection du facteur).Lorsqu’une inscription multifacteur est demandée, les Actions suivantes ne seront pas exécutées tant que cette inscription n’aura pas été
effectuée par l’utilisateur.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 locataire est demandé, il sera ignoré.
Si un facteur pour lequel l’utilisateur est déjà inscrit est demandé, il sera ignoré.
Si aucun des facteurs demandés n’est activé et non inscrit, la
transaction d’authentification échouera (c.-à-d. que la connexion ne se terminera pas).
S’il existe un facteur préféré, la méthode api.authentication.enrollWith()
est à privilégier. L’écran de sélection du facteur ne sera pas affiché si un seul facteur est transmis ou valide.
Indique qu’une méthode d’authentification personnalisée a été exécutée dans la
session en cours. Cette méthode sera ensuite disponible dans le tableau event.authentication.methods
lors des connexions ultérieures.IMPORTANT : Cette API est uniquement disponible dans la fonction onContinuePostLogin
pour les Actions PostLogin. Autrement dit, elle peut être utilisée pour enregistrer
l’exécution d’une méthode d’authentification personnalisée après avoir redirigé l’utilisateur au moyen de
api.redirect.sendUserTo().
Modifie l’utilisateur principal de la transaction de connexion.Dans les scénarios où il faut lier des utilisateurs, l’identité utilisateur utilisée pour lancer la connexion peut ne plus
exister comme utilisateur distinct. Cette identité peut désormais être une identité secondaire d’un utilisateur existant. Dans
de telles situations, la fonction setPrimaryUser() peut être utilisée pour indiquer que le sujet de la
connexion doit être modifié.IMPORTANT : Lier des comptes de façon non sécuritaire 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 les jetons ne seront pas émis.
Activez l’authentification multifacteur pour ce flux de connexion. Lorsqu’elle est activée, les utilisateurs doivent effectuer la
vérification multifacteur configurée. La vérification multifacteur proprement dite sera reportée à la
fin du flux de connexion.
Le nom du fournisseur multifacteur à utiliser ou la valeur "any" pour utiliser l’un
des fournisseurs configurés.Valeurs autorisées : duo, none, guardian, google-authenticator, any
Lorsque le fournisseur est défini sur google-authenticator ou duo, l’utilisateur n’est invité à effectuer une
MFA qu’une fois tous les 30 jours. Lorsque le fournisseur est défini sur guardian, l’invite MFA affiche la case
d’inscription afin que les utilisateurs puissent choisir de s’inscrire ou non. La valeur par défaut est false. Pour en savoir plus,
consultez Personnaliser les pages d’authentification multifacteur.
Créez un jeton de session pouvant être utilisé comme paramètre de chaîne de requête pour une cible de redirection (via sendUserTo)
et contenant des données dont l’authenticité doit pouvoir être vérifiée par le point de terminaison cible. Le point de terminaison cible
peut vérifier l’authenticité et l’intégrité des données en validant la signature du JWT
à l’aide d’un secret partagé.Le secret partagé doit être stocké comme secret de l’Action et sera accessible à
event.secrets['<secret_name>'].
Secret utilisé pour signer un JWT partagé avec la cible de redirection. La
valeur du secret doit être stockée comme secret et récupérée à l’aide de
event.secrets['<secret_name>'].
Fait en sorte que le processus de connexion déclenche immédiatement une redirection du navigateur vers l’url cible une fois
cette action terminée. La méthode utilitaire createUrl est fournie pour simplifier l’encodage des
données dans un paramètre de requête de l’url cible, afin que l’authenticité et
l’intégrité des données puissent être vérifiées par le point de terminaison cible.
Définit des métadonnées propres à l’application pour l’utilisateur qui se connecte.Remarque : cette méthode ne doit pas être utilisée dans des fonctions de rappel. Son appel ne met pas à jour les métadonnées immédiatement.
Vous pouvez l’appeler plusieurs fois dans plusieurs Actions d’un même flux, et le moteur regroupera les
modifications pour mettre à jour les métadonnées en une seule fois avant la fin du flux. Cette fonction ne fonctionne qu’avec des métadonnées au
format objet.
Définit des métadonnées générales pour l’utilisateur qui se connecte.Remarque : cette méthode ne doit pas être utilisée dans des fonctions de rappel. Son appel ne met pas à jour les métadonnées immédiatement.
Vous pouvez l’appeler à plusieurs reprises dans différentes Actions d’un même flux, et le moteur regroupera les
modifications pour mettre à jour les métadonnées en une seule fois avant la fin du flux. Cette fonction ne fonctionne qu’avec des métadonnées
au format objet.
Récupère un enregistrement décrivant une valeur en cache à la clé fournie,
si elle existe. Si un enregistrement est trouvé, la valeur en cache se trouve
dans la propriété value de l’objet retourné.
Stocke ou met à jour une valeur de type chaîne dans le cache à la clé spécifiée.Les valeurs stockées dans ce cache sont limitées au déclencheur dans lequel
elles sont définies. Elles sont assujetties aux limites du cache des Actions.Les valeurs stockées de cette façon auront une durée de vie pouvant aller jusqu’à la
valeur ttl ou expires_at spécifiée. Si aucune durée de vie n’est spécifié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 des Actions.Important : Ce cache est conçu pour des données éphémères de courte durée. Il se peut que des éléments ne soient pas
disponibles dans des transactions ultérieures même s’ils sont encore dans leur durée de vie prévue.
L’heure d’expiration absolue, en millisecondes depuis l’époque Unix.
Bien que les enregistrements mis en cache puissent être évincés plus tôt, ils ne
seront jamais conservés au-delà de la valeur expires_at fournie.Remarque : Cette valeur ne doit pas être fournie si une valeur a aussi
été fournie pour ttl. Si les deux options sont fournies, la
première échéance des deux sera utilisée.
La durée de vie de cette entrée de cache, en millisecondes.
Bien que les valeurs mises en cache puissent être évincées plus tôt, elles ne
seront jamais conservées au-delà de la valeur ttl fournie.Remarque : Cette valeur ne doit pas être fournie si une valeur a aussi
été fournie pour expires_at. Si les deux options sont fournies, la
première échéance des deux sera utilisée.
Destinataire de l’assertion SAML (SubjectConfirmationData).
La valeur par défaut est l’AssertionConsumerUrl de la SAMLRequest, ou l’URL de rappel si aucune SAMLRequest n’a été envoyée.
Si la valeur est true (par défaut), pour chaque revendication qui n’est pas mappée au profil commun, Auth0 la transmet dans l’assertion de sortie.
Si la valeur est false, ces revendications ne seront pas mappées.
Si passthroughClaimsWithNoMapping est true et que cette valeur est false (par défaut), Auth0 ajoute le préfixe http://schema.auth0.com à chaque revendication qui n’est pas mappée au profil commun.
Si elle est true, la revendication est transmise telle quelle.
Si cette valeur est true (par défaut), davantage d’informations sont ajoutées au jeton, comme le fournisseur (Google, ADFS, AD, etc.) et le jeton d’accès, s’il est disponible.
Destination de la réponse SAML. Si elle n’est pas spécifiée, il s’agit de l’AssertionConsumerUrl de la SAMLRequest ou de l’URL de rappel en l’absence de SAMLRequest.
Indique 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 true, la réponse SAML sera signée au lieu de l’assertion SAML.
La valeur par défaut est false.
Auth0 essaiera chacun des attributs de ce tableau dans l’ordre.
Si l’un d’eux a une valeur, celle-ci sera utilisée pour le 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[..all the other lines..]-----END CERTIFICATE-----\n”.
Lorsqu’elle est définie à true, nous déduisons le NameFormat en fonction du nom de l’attribut. Les valeurs de 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.
Si elle est définie à false, le NameFormat de l’attribut n’est pas défini dans l’assertion.
La valeur par défaut est true.
Lorsqu’elle est définie sur true, cette option nous permet de déduire le xs:type de l’élément. Les types possibles sont xs:string, xs:boolean, xs:double et xs:anyType.
Lorsqu’elle est définie sur false, tous les xs:type sont xs:anyType.
La valeur par défaut est true.
Vous pouvez, au besoin, spécifier un certificat utilisé pour chiffrer l’assertion SAML.
Le certificat doit être obtenu auprès du 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[..all the other lines..]-----END CERTIFICATE-----\n”.
Vous pouvez, au besoin, spécifier une clé publique servant à chiffrer l’assertion SAML.
La clé publique doit être obtenue auprès du fournisseur de services.
Vous devez spécifier à la fois la clé publique et le certificat.
Voici un exemple de valeur : « -----BEGIN PUBLIC KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END PUBLIC KEY-----\n ».
Par défaut, Auth0 utilisera la paire de clés publique/privée attribuée à votre locataire pour signer les réponses ou les assertions SAML.
Dans certains cas très précis, vous pourriez vouloir 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[..all the other lines..]-----END CERTIFICATE-----\n”.
Par défaut, Auth0 utilise la paire de clés privée/publique attribuée à votre locataire pour signer les réponses ou les assertions SAML.
Dans des cas très particuliers, vous pouvez 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 dans Actions.
Consultez ce lien pour en savoir plus : 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[..all the other lines..]-----END PRIVATE KEY-----\n”.
[Client d’entreprise] Révoquez le jeton d’actualisation actuel de l’utilisateur et marquez la tentative d’échange du jeton d’actualisation en cours comme refusée. Cela empêchera
l’utilisateur final de terminer le flux d’échange du jeton d’actualisation et révoquera le jeton d’actualisation en cours d’utilisation.
Le flux d’échange du jeton d’actualisation s’arrêtera immédiatement après l’exécution de cette action, 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".
Une explication claire du rejet de l’échange du jeton d’actualisation, formulée pour être comprise par un humain. Elle peut être affichée
directement dans les interfaces destinées aux utilisateurs finaux.
[Client d’entreprise] Définit une nouvelle date d’expiration absolue pour le jeton d’actualisation actuel.
L’expiration ne peut pas être définie à une valeur supérieure à la durée de vie maximale du jeton d’actualisation configurée dans les paramètres.
Si cette méthode est appelée plusieurs fois, la date d’expiration la plus rapprochée sera utilisée.
Obligatoire, la nouvelle date d’expiration absolue en millisecondes depuis l’époque Unix, après laquelle le jeton d’actualisation sera considéré comme invalide.
[Client d’entreprise] Définit une nouvelle date d’expiration d’inactivité pour le jeton d’actualisation actuel.
L’expiration ne peut pas être définie au-delà de la durée de vie absolue maximale du jeton d’actualisation configurée dans les paramètres.
Si cette méthode est appelée plusieurs fois, la date d’expiration la plus rapprochée sera utilisée.
Obligatoire, la nouvelle date d’expiration d’inactivité, en millisecondes depuis l’époque Unix, après laquelle le jeton d’actualisation sera considéré comme invalide
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 après l’exécution de cette action et aucune autre Action ne sera exécutée.
Une explication compréhensible par un humain du rejet de la connexion. Elle peut être affichée
directement dans les interfaces destinées aux utilisateurs finaux.
La valeur par défaut est false. Si la valeur est true, 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 vie du jeton d’actualisation.
Revoke the session while preserving refresh tokens
[Clients d’entreprise] Définit une nouvelle date d’expiration absolue pour la session en cours.
La date d’expiration ne peut pas dépasser la durée de vie maximale de la session définie dans les paramètres du locataire.
Si cette méthode est appelée plusieurs fois, c’est la date d’expiration la plus proche qui sera utilisée.
Obligatoire, la nouvelle date d’expiration absolue, en millisecondes depuis l’époque Unix, au-delà de laquelle la session sera considérée comme invalide.
[Clients d’entreprise] Définit une nouvelle heure d’expiration d’inactivité pour la session en cours.
L’expiration ne peut pas être définie au-delà de la durée de vie absolue maximale de la session configurée dans les paramètres du locataire.
Si elle est appelée plusieurs fois, l’heure d’expiration la plus rapprochée sera utilisée.
Obligatoire, la nouvelle heure d’expiration d’inactivité en millisecondes depuis l’époque Unix, après laquelle la session sera considérée comme invalide s’il n’y a
aucune interaction de l’utilisateur pendant cette période.
[Clients d’entreprise] [Accès anticipé] Définit le mode du cookie pour la session en cours, qui peut être soit ‘persistent’, soit ‘non-persistent’ (éphémère).
Cela détermine la façon dont le cookie de session est géré dans le navigateur :
‘persistent’ : le cookie sera conservé jusqu’à son expiration ou sa suppression par l’utilisateur.
‘non-persistent’ (éphémère) : le cookie sera supprimé à la fermeture du navigateur.
Si plusieurs appels à setCookieMode sont effectués, seul le dernier prendra effet. Si ‘non-persistent’ est défini, le cookie sera supprimé à la fermeture du navigateur. Toutefois, la session elle-même demeurera valide jusqu’à ce que son délai d’expiration absolu ou d’inactivité soit atteint
ou que la session soit révoquée au moyen de nos API disponibles. Pour en savoir plus sur les modes de cookie, consultez notre documentation.
Obligatoire, le mode du cookie pour la session en cours.
Peut être soit ‘persistent’, soit ‘non-persistent’ (éphémère).Valeurs autorisées : persistent, non-persistent
Stocke ou met à jour la valeur des métadonnées de la transaction pour une clé donnée.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.
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme