API My Account

Apprenez à donner à vos utilisateurs la possibilité de gérer leurs propres informations de compte grâce à l’API My Account.

L’API My Account d’Auth0 propose un ensemble dédié des terminaux permettant aux utilisateurs de gérer les informations de leur compte. Les clients peuvent utiliser ces API pour créer des expériences en libre-service au sein de leurs applications ou pour ajouter progressivement des informations à un compte utilisateur.

L’API My Account fonctionne au sein du contexte de l’utilisateur actuellement connecté et peut être utilisée directement dans les applications destinées aux utilisateurs.

Utilisation d’un domaine Auth0 ou d’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 domaine tout au long du processus, notamment :

• pour obtenir un jeton d’accès
• pour définir la valeur audience
• pour appeler le terminal de l’API My Account

Pour en savoir plus, consultez Domaines personnalisés.

​

Activer l’API My Account

Vous pouvez activer l’API My Account pour votre locataire dans Auth0 Dashboard :

1. Rendez-vous à Applications > API.
2. Localisez la bannière API My Account.
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 utilisateurs
• deny_all pour les flux clients (communication entre machines)

Pour qu’une application puisse accéder à l’API My Account au nom d’un utilisateur, vous devez créer explicitement une autorisation de client pour cette application, ce qui vous permet de définir les permissions maximales que l’application peut demander. Vous pouvez également modifier la politique relative aux flux d’accès des utilisateurs pour la définir sur allow_all, ce qui permet à n’importe quelle application de votre locataire de demander n’importe quelle permission à l’API My Account.

Auth0 déconseille d’utiliser allow_all pour les flux d’accès des utilisateurs, car l’API My Account expose des informations et des opérations sensibles. Vous devez respecter le principe du « droit d’accès minimal » avec l’API My Account afin de garantir que les applications n’aient accès qu’aux informations dont elles ont réellement besoin, ce qui permet de réduire au minimum les risques en matière de sécurité.

Auth0 détermine les autorisations finales accordées à l’application en croisant les permissions autorisées par la politique d’accès à l’API de l’application, les autorisations du contrôle d’accès basé sur les rôles (RBAC) attribuées à l’utilisateur final et tout consentement donné par l’utilisateur (le cas échéant).

Vous ne pouvez pas mettre à jour la politique API de l’application 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 flux des identifiants client.

Pour en savoir plus sur la gestion des politiques d’accès aux API des applications et des autorisations client associées, consultez Accès des applications aux API : Autorisations client.

​

Politique par défaut

La politique par défaut garantit l’authentification intégrée pour l’API My Account en imposant une authentification renforcée. Lorsque cette fonctionnalité est activée, Auth0 s’assure automatiquement que les utilisateurs se sont authentifiés récemment et à l’aide d’un deuxième facteur d’authentification.

Cette politique impose l’authentification à deux facteurs dans un délai de 15 minutes. Auth0 applique cette règle lors de la connexion et à chaque échange de jeton d’actualisation :

• Si un utilisateur a inscrit un facteur de MFA, l’authentification à deux facteurs doit être effectuée lors de la connexion, puis à nouveau lorsque ses jetons datent de plus de 15 minutes.
• Si un utilisateur ne dispose d’aucun facteur pouvant être inscrit, Auth0 autorise l’accès initial, mais renvoie une erreur unmet_authentication_requirements lors des échanges de jetons d’actualisation au bout de 15 minutes.

La politique par défaut n’est pas compatible avec la connexion classique. Activez cette fonctionnalité si votre locataire utilise la connexion universelle ou un flux intégré pris en charge (flux par mot de passe du propriétaire de la ressource ou clés d’identification natives).

​

Activer la politique par défaut

Pour activer la politique par défaut pour l’API My Account :

1. Rendez-vous à Applications > API, et sélectionnez l’API My Account.
2. Sélectionnez l’onglet Paramètres.
3. Sous Politique par défaut, activez Exiger l’authentification à deux facteurs.
4. Sélectionnez Enregistrer.

Lorsque votre locataire a activé la politique par défaut, Auth0 l’associe automatiquement à chaque fois qu’il crée une nouvelle API My Account.

​

Hiérarchie des exigences d’authentification

La politique par défaut s’applique entre la politique de MFA au niveau du locataire et toute logique MFA que vous définissez dans les actions :

1. MFA au niveau du locataire : La politique par défaut appliquée à toutes les authentifications sur votre locataire
2. Politique par défaut : Remplace la politique au niveau du locataire spécialement pour l’API My Account
3. **Actions ** : Les commandes MFA présentes dans les Actions ont toujours la priorité sur les deux

​

Comportement par défaut de la politique

Ce comportement dépend de la présence ou non d’un deuxième facteur d’authentification pouvant être inscrit par l’utilisateur.

Utilisateurs ayant inscrit un facteur de MFA

Pour les utilisateurs inscrits avec TOTP, un courriel ou un autre facteur d’authentification pris en charge :

1. Lors de la connexion, Auth0 demande à l’utilisateur d’utiliser son facteur d’authentification inscrit avant d’émettre des jetons.
2. Le jeton d’actualisation enregistre la méthode d’authentification et l’horodatage (AMR).
3. Lors de l’échange de jeton d’actualisation dans les 15 minutes suivant le dernier défi-réponse, Auth0 émet un nouveau jeton d’accès sans lancer de nouveau défi-réponse.
4. Lors de l’échange du jeton d’actualisation au bout de 15 minutes, Auth0 lance un nouveau défi-réponse à l’utilisateur avant de générer les jetons.

Utilisateurs n’ayant pas inscrit de facteur de MFA

Pour les utilisateurs sans courriel vérifié et sans facteur d’authentification inscrit :

1. Lors de la connexion, Auth0 autorise l’accès sans authentification à deux facteurs.
2. Lors de l’échange de jeton d’actualisation dans les 15 minutes, Auth0 émet un nouveau jeton d’accès sans lancer de nouveau défi-réponse.
3. Lors de l’échange du jeton d’actualisation au bout de 15 minutes, Auth0 renvoie une erreur unmet_authentication_requirements.

Lorsque Auth0 renvoie un code d’erreur unmet_authentication_requirements lors d’un échange de jeton d’actualisation, vous ne pouvez pas rafraîchir le jeton. 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 parvient pas à respecter la politique au bout de 15 minutes.

​

Obtenir un jeton d’accès

Vous pouvez obtenir un jeton d’accès dans le glossaire pour l’API My Account de la même manière que vous obtiendriez un jeton d’accès pour l’une de vos propres API.

Si vous nécessitez un niveau de sécurité d’authentification plus élevé que celui fourni par la politique par défaut, par exemple en imposant un facteur particulier d’authentification ou en appliquant des exigences uniquement à certaines opérations, vous pouvez recourir à l’authentification renforcée avec Actions. Cela vous permettra de définir une logique de MFA personnalisée. Veuillez noter que les Actions prévalent toujours sur la politique par défaut.

Si vous utilisez la connexion universelleConnexion universelle, lisez 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 de mot de passe du propriétaire de ressource
• Flux de connexion avec l’API Native Passkeys

​

Public

Le public) Le public de l’API My Account est https://{yourDomain}/me/.

​

Permission

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

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

Pour les comptes connectés disposant d’un coffre-fort de jetons, l’API My Account prend en charge les permissions suivantes :

Permission	Description
create:me:connected_accounts	Permet à l’utilisateur d’associer un nouveau compte à son profil utilisateur.
read:me:connected_accounts	Permet à l’utilisateur d’afficher les comptes déjà connectés et associés à son profil utilisateur.
delete:me:connected_accounts	Permet à l’utilisateur de supprimer un compte associé de son profil utilisateur.

​

Exemples de jetons d’accès

​

Connexion universelle avec flux de code d’autorisation

La récupération des jetons d’accès avec la connexion universelle d’Auth0 se déroule en deux étapes : demander un code d’autorisation, puis échanger ce code 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 API vers le terminal /authorize pour demander un code d’autorisation :

Puis, échangez le code contre un jeton d’accès :

​

Connexion intégrée avec clés d’identification natives

Pour intégrer des clés d’identification dans le processus de connexion de vos applications intégrées, commencez par demander un défi-réponse de connexion :

Ensuite, authentifiez les utilisateurs existants :

​

Gestion des méthodes d’authentification

Grâce à l’API My Account, configurez les méthodes d’authentification afin que vos utilisateurs finaux puissent inscrire et gérer eux-mêmes leurs propres méthodes d’authentification. La plupart des méthodes suivent un flux en deux étapes : commencer l’inscription, puis confirmer celui-ci.

Consultez le tableau pour connaître les méthodes d’authentification prises en charge.

Type	Comportement en matière d’inscription	Inscription possible via l’API
email secondaire (MFA)	POST { "type": "email" } Inclure email dans la requête POST. Auth0 envoie un code à usage unique à cette adresse. Envoyez ce code dans la demande de vérification otp_code.	Oui
phone secondaire (MFA)	POST { "type": "sms" } Auth0 envoie un code à usage unique à ce numéro de téléphone. Envoyez ce code dans la demande de vérification otp_code.	Oui
totp secondaire (MFA)	POST { "type": "totp" } La réponse comprend : barcode_uri : s’affiche sous la forme d’un code QR que l’utilisateur peut balayer à l’aide d’une application d’authentification. manual_input_code : le code secret TOTP pour les utilisateurs qui ne peuvent pas balayer un code QR.	Oui
push-notification secondaire (MFA)	POST { "type": "push-notification" } La réponse contient un code barcode_uri que l’utilisateur doit balayer pour associer une application d’authentification. La demande de vérification nécessite uniquement auth_session et non otp_code. Auth0 finalise l’inscription une fois que l’utilisateur a validé la notification poussée 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 vous ne pourrez plus la récupérer par la suite. La demande de vérification ne nécessite que auth_session.	Oui
password primaire	POST { "type": "password" } La réponse comprend un objet policy décrivant les exigences relatives au mot de passe de l’utilisateur (p. ex., longueur minimale, types de caractères autorisés, historique et paramètres du dictionnaire). Envoyez new_password avec auth_session dans la demande de vérification. Auth0 vérifie que le mot de passe est conforme à la politique avant de valider l’inscription.	Oui
passkey primaire	POST { "type": "passkey" }. La réponse ne contient pas d’identifiant. Elle renvoie plutôt : auth_session : identificateur de session unique pour l’inscription, tel que renvoyé par POST /authentication-methods. authn_params_public_key : permet à WebAuthn PublicKeyCredentialCreationOptions de transmettre à navigator.credentials.create(). Dans la requête de vérification, transmettez l’intégralité de AuthenticatorAttestationResponse WebAuthn en tant que authn_response. L’identifiant de la méthode est renvoyé dans la réponse de vérification.	Oui
webauthn-platform secondaire (MFA)	L’inscription n’est pas prise en charge pour le moment.	Non — en lecture seule
webauthn-roaming secondaire (MFA)	L’inscription n’est pas prise en charge pour le moment.	Non — en lecture seule

​

Flux d’inscription

L’inscription d’une méthode d’authentification se déroule en deux étapes :

1. Pour lancer l’inscription, effectuez un appel POST vers /me/authentication-methods en indiquant le type de méthode et tous les champs obligatoires. Auth0 renvoie un jeton auth_session et une inscription propre au type.
2. Pour confirmer votre inscription, effectuez un appel POST vers /me/authentication-methods/{id}/verify en utilisant auth_session et l’identifiant de vérification correspondant à ce type de méthode (un code OTP, un nouveau mot de passe ou une réponse WebAuthn).

Une fois la confirmation effectuée, Auth0 définit la valeur du champ confirmed de la méthode sur true dans les réponses GET suivantes.

L’inscription des clés d’identification n’inclut pas d’identifiant dans la réponse POST. Auth0 ne renvoie l’identifiant qu’une fois l’étape de vérification réussie.

​

Exemples de gestion des méthodes d’authentification

​

Effectuer l’inscription d’un authentificateur TOTP

L’inscription au TOTP se déroule en deux étapes : le lancement de la procédure d’inscription au TOTP et la confirmation de cette inscription.

Commencez par lancer la procédure d’inscription afin de recevoir un code QR et une clé secrète que l’utilisateur devra ajouter à son application d’authentification :

Requête

curl --request POST \
  --url 'https://{yourDomain}/me/v1/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"
}

Ensuite, validez en saisissant le code à usage unique fourni par l’application d’authentification de l’utilisateur, ainsi que auth_session et id issues de la réponse précédente :

Requête

curl --request POST \
  --url 'https://{yourDomain}/me/v1/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"
}

​

Liste des méthodes d’authentification

Récupérer toutes les méthodes d’authentification inscrites pour l’utilisateur actuel. Le champ confirmed indique si l’inscription a été effectuée.

Requête

curl --request GET \
  --url 'https://{yourDomain}/me/v1/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

Supprimer une méthode d’authentification inscrite. Remplacez {id} par les id des méthodes figurant dans la liste de réponse.

Requête

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

Réponse

HTTP 204 No Content

​

Requêtes cross-origin

Si vous avez l’intention d’appeler l’API My Account directement à partir d’une application basée sur un navigateur (telle qu’une application Web monopage) fonctionnant sur un domaine différent de celui de votre locataire Auth0, vous pourriez être confronté aux politiques de sécurité des navigateurs connues sous le nom de partage de ressources cross-origin (CORS). Par défaut, les navigateurs bloquent ces requêtes cross-origin.

Pour permettre à votre application d’envoyer correctement des requêtes à l’API, vous devez ajouter le domaine de votre application (son « origine ») à la configuration de votre client :

1. Rendez-vous à Tableau de bord > Applications. Sélectionnez l’application à afficher.
2. Sous Authentification cross-origin, activez l’option Autoriser l’authentification cross-origin.
3. Repérez les origines autorisées (CORS) et saisissez l’URL d’origine de votre application’.
4. Sélectionnez Enregistrer.

Pour en savoir plus, consultez Configurer le partage de ressources cross-origin.

Si vous n’avez pas besoin d’utiliser CORS pour votre application, assurez-vous que l’option Autoriser l’authentification cross-origin est désactivée. En ajoutant l’URL de votre application à cette liste, vous indiquez à Auth0 de considérer comme fiables les requêtes provenant de cette source, ce qui permet à votre application côté client d’accéder à l’API.