Skip to main content
Les applications confidentielles, contrairement aux applications publiques, peuvent stocker des identifiants de façon sécuritaire. Lorsque des applications confidentielles demandent l’accès ou des au point de terminaison de jeton, l’application doit s’authentifier auprès du . Au cours de cette demande de jetons, l’application fournit ses propres identifiants. De plus, les identifiants d’application peuvent également garantir l’authenticité et l’intégrité des paramètres de requête envoyés au point de terminaison /authorize. Pour en savoir plus sur les applications confidentielles et les applications publiques, consultez Confidential and Public Applications.

​
Méthodes d’authentification de l’application

Pour obtenir des jetons d’Auth0, votre application doit s’authentifier au moyen de l’Authentication API. Auth0 prend en charge les méthodes suivantes pour authentifier votre application :
  •  : Une méthode d’authentification symétrique. Dans l’authentification Client Secret, vous utilisez le Client Secret généré par Auth0 lorsque vous avez créé l’application.
  • Private Key  : Une méthode d’authentification asymétrique. Avec Private Key JWT, vous générez une paire de clés, publique et privée, à utiliser comme informations d’identification. Vous fournissez la clé publique et conservez la clé privée de façon sécurisée dans vos propres systèmes, sans la partager avec Auth0.
  • mTLS for  : Une méthode d’authentification asymétrique. Avec mTLS for OAuth, vous enregistrez auprès d’Auth0 un certificat client X.509 standard. Vous utilisez ensuite la clé privée correspondante pour établir de façon sécurisée le tunnel mTLS et envoyer des requêtes aux endpoints de votre tenant Auth0.

​
Authentification par Client Secret

L’authentification par Client Secret est une méthode d’authentification symétrique incluse dans la spécification OAuth 2.0. L’authentification par Client Secret est la méthode d’authentification par défaut dans Auth0. Cette méthode d’authentification est prise en charge par toutes les applications et tous les outils existants. Le Client Secret est une valeur à entropie élevée générée par Auth0 lorsque vous créez une application; il est connu à la fois de votre application et d’Auth0. Votre application s’authentifie en incluant le Client Secret dans la requête au serveur d’autorisation. L’utilisation du Client Secret comme information d’identification comporte certains risques de sécurité, surtout dans les scénarios qui exigent un niveau de sécurité plus élevé :
  • Le secret utilisé par l’application est partagé avec Auth0.
  • Le secret est transmis sur le réseau et pourrait être intercepté en cas d’attaque de type homme du milieu.
Pour renforcer votre sécurité, nous vous recommandons d’utiliser la méthode d’authentification Private Key JWT.
Une application ne peut avoir qu’un seul Client Secret. Il n’est pas possible de faire la rotation du secret pendant que vous mettez à jour votre mise en œuvre avec le nouveau secret. Pour en savoir plus, consultez Rotate Client Secrets.

​
Authentification par Private Key JWT

Private Key JWT est offert aux clients du forfait Enterprise. Pour passer à un forfait supérieur, consultez Auth0 pricing.
L’authentification par Private Key JWT est une méthode d’authentification asymétrique qui repose sur des paires de clés privées et publiques. Pour en savoir plus, consultez JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. Vous pouvez utiliser le ou l’Auth0 pour configurer un tenant afin d’utiliser Private Key JWT. Pour en savoir plus, consultez Configurer l’authentification Private Key JWT. Dans Private Key JWT, une requête au serveur d’autorisation comporte deux grandes étapes :
  1. Configurez les clés publique et privée :
    1. Générez une paire de clés (une clé publique et une clé privée).
    2. Enregistrez la clé privée auprès de l’application qui effectue la requête d’authentification, puis enregistrez la clé publique auprès du fournisseur d’identité (IdP).
  2. Créez des assertions pour les requêtes au serveur d’autorisation :
    1. Créez une nouvelle assertion avec les claims spécifiés au format JWT, puis signez-la avec la clé privée. Incluez cette assertion dans la requête à l’IdP.
    2. L’IdP valide l’assertion à l’aide de la clé publique.
Pour configurer Private Key JWT pour Auth0, consultez Configurer l’authentification Private Key JWT. Pour en savoir plus sur la création d’une assertion pour Private Key JWT, consultez S’authentifier avec Private Key JWT. L’utilisation de Private Key JWT présente certains avantages sur le plan de la sécurité :
  • La clé privée n’est pas transmise sur le réseau, ce qui réduit le risque d’exposition des informations d’identification de votre application. Les comme Auth0 n’ont pas connaissance de la clé privée, et seules les applications qui y ont accès peuvent créer des requêtes d’authentification.
  • Les assertions signées ont une courte durée de validité, ce qui réduit la fenêtre d’opportunité pour les attaques par rejeu.

​
mTLS for OAuth

Pour utiliser les fonctionnalités de Highly Regulated Identity, vous devez avoir un Enterprise Plan avec le module complémentaire Highly Regulated Identity. Consultez tarification Auth0 pour en savoir plus.
mTLS for OAuth authentifie les requêtes auprès du serveur d’autorisation au moyen du TLS mutuel, basé sur des certificats auto-signés ou une infrastructure à clé publique (PKI). Lisez S’authentifier avec mTLS pour en savoir plus sur le fonctionnement de l’authentification mTLS chez Auth0. La fonctionnalité mTLS for OAuth d’Auth0 cible d’abord les clients des secteurs fortement réglementés, comme la finance et la santé, qui disposent probablement déjà de déploiements mTLS. Pour faciliter son adoption, cette fonctionnalité s’appuie sur les domaines personnalisés et exploite l’infrastructure mTLS existante du client pour assurer le provisionnement et la vérification des certificats. Pour en savoir plus sur l’authentification avec mTLS et la configuration de votre réseau de périphérie, lisez S’authentifier avec mTLS et Configurer votre customer edge.
Vous pouvez configurer des alias de point de terminaison mTLS pour utiliser un sous-domaine précis avec mTLS for OAuth.
Pour savoir comment configurer mTLS, lisez Configurer l’authentification mTLS. Une fois votre réseau de périphérie configuré et mTLS activé, votre application doit établir le tunnel mTLS pour envoyer des requêtes à Auth0, comme expliqué dans Appeler le serveur d’autorisation. Avec mTLS, la clé privée du certificat client n’est pas transmise sur le réseau, ce qui réduit le risque d’exposer les identifiants de votre application. Les fournisseurs d’identité comme Auth0 n’ont pas accès à la clé privée. Seules les applications qui ont accès à la clé privée peuvent s’authentifier.
mTLS prend aussi en charge Sender Constraining ou Token Binding pour protéger les jetons d’accès contre les attaquants. Pour en savoir plus, lisez Configurer Sender Constraining. Token Binding n’exige pas d’identifiants d’application enregistrés au préalable, comme un certificat client, pour être utilisé avec mTLS.

​
Requête d’autorisation sécurisée par JWT (JAR)

Pour utiliser les fonctionnalités de Highly Regulated Identity, vous devez avoir un forfait Enterprise avec le module complémentaire Highly Regulated Identity. Consultez la tarification Auth0 pour en savoir plus.
La requête d’autorisation sécurisée par JWT (JAR) est une extension du protocole OAuth2 qui renforce la sécurité des requêtes d’autorisation. Pour ce faire, elle utilise un paramètre de requête JSON Web Token (JWT) afin de protéger l’intégrité et la confidentialité des paramètres de la requête d’autorisation. Vous pouvez utiliser l’Auth0 Management API pour configurer JAR pour votre application. La mise en œuvre de JAR par Auth0 repose sur la cryptographie asymétrique : vous enregistrez la clé publique, tandis que vous conservez la clé privée en sécurité de votre côté. Pour en savoir plus, consultez Configurer les requêtes d’autorisation sécurisées par JWT. Lorsque vous utilisez JAR, le client crée un JWT qui contient les paramètres de la requête d’autorisation, le signe avec sa clé privée et l’envoie au serveur d’autorisation. Le serveur d’autorisation vérifie ensuite la signature à l’aide de la clé publique du client et, si elle est valide, extrait du JWT les paramètres de la requête d’autorisation et traite la requête comme d’habitude. Pour en savoir plus sur l’utilisation de JAR, consultez Flux de code d’autorisation avec des requêtes d’autorisation sécurisées par JWT (JAR).

​
Enregistrement des clés et des certificats

Vous devriez générer une paire de clés distincte pour chaque type d’utilisation des justificatifs d’authentification. Par exemple, ne réutilisez pas les mêmes paires de clés pour JAR et pour l’authentification Private Key JWT.
Vous pouvez enregistrer deux clés publiques pour une application en même temps. Auth0 effectue la vérification à l’aide de la clé appropriée et vous permet d’effectuer une rotation sans interruption de service. Une fois l’ancienne clé supprimée ou désactivée, toutes les requêtes signées avec la clé privée correspondante sont invalidées. Remarque : Auth0 prend en charge les algorithmes suivants pour l’authentification d’application et la signature des requêtes d’autorisation : RS256, RS384 et PS256. Assurez-vous de fournir les clés appropriées pour chacun d’eux. Pour en savoir plus, consultez Configurer l’authentification Private Key JWT et Configurer les requêtes d’autorisation sécurisées par JWT. De même, pour les certificats clients mTLS, vous pouvez enregistrer en même temps deux certificats clients X.509 (auto-signés ou avec le DN du sujet du certificat de l’autorité de certification) pour une application. Auth0 effectue la vérification avec les deux certificats clients, ce qui vous permet d’effectuer une rotation des certificats sans interruption de service.

​
Mettre à jour la méthode d’authentification d’une application

Vous pouvez mettre à jour la méthode d’authentification d’une application dans Auth0 Dashboard. Pour en savoir plus, consultez Paramètres des identifiants.

​
En savoir plus