> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Décrit les façons dont vous pouvez authentifier votre application auprès des services Auth0.

# Identifiants d’application

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 <Tooltip tip="Jeton d’identité : identifiant destiné au client lui-même, plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=ID+tokens">jetons d’identité</Tooltip> au [point de terminaison de jeton](https://auth0.com/docs/api/authentication#get-token), l’application doit s’authentifier auprès du <Tooltip tip="Jeton d’identité : identifiant destiné au client lui-même, plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+server">serveur d’autorisation</Tooltip>. 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`](https://auth0.com/docs/api/authentication#authorize-application).

Pour en savoir plus sur les applications confidentielles et les applications publiques, consultez [Confidential and Public Applications](/docs/fr-ca/get-started/applications/confidential-and-public-applications).

<div id="application-authentication-methods">
  ## Méthodes d’authentification de l’application
</div>

Pour obtenir des jetons d’Auth0, votre application doit s’authentifier au moyen de l’[Authentication API](https://auth0.com/docs/api/authentication). Auth0 prend en charge les méthodes suivantes pour authentifier votre application :

* **<Tooltip tip="Client Secret : secret utilisé par un client (application) pour s’authentifier auprès du serveur d’autorisation; il ne doit être connu que du client et du serveur d’autorisation et doit être suffisamment aléatoire pour ne pas pouvoir être deviné." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Client+Secret">Client Secret</Tooltip> :** 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 <Tooltip tip="JSON Web Token (JWT) : format standard d’ID Token (et souvent de jeton d’accès) utilisé pour représenter de façon sécurisée des claims entre deux parties." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=JWT">JWT</Tooltip> :** 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 <Tooltip tip="OAuth 2.0 : framework d’autorisation qui définit les protocoles et les workflows d’autorisation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OAuth">OAuth</Tooltip> :** 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.

<div id="client-secret-authentication">
  ### Authentification par Client Secret
</div>

L’authentification par Client Secret est une méthode d’authentification symétrique incluse dans la [spécification OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749#section-2.3). 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.

<Warning>
  Pour renforcer votre sécurité, nous vous recommandons d’utiliser la méthode d’authentification Private Key JWT.
</Warning>

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](/docs/fr-ca/get-started/applications/rotate-client-secret).

<div id="private-key-jwt-authentication">
  ### Authentification par Private Key JWT
</div>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Private Key JWT est offert aux clients du forfait Enterprise. Pour passer à un forfait supérieur, consultez [Auth0 pricing](https://auth0.com/pricing/).
</Callout>

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](http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer).

Vous pouvez utiliser le <Tooltip tip="Auth0 Dashboard : le principal produit d’Auth0 pour configurer vos services." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Auth0+Dashboard">Auth0 Dashboard</Tooltip> ou l’Auth0 <Tooltip tip="Auth0 Dashboard : le principal produit d’Auth0 pour configurer vos services." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Management+API">Management API</Tooltip> pour configurer un tenant afin d’utiliser Private Key JWT. Pour en savoir plus, consultez [Configurer l’authentification Private Key JWT.](/docs/fr-ca/get-started/applications/configure-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](/docs/fr-ca/secure/application-credentials/generate-rsa-key-pair) (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](/docs/fr-ca/get-started/applications/configure-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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-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 <Tooltip tip="Identity Provider (IdP) : service qui stocke et gère les identités numériques." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Identity+providers">fournisseurs d’identité</Tooltip> 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.

<div id="mtls-for-oauth">
  ### mTLS for OAuth
</div>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](https://auth0.com/pricing/) pour en savoir plus.
</Callout>

[mTLS for OAuth](https://www.rfc-editor.org/rfc/rfc8705) 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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-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](/docs/fr-ca/customize/custom-domains) 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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-mtls) et [Configurer votre customer edge](/docs/fr-ca/get-started/applications/configure-mtls/set-up-the-customer-edge).

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Vous pouvez configurer des [alias de point de terminaison mTLS](/docs/fr-ca/get-started/applications/configure-mtls/configure-mtls-for-a-tenant#enable-mtls-endpoint-aliases) pour utiliser un sous-domaine précis avec mTLS for OAuth.
</Callout>

Pour savoir comment configurer mTLS, lisez [Configurer l’authentification mTLS](/docs/fr-ca/get-started/applications/configure-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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-mtls#call-the-authorization-server).

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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/docs/fr-ca/secure/sender-constraining/configure-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.
</Callout>

<div id="jwt-secured-authorization-request-jar">
  ### Requête d’autorisation sécurisée par JWT (JAR)
</div>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](https://auth0.com/pricing/) pour en savoir plus.
</Callout>

La [requête d’autorisation sécurisée par JWT (JAR)](https://datatracker.ietf.org/doc/rfc9101/) 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](https://auth0.com/docs/api/management/v2) 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](/docs/fr-ca/get-started/applications/configure-jar).

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)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar).

<div id="key-and-certificate-registration">
  ### Enregistrement des clés et des certificats
</div>

<Warning>
  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.
</Warning>

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](/docs/fr-ca/get-started/applications/configure-private-key-jwt) et [Configurer les requêtes d’autorisation sécurisées par JWT](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar).

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.

<div id="update-application-authentication-method">
  ## Mettre à jour la méthode d’authentification d’une application
</div>

Vous pouvez mettre à jour la méthode d’authentification d’une application dans Auth0 Dashboard. Pour en savoir plus, consultez [Paramètres des identifiants](/docs/fr-ca/get-started/applications/credentials).

<div id="learn-more">
  ## En savoir plus
</div>

* [Paramètres des identifiants](/docs/fr-ca/get-started/applications/credentials)
* [S’authentifier avec Private Key JWT](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt)
* [Rotation des identifiants](/docs/fr-ca/get-started/applications/rotate-credentials)
* [Configurer l’authentification Private Key JWT](/docs/fr-ca/get-started/applications/configure-private-key-jwt)
* [S’authentifier avec mTLS](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-mtls)