Référence de l’API My Account

Documentation de l’API My Account d’Auth0

Version : 1.0 (actuelle)

L’API My Account d’Auth0 fournit un ensemble de points de terminaison dédiés 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 peut être utilisée directement dans des applications destinées aux utilisateurs.

Utilisation du domaine Auth0 par rapport au 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 de l’audience
• Effectuer une requête au point de terminaison 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 tenant dans l’Auth0 Dashboard :

1. Accédez à Authentication > APIs.
2. Repérez la bannière de l’API My Account.
3. Sélectionnez Activate.

Par défaut, l’API My Account est créée avec les politiques d’accès des applications aux 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 maximums que l’application peut demander. Vous pouvez aussi modifier la politique des flux d’accès utilisateur à allow_all, ce qui permet à toute application de votre tenant de demander n’importe quel scope de l’API My Account.

Comme l’API My Account expose des renseignements et des opérations sensibles, Auth0 ne recommande pas d’utiliser allow_all pour les flux d’accès utilisateur. Vous devriez appliquer le principe du moindre privilège à 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 au minimum les risques de sécurité.

Les permissions finales accordées à l’application seront déterminées par l’intersection des scopes autorisés par la politique d’accès des applications à l’API, des permissions de contrôle d’accès basé sur les rôles (RBAC) attribuées à l’utilisateur final, et de tout consentement donné par l’utilisateur (le cas échéant).

Flux pris en charge

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 aux API et des client grants associés, consultez Accès des applications aux API : client grants.

​

Obtenir un jeton d’accès

Vous pouvez obtenir un jeton d’accès pour l’API My Account de la même façon que pour l’une de vos propres API.

Opérations sensibles

Si vous prévoyez autoriser l’API My Account à effectuer des opérations sensibles (comme l’enregistrement d’une méthode d’authentification), nous vous recommandons fortement d’utiliser l’authentification progressive afin d’appliquer des politiques de sécurité supplémentaires au moyen de l’authentification multifacteur (MFA).

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 connexion avec l’API Native Passkeys

​

Exemples

​

Universal Login avec le flux de code d’autorisation

Étape 1 : Demander un code d’autorisation

curl --request GET \
  --url 'https://{yourDomain}/authorize?response_type=code&client_id={yourClientId}&redirect_uri=%7ByourRedirectUri%7D&scope=create%3Ame%3Aauthentication_methods&offline_access=&audience=https%3A%2F%2F{yourDomain}%2Fme%2F'

Étape 2 : Échanger le code contre un jeton d’accès

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/json' \
  --data '{"grant_type": "authorization_code","client_id": "{yourClientId}","client_secret": "{yourClientId}","code": "{yourAuthorizationCode}","redirect_uri": "{yourRedirectUri}","audience": "{yourAudience}","scope": "create:me:authentication_methods","offline_access": ""}'

​

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

Étape 1 : Demander un défi de connexion

curl --request POST \
  --url 'https://{yourDomain}/passkey/challenge' \
  --header 'content-type: application/json' \
  --data '{"client_id": "{yourDomain}"}'

Étape 2 : Authentifier un utilisateur existant

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/json' \
  --data '{  "grant_type": "urn:okta:params:oauth:grant-type:webauthn",  "client_id": "{yourClientId}",  "scope": "create:me:authentication_methods offline_access",  "audience": "https://{yourDomain}/me/"  "auth_session": "{sessionIdFromTheFirstRequest}",  "authn_response": "{authenticatorResponse}"}'

​

Authentification

HTTP : authentification Bearer

Les jetons Bearer et DPoP sont pris en charge en fonction de la configuration de l’API

Type de schéma de sécurité :	http
Schéma d’autorisation HTTP :	bearer