Passer au contenu principal
Les applications confidentielles, contrairement aux applications publiques, peuvent stocker des identifiants de manière sécuritaire. Lorsque des applications confidentielles demandent un accès ou des à partir du point de terminaison de jetons, l’application doit s’authentifier auprès du . Au cours de cette demande de jetons, l’application fournit des identifiants qui lui sont propres. De plus, les identifiants de l’application peuvent aussi assurer l’authenticité et protéger 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 Applications confidentielles et publiques.

​
Méthodes d’authentification de l’application

Pour obtenir des jetons auprès 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. Avec l’authentification par Secret client, vous utilisez le Secret client généré par Auth0 lors de la création de l’application.
  • Private Key  : Une méthode d’authentification asymétrique. Avec Private Key JWT, vous générez une paire de clés, une publique et une privée, à utiliser comme identifiants. Vous fournissez la clé publique et stockez la clé privée de façon sécurisée dans vos propres systèmes, sans la partager avec Auth0.
  • mTLS pour  : Une méthode d’authentification asymétrique. Avec mTLS pour OAuth, vous enregistrez un certificat client X.509 standard auprès d’Auth0. Ensuite, vous utilisez la clé privée correspondante pour établir de façon sécurisée le tunnel mTLS afin d’envoyer des requêtes aux points de terminaison de votre locataire sur Auth0.

​
Authentification par Secret client

L’authentification par Secret client est une méthode d’authentification symétrique incluse dans la spécification OAuth 2.0. L’authentification par Secret client 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 Secret client est une valeur à forte entropie générée par Auth0 lorsque vous créez une application, et connue à la fois par votre application et par Auth0. Votre application s’authentifie en incluant le Secret client dans la requête envoyée au serveur d’autorisation. L’utilisation du Secret client comme information d’authentification comporte certains risques de sécurité, surtout dans les scénarios exigeant 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 Secret client. Il n’est pas possible d’en faire la rotation pendant que vous mettez à jour votre implémentation 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 plan Enterprise. Pour passer à ce plan, 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ée et publique. 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’ d’Auth0 pour configurer un locataire 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 étapes principales :
  1. Configurer 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 et la clé publique auprès du fournisseur d’identité (IdP).
  2. Créer des assertions pour les requêtes au serveur d’autorisation :
    1. Créez une nouvelle assertion avec les claims spécifiées au format JWT et signez-la avec la clé privée. Incluez cette assertion dans la requête envoyée à 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 en matière de sécurité :
  • La clé privée n’est pas transmise sur le réseau, ce qui réduit le risque d’exposition des identifiants de votre application. Les comme Auth0 ne connaissent pas 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 d’expiration, ce qui réduit le risque d’attaques par rejeu.

​
mTLS pour OAuth

Pour utiliser les fonctionnalités Highly Regulated Identity, vous devez disposer d’un plan Enterprise avec le module complémentaire Highly Regulated Identity. Consultez Auth0 Pricing pour en savoir plus.
Le mTLS pour OAuth authentifie les requêtes adressées au serveur d’autorisation au moyen du protocole TLS mutuel, basé sur des certificats autosignés ou une infrastructure à clé publique (PKI). Consultez Authenticate with mTLS pour en savoir plus sur le fonctionnement de l’authentification mTLS dans Auth0. Le mTLS pour OAuth d’Auth0 cible d’abord les clients de secteurs fortement réglementés, comme la finance et les soins de santé, qui disposent probablement déjà de déploiements mTLS. Pour faciliter l’adoption par les clients, la fonctionnalité mTLS s’appuie sur les domaines personnalisés et exploite l’infrastructure mTLS existante du client pour assurer l’approvisionnement 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, consultez Authenticate with mTLS et Set up your customer edge.
Vous pouvez configurer des alias de point de terminaison mTLS pour utiliser un sous-domaine précis avec mTLS pour OAuth.
Pour savoir comment configurer mTLS, consultez Configure mTLS Authentication. Une fois votre réseau de périphérie configuré et mTLS mis en place, votre application doit établir le tunnel mTLS pour envoyer des requêtes à Auth0, comme expliqué dans Call the authorization server. Avec mTLS, la clé privée du certificat de l’application 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 y ont accès peuvent s’authentifier.
mTLS prend également en charge Sender Constraining ou Token Binding afin de protéger les jetons d’accès contre les attaquants. Pour en savoir plus, consultez Configure Sender Constraining. Token Binding ne nécessite pas d’identifiants d’application préalablement enregistrés, comme un certificat d’application, pour être utilisé avec mTLS.

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

Pour utiliser les fonctionnalités Highly Regulated Identity, vous devez disposer d’un plan Enterprise avec le module complémentaire Highly Regulated Identity. Consultez Auth0 Pricing pour en savoir plus.
La JWT-Secured Authorization Request (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 JWT (JSON Web Token) 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. L’implémentation JAR d’Auth0 repose sur la cryptographie asymétrique : vous enregistrez la clé publique et conservez la clé privée de manière sécurisée de votre côté. Pour en savoir plus, consultez Configure JWT-Secured Authorization Requests. Lors de l’utilisation de JAR, l’application crée un JWT qui inclut 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 de l’application et, si la signature est valide, extrait du JWT les paramètres de la requête d’autorisation et traite ensuite la requête normalement. Pour en savoir plus sur l’utilisation de JAR, consultez Authorization Code Flow with JWT-Secured Authorization Requests (JAR).

​
Enregistrement des clés et des certificats

Vous devriez générer une paire de clés distincte pour chaque type d’usage des informations d’authentification. Par exemple, n’utilisez pas la même paire de clés à la fois pour JAR et pour l’authentification Private Key JWT.
Vous pouvez enregistrer simultanément deux clés publiques pour une application. Auth0 effectue la vérification à l’aide de la clé appropriée et vous permet de faire une rotation sans interruption. 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 des applications et la signature des demandes d’autorisation : RS256, RS384 et PS256. Assurez-vous de fournir les clés appropriées pour chacun. Pour en savoir plus, consultez Configure Private JWT Authentication et Configure JWT-Secured Authorization Requests. De même, pour les certificats clients mTLS, vous pouvez enregistrer simultanément deux certificats clients X.509 (autosignés ou avec le DN du sujet du certificat de l’AC) pour une application. Auth0 effectue la vérification à l’aide des deux certificats clients, ce qui vous permet de faire une rotation des certificats sans interruption.

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

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

​
En savoir plus