Passer au contenu principal
L’Authentication API vous permet de gérer tous les aspects de l’identité des utilisateurs lorsque vous utilisez Auth0. Elle offre des points de terminaison pour permettre à vos utilisateurs de se connecter, de s’inscrire, de se déconnecter, d’accéder à des API, et plus encore. L’API prend en charge différents protocoles d’identité, comme OpenID Connect, OAuth 2.0, FAPI et SAML.
Cette API est conçue pour les personnes qui sont à l’aise avec l’intégration d’API RESTful. Si vous préférez une approche plus guidée, consultez nos guides de démarrage rapide ou nos bibliothèques.

​
URL de base

L’Authentication API est accessible via HTTPS. Toutes les URL mentionnées dans la documentation utilisent l’URL de base suivante : https://{yourDomain}

​
Méthodes d’authentification

Vous avez cinq options pour vous authentifier auprès de cette API :
  • Jeton d’accès OAuth2
  • ID client et Assertion d’application (applications confidentielles)
  • ID client et Secret client (applications confidentielles)
  • ID client (applications publiques)
  • Authentification mTLS (applications confidentielles)

​
Jeton d’accès OAuth2

Envoyez un Jeton d’accès valide dans l’en-tête Authorization en utilisant le schéma d’authentification Bearer. Vous trouverez un exemple dans le point de terminaison Get User Info. Dans ce scénario, vous obtenez un Jeton d’accès lorsque vous authentifiez un utilisateur, puis vous pouvez envoyer une requête à l’point de terminaison Get User Info en utilisant ce jeton dans l’en-tête Authorization afin de récupérer le profil de l’utilisateur.

​
ID client et assertion d’application

Générez une assertion d’application contenant un JSON Web Token (JWT) signé pour l’authentification. Dans le corps de la requête, incluez votre ID client, un paramètre client_assertion_type comportant la valeur urn:ietf:params:oauth:client-assertion-type:jwt-bearer, ainsi qu’un paramètre client_assertion contenant votre assertion signée. Consultez Private Key JWT pour voir des exemples.

​
ID client et Secret client

Envoyez l’ID client et le Secret client. La méthode à utiliser pour envoyer ces données dépend de la méthode d’authentification du point de terminaison de jeton configurée pour votre application. Si vous utilisez Post, vous devez envoyer ces données dans le corps JSON de votre requête. Si vous utilisez Basic, vous devez envoyer ces données dans l’en-tête Authorization, en utilisant le schéma d’authentification Basic. Pour générer votre valeur d’identification, concaténez votre ID client et votre Secret client, séparés par un deux-points (:), puis encodez le tout en Base64. Le point de terminaison de révocation du Jeton d’actualisation en est un exemple. Cette option est disponible uniquement pour les applications confidentielles (comme les applications capables de conserver des identifiants de manière sécurisée sans les exposer à des tiers non autorisés).

​
ID client

Envoyez l’ID client. Pour les applications publiques (applications qui ne peuvent pas stocker des identifiants de manière sécurisée, comme les SPA ou les applications mobiles), certains points de terminaison sont accessibles en utilisant uniquement l’ID client. Par exemple, l’octroi implicite.

​
Authentification mTLS

Générez un certificat, soit autosigné, soit signé par une autorité de certification. Ensuite, configurez le réseau de périphérie du client qui effectue la négociation mTLS. Une fois que votre réseau de périphérie a vérifié le certificat, transférez la requête vers le réseau de périphérie d’Auth0 avec les en-têtes suivants :
  • La clé API du Domaine personnalisé comme en-tête cname-api-key.
  • Le certificat client comme en-tête client-certificate.
  • Le statut de vérification du certificat client par l’autorité de certification comme en-tête client-certificate-ca-verified. Pour en savoir plus, consultez Transférer la requête.
Pour en savoir plus, consultez S’authentifier avec mTLS.

​
Paramètres

Pour les requêtes GET, tout paramètre qui n’est pas indiqué comme segment du chemin peut être transmis sous forme de paramètre de chaîne de requête HTTP : GET https://{yourDomain}/some-endpoint?param=value&param=value Pour les requêtes POST, les paramètres qui ne figurent pas dans l’URL doivent être encodés en JSON avec un Content-Type de application/json : curl --request POST --url 'https://{yourDomain}/some-endpoint' --header 'content-type: application/json' --data '{"param": "value", "param": "value"}'
Une exception est le flux d’authentification unique (SSO) SAML initié par l’IdP, qui utilise à la fois un paramètre de chaîne de requête et une valeur x-www-form-urlencoded.

​
Exemples de code

Pour chaque point de terminaison, vous trouverez des extraits que vous pouvez utiliser dans trois formats :
  • Requête HTTP
  • Commande cURL
  • JavaScript : selon le point de terminaison, chaque extrait peut utiliser la bibliothèque Auth0.js, du code Node.js ou du JavaScript simple
Chaque requête doit être envoyée avec un en-tête Content-Type défini sur application/json.

​
Test

Vous pouvez tester les points de terminaison à l’aide de l’Authentication API Debugger.

​
Authentication API Debugger

L’Authentication API Debugger est une extension Auth0 que vous pouvez utiliser pour tester plusieurs points de terminaison de l’Authentication API. Installer le Debugger Si vous avez déjà installé l’extension, passez à l’Authentication API Debugger. Le lien varie selon la région de votre locataire : Ouest des États-Unis, Europe centrale ou Australie. Pour en savoir plus sur les régions de locataire, consultez Créer des locataires.

​
Configurer les connexions

  1. Dans l’onglet Configuration, renseignez les champs Application (sélectionnez l’application que vous souhaitez utiliser pour le test) et Connexion (le nom de la connexion sociale à utiliser).
  2. Copiez l’URL de rappel et ajoutez-la à Allowed Callback URLs dans vos paramètres de l’application.
  3. Dans l’onglet OAuth2 / OIDC, sélectionnez OAuth2 / OIDC Login.

​
Options des points de terminaison

Configurez les autres points de terminaison avec les options suivantes :
  • Passwordless : dans l’onglet OAuth2 / OIDC, définissez Username comme le numéro de téléphone de l’utilisateur si connection=sms, ou comme le courriel de l’utilisateur si connection=email, et Password comme le code de vérification de l’utilisateur. Cliquez sur Resource Owner Endpoint.
  • SAML SSO : dans l’onglet Other Flows, sélectionnez SAML.
  • WS-Federation : dans l’onglet Other Flows, sélectionnez WS-Federation.
  • Logout : dans l’onglet Other Flows, sélectionnez Logout, ou Logout (Federated) pour également déconnecter l’utilisateur du fournisseur d’identité.
  • Ancien Login : dans l’onglet OAuth2 / OIDC, définissez les champs ID Token, Refresh Token et Target Client ID. Cliquez sur Delegation.
  • Ancienne délégation : dans l’onglet OAuth2 / OIDC, définissez Username et Password. Cliquez sur Resource Owner Endpoint.
  • Ancien Resource Owner : dans l’onglet OAuth2 / OIDC, définissez Username et Password, puis sélectionnez Resource Owner Endpoint.

​
Flux d’authentification

Configurez les flux d’authentification à l’aide des options suivantes :
  • Flux de code d’autorisation : dans l’onglet OAuth2 / OIDC, renseignez le champ Authorization Code avec le code récupéré dans l’octroi par code d’autorisation, puis le champ Code Verifier avec la clé. Cliquez sur OAuth2 Code Exchange.
  • Flux de code d’autorisation + PKCE : dans l’onglet OAuth2 / OIDC, renseignez le champ Authorization Code avec le code récupéré dans l’octroi par code d’autorisation, puis le champ Code Verifier avec la clé. Cliquez sur OAuth2 Code Exchange.
  • Flux des identifiants de l’application : dans l’onglet OAuth2 / OIDC, sélectionnez OAuth2 Client Credentials.

​
Erreurs

Lorsqu’une erreur se produit, vous recevez un objet d’erreur. La plupart de ces objets d’erreur contiennent un code d’erreur et une description de l’erreur afin que vos applications puissent cerner le problème plus efficacement. Si vous obtenez un code de réponse HTTP 4xx, vous pouvez supposer qu’il s’agit d’une requête incorrecte de votre côté. Les erreurs 5xx indiquent généralement un problème du côté d’Auth0. Dans ce cas, consultez la page d’état d’Auth0 et @auth0status sur Twitter pour vérifier l’état de nos systèmes. Dans tous les autres cas, vous pouvez utiliser nos options d’assistance.

​
Limites de débit

L’Authentication API est soumise à des limites de débit. Celles-ci varient selon le point de terminaison. Si vous dépassez la limite de débit établie pour un point de terminaison donné, vous recevrez la réponse 429 Too Many Requests avec le message suivant : Too many requests. Check the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers. Pour plus de détails sur les limites de débit, consultez la politique de limite de débit de l’API Auth0. Notez que, pour les connexions de base de données, Auth0 limite certains types de tentatives de connexion répétées selon le compte d’utilisateur et l’adresse IP. Pour plus de détails, consultez les limites de débit pour l’authentification par nom d’utilisateur et mot de passe.

​
Support

Si vous éprouvez des problèmes ou avez besoin d’aide pour votre dossier, vous pouvez toujours communiquer avec notre Support. Notez que si vous avez un abonnement gratuit et que votre période d’essai de 22 jours est terminée, vous ne pourrez pas accéder au Support Center ni y ouvrir de tickets. Dans ce cas, vous pouvez obtenir de l’aide par l’entremise de la communauté Auth0. Pour en savoir plus sur notre programme de support, consultez Options de support.