Skip to main content
L’API My Account d’Auth0 fournit un ensemble dédié de points de terminaison permettant aux utilisateurs de gérer les renseignements de leur propre compte. Les clients peuvent utiliser ces API pour créer des expériences en libre-service dans leurs applications ou ajouter progressivement des renseignements à un compte d’utilisateur. L’API My Account fonctionne dans le contexte de l’utilisateur actuellement connecté, et vous pouvez l’utiliser directement dans des applications destinées aux utilisateurs.
Utiliser le domaine Auth0 ou un domaine personnaliséL’API My Account prend en charge l’utilisation de votre domaine Auth0 canonique ou de votre domaine personnalisé, mais vous devez utiliser le même pendant tout le processus, notamment pour :
  • Obtenir un jeton d’accès
  • Définir la valeur audience
  • Effectuer une requête au point de terminaison d’API My Account
Pour en savoir plus, consultez Custom Domains.

​
Activer l’API My Account

Vous pouvez activer l’API My Account pour votre tenant dans le  :
  1. Accédez à Applications > APIs.
  2. Repérez la bannière MyAccount API.
  3. Sélectionnez Activer.
Page APIs d’Auth0 Dashboard affichant la bannière MyAccount API avec le bouton Activer
Par défaut, Auth0 crée l’API My Account avec les politiques d’accès des applications à l’API suivantes :
  • require_client_grant pour les flux utilisateur
  • deny_all pour les flux client (machine-to-machine)
Pour qu’une application puisse accéder à l’API My Account au nom de l’utilisateur, vous devez créer explicitement un client grant pour cette application, ce qui vous permet de définir les scopes maximaux que l’application peut demander. Vous pouvez aussi modifier la politique des flux d’accès utilisateur pour la définir à allow_all, ce qui permet à toute application de votre tenant de demander n’importe quel scope à l’API My Account. Auth0 ne recommande pas d’utiliser allow_all pour les flux d’accès utilisateur, car l’API My Account expose des renseignements et des opérations sensibles. Vous devriez appliquer le principe du moindre privilège avec l’API My Account afin de vous assurer que les applications n’obtiennent que l’accès dont elles ont réellement besoin, ce qui réduit les risques de sécurité potentiels. Auth0 détermine les permissions finales accordées à l’application en faisant l’intersection des scopes autorisés par la politique d’accès de l’application à l’API, des permissions Role-Based Access Control (RBAC) attribuées à l’utilisateur final, ainsi que du consentement donné par l’utilisateur (le cas échéant).
Vous ne pouvez pas mettre à jour la politique d’accès des applications à l’API pour l’accès client à l’API My Account, ce qui signifie que vous ne pouvez pas accéder à l’API My Account à l’aide du Client Credentials Flow.
Pour en savoir plus sur la gestion des politiques d’accès des applications à l’API et des client grants associés, consultez Application Access to APIs: Client Grants.

​
Default Policy

La Default Policy fournit un niveau d’assurance de l’authentification intégré pour la API My Account en exigeant authentification renforcée. Lorsqu’elle est activée, Auth0 veille automatiquement à ce que les utilisateurs se soient authentifiés récemment et au moyen d’un second facteur. La politique impose la 2FA dans un délai de 15 minutes. Auth0 applique cette règle à la connexion et à chaque échange de jeton d’actualisation :
  • Si un utilisateur est déjà inscrit à un facteur MFA, la 2FA doit être effectuée à la connexion, puis de nouveau lorsque ses jetons ont plus de 15 minutes.
  • Si un utilisateur n’a aucun facteur pouvant être inscrit, Auth0 autorise l’accès initial, mais renvoie une erreur unmet_authentication_requirements lors des échanges de jeton d’actualisation après 15 minutes.
La Default Policy n’est pas compatible avec Classic Login. Activez cette fonctionnalité si votre tenant utilise Universal Login ou un flux embedded pris en charge (Resource Owner Password Flow ou clés d’accès natives).

​
Activer la Default Policy

Pour activer la Default Policy pour la API My Account :
  1. Accédez à Applications > APIs, puis sélectionnez la API My Account.
  2. Sélectionnez l’onglet Settings.
  3. Sous Default Policy, activez la bascule Require 2FA.
  4. Sélectionnez Save.
Lorsque la Default Policy est activée dans votre tenant, Auth0 l’associe automatiquement chaque fois qu’il crée une nouvelle API My Account.

​
Hiérarchie des exigences d’authentification

La Default Policy se situe entre la politique MFA au niveau du tenant et toute logique MFA que vous définissez dans Actions :
  1. Politique MFA du tenant : La politique de base par défaut appliquée à toute l’authentification de votre tenant
  2. Default Policy : Remplace la politique au niveau du tenant spécifiquement pour la My Account API
  3. Actions : Toute commande MFA dans Actions a toujours préséance sur les deux

​
Comportement de Default Politique

Le comportement dépend de la présence, ou non, d’un second facteur pouvant être inscrit par l’utilisateur. Utilisateurs ayant un facteur MFA inscrit Pour les utilisateurs ayant inscrit le TOTP, le courriel ou un autre facteur pris en charge :
  1. À la connexion, Auth0 demande à l’utilisateur de valider son facteur inscrit avant d’émettre des jetons.
  2. Le jeton d’actualisation consigne la méthode d’authentification et l’horodatage (AMR).
  3. Lors d’un échange de jeton d’actualisation dans les 15 minutes suivant la dernière vérification, Auth0 émet un nouvel jeton d’accès sans demander de nouvelle vérification.
  4. Lors d’un échange de jeton d’actualisation après 15 minutes, Auth0 demande de nouveau à l’utilisateur de valider son identité avant d’émettre des jetons.
Utilisateurs sans facteur MFA inscrit Pour les utilisateurs sans adresse courriel vérifiée et sans facteur inscrit :
  1. À la connexion, Auth0 autorise l’accès sans second facteur.
  2. Lors d’un échange de jeton d’actualisation dans les 15 minutes, Auth0 émet un nouvel jeton d’accès sans vérification.
  3. Lors d’un échange de jeton d’actualisation après 15 minutes, Auth0 renvoie une erreur unmet_authentication_requirements.
Lorsque Auth0 renvoie unmet_authentication_requirements lors d’un échange de jeton d’actualisation, vous ne pouvez pas actualiser le token. Votre application doit redémarrer le flux d’authentification complet pour obtenir de nouveaux jetons.Une connexion silencieuse (prompt=none) renvoie la même erreur lorsque l’utilisateur ne peut pas satisfaire la politique après 15 minutes.

​
Obtenir un jeton d’accès

Vous pouvez obtenir un pour l’API My Account de la même manière que pour l’une de vos propres API.
Si vous avez besoin d’un niveau d’assurance d’authentification supérieur à la Default Policy — par exemple, pour exiger un facteur précis ou n’appliquer des exigences qu’à certaines opérations — vous pouvez utiliser l’authentification renforcée avec Actions pour définir une logique MFA personnalisée. Notez qu’Actions remplace toujours la Default Policy.
Si vous utilisez , consultez les articles suivants : Si vous utilisez la connexion intégrée, consultez les articles suivants :

​
Audience

L’ de l’API My Account est https://{yourDomain}/me/.

​
Scope

L’API My Account prend en charge les scopes suivantes : Pour Connected Accounts with Token Vault, l’API My Account prend en charge les scopes suivantes :

​
Exemples de jetons d’accès

​
Universal Login avec le flux de code d’autorisation

L’obtention de jetons d’accès avec Universal Login d’Auth0 se fait en deux étapes : demandez un code d’autorisation, puis échangez-le contre un jeton d’accès. Pour en savoir plus sur ce type d’autorisation, consultez Flux de code d’autorisation. Commencez par effectuer un appel d’API au point de terminaison /authorize pour demander un code d’autorisation : Échangez ensuite le code contre un jeton d’accès :

​
Connexion intégrée avec des clés d’accès natives

Pour inclure des clés d’accès au flux de connexion de votre application intégrée, commencez par demander un défi de connexion : Ensuite, authentifiez les utilisateurs existants :

​
Gérer les méthodes d’authentification

Avec la My Account API, configurez les méthodes d’authentification afin que vos utilisateurs finaux puissent inscrire et gérer leurs propres méthodes d’authentification. La plupart des méthodes suivent un flux en deux étapes : lancez l’enrôlement, puis confirmez-la. Consultez le tableau des méthodes d’authentification prises en charge.

​
Enrôlement

L’enrôlement d’une méthode d’authentification se fait en deux étapes :
  1. Pour démarrer l’enrôlement, effectuez une requête POST vers /me/authentication-methods avec le type de méthode et les champs requis. Auth0 renvoie un jeton auth_session et des données d’enrôlement propres au type.
  2. Pour confirmer l’enrôlement, effectuez une requête POST vers /me/authentication-methods/{id}/verify avec le jeton auth_session et les informations d’identification de vérification associées à ce type de méthode (un code OTP, un nouveau mot de passe ou une réponse WebAuthn).
Une fois l’enrôlement confirmé, Auth0 définit le champ confirmed de la méthode à true dans les réponses GET suivantes.
L’enrôlement d’une clé d’accès ne comprend pas d’ID dans la réponse POST. Auth0 ne renvoie l’ID qu’après la réussite de l’étape de vérification.

​
Exemples de gestion des méthodes d’authentification

​
S’inscrire à un authentificateur TOTP

L’inscription à un authentificateur TOTP se fait en deux étapes : démarrer l’inscription, puis la confirmer. Commencez par lancer l’inscription pour obtenir un code QR et un secret à saisir manuellement que l’utilisateur pourra ajouter à son application d’authentification :
Confirmez ensuite l’inscription en envoyant le code à usage unique généré par l’application d’authentification de l’utilisateur, ainsi que les valeurs auth_session et id de la réponse précédente :

​
Lister les méthodes d’authentification

Récupérez toutes les méthodes d’authentification auxquelles l’utilisateur actuel est inscrit. Le champ confirmed indique si l’enrôlement est terminé.

​
Supprimer une méthode d’authentification

Supprimez une méthode d’authentification déjà inscrite. Remplacez {id} par l’id de la méthode figurant dans la réponse de la liste.

​
Requêtes inter-origines

Si vous prévoyez envoyer une requête directement à la My Account API à partir d’une application s’exécutant dans le navigateur (comme une Single Page Application) sur un domaine différent de celui de votre tenant Auth0, vous pourriez être confronté aux politiques de sécurité des navigateurs appelées Cross-Origin Resource Sharing (CORS). Par défaut, les navigateurs bloquent ces requêtes inter-origines. Pour permettre à votre application d’envoyer des requêtes à l’API avec succès, vous devez ajouter le domaine de votre application (son « origin ») à la configuration de votre client :
  1. Accédez à Dashboard > Applications. Sélectionnez l’application à afficher.
  2. Sous Cross-Origin Authentication, activez la bascule Allow Cross-Origin Authentication.
  3. Repérez Allowed Origins (CORS), puis saisissez l’URL d’origine de votre application.
  4. Sélectionnez Save.
Pour en savoir plus, consultez Configurer Cross-Origin Resource Sharing.
Si vous n’avez pas besoin d’utiliser CORS pour votre application, assurez-vous que l’option Allow Cross-Origin Authentication est désactivée. En ajoutant l’URL de votre application à cette liste, vous indiquez à Auth0 de faire confiance aux requêtes provenant de cette origine, ce qui permet à votre application côté client d’accéder à l’API.