My Account API

Découvrez comment permettre à vos utilisateurs de gérer eux-mêmes les renseignements de leur compte avec la API My Account.

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 Auth0 Dashboard :

1. Accédez à Applications > APIs.
2. Repérez la bannière MyAccount API.
3. Sélectionnez 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 jeton d’accès 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 Universal Login, consultez les articles suivants :

• Appeler votre API à l’aide du flux de code d’autorisation
• Appeler votre API à l’aide du flux de code d’autorisation avec PKCE

Si vous utilisez la connexion intégrée, consultez les articles suivants :

• Appeler votre API à l’aide du flux Resource Owner Password
• Flux de login avec l’API Native Passkeys

​

Audience

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

​

Scope

L’API My Account prend en charge les scopes suivantes :

scope	Description
create:me:authentication_methods	Permet à l’utilisateur d’enregistrer une nouvelle méthode d’authentification.
read:me:authentication_methods	Permet à l’utilisateur de consulter les méthodes d’authentification existantes.
update:me:authentication_methods	Permet à l’utilisateur de modifier les méthodes d’authentification existantes.
delete:me:authentication_methods	Permet à l’utilisateur de supprimer les méthodes d’authentification existantes.
read:me:factors	Permet à l’utilisateur de consulter les facteurs qu’il peut enregistrer.

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

scope	Description
create:me:connected_accounts	Permet à l’utilisateur de connecter un nouveau compte à son profil.
read:me:connected_accounts	Permet à l’utilisateur de consulter les comptes connectés existants liés à son profil.
delete:me:connected_accounts	Permet à l’utilisateur de supprimer un compte connecté de son profil.

​

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.

Type	Comportement d’enrôlement	Enrôlement possible via l’API
email Secondaire (MFA)	POST { "type": "email" } Incluez email dans la requête POST. Auth0 envoie un code à usage unique à l’adresse. Soumettez ce code dans otp_code de la requête de vérification.	Oui
phone Secondaire (MFA)	POST { "type": "sms" } Auth0 envoie un code à usage unique au numéro de téléphone. Soumettez ce code dans otp_code de la requête de vérification.	Oui
totp Secondaire (MFA)	POST { "type": "totp" } La réponse comprend : barcode_uri : s’affiche sous forme de code QR que l’utilisateur peut numériser avec une application d’authentification. manual_input_code : le secret TOTP destiné aux utilisateurs qui ne peuvent pas numériser un code QR.	Oui
push-notification Secondaire (MFA)	POST { "type": "push-notification" } La réponse comprend un barcode_uri que l’utilisateur peut numériser pour associer une application d’authentification. La requête de vérification nécessite uniquement auth_session, et non otp_code. Auth0 termine l’enrôlement lorsque l’utilisateur approuve la notification push dans son application.	Oui
recovery-code Secondaire (MFA)	POST { "type": "recovery-code" } La réponse comprend un recovery_code. Affichez immédiatement cette valeur à l’utilisateur, car elle ne peut pas être récupérée de nouveau. La requête de vérification nécessite uniquement auth_session.	Oui
password Principal	POST { "type": "password" } La réponse comprend un objet policy décrivant les exigences de mot de passe du tenant (p. ex., longueur minimale, types de caractères autorisés, paramètres d’historique et de dictionnaire). Soumettez new_password avec auth_session dans la requête de vérification. Auth0 valide le mot de passe en fonction de la politique avant de confirmer l’enrôlement.	Oui
passkey Principal	POST { "type": "passkey" }. La réponse ne comprend pas d’ID. Elle renvoie plutôt : auth_session : identifiant de session unique pour l’enrôlement, tel que renvoyé par POST /authentication-methods. authn_params_public_key : permet de transmettre les PublicKeyCredentialCreationOptions WebAuthn à navigator.credentials.create(). Dans la requête de vérification, soumettez la réponse WebAuthn AuthenticatorAttestationResponse complète dans authn_response. L’ID de la méthode est renvoyé dans la réponse de vérification.	Oui
webauthn-platform Secondaire (MFA)	L’enrôlement n’est actuellement pas prise en charge.	Non — lecture seule
webauthn-roaming Secondaire (MFA)	L’enrôlement n’est actuellement pas prise en charge.	Non — lecture seule

​

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

​

Inscrire un authentificateur TOTP

L’enrôlement d’un authentificateur TOTP se fait en deux étapes : démarrer l’enrôlement, puis la confirmer.

Commencez par lancer l’enrôlement pour obtenir un code QR et un secret à saisir manuellement que l’utilisateur pourra ajouter à son application d’authentification :

Requête

curl --request POST \
  --url 'https://{yourDomain}/me/authentication-methods' \
  --header 'Authorization: Bearer {yourAccessToken}' \
  --header 'Content-Type: application/json' \
  --data '{"type": "totp"}'

Réponse

{
  "id": "amr_abc123",
  "auth_session": "eyJhbGci...",
  "barcode_uri": "otpauth://totp/YourApp:user%40example.com?secret=JBSWY3DPEHPK3PXP&issuer=YourApp",
  "manual_input_code": "JBSWY3DPEHPK3PXP"
}

Confirmez ensuite l’enrôlement 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 :

Requête

curl --request POST \
  --url 'https://{yourDomain}/me/authentication-methods/{id}/verify' \
  --header 'Authorization: Bearer {yourAccessToken}' \
  --header 'Content-Type: application/json' \
  --data '{"auth_session": "{yourAuthSession}", "otp_code": "{yourOtpCode}"}'

Réponse

{
  "id": "amr_abc123",
  "type": "totp",
  "confirmed": true,
  "created_at": "2024-01-15T10:30:00.000Z",
  "updated_at": "2024-01-15T10:35:00.000Z"
}

​

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é.

Requête

curl --request GET \
  --url 'https://{yourDomain}/me/authentication-methods' \
  --header 'Authorization: Bearer {yourAccessToken}'

Réponse

[
  {
    "id": "amr_abc123",
    "type": "totp",
    "confirmed": true,
    "created_at": "2024-01-15T10:30:00.000Z",
    "updated_at": "2024-01-15T10:35:00.000Z"
  },
  {
    "id": "amr_def456",
    "type": "email",
    "email": "[e-mail]",
    "confirmed": true,
    "created_at": "2024-01-10T08:00:00.000Z",
    "updated_at": "2024-01-10T08:05:00.000Z"
  }
]

​

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ête

curl --request DELETE \
  --url 'https://{yourDomain}/me/authentication-methods/{id}' \
  --header 'Authorization: Bearer {yourAccessToken}'

Réponse

HTTP 204 No Content

​

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.