> ## 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écouvrez comment implémenter l’authentification du client par JWT avec clé privée pour vos connexions d’entreprise.
# Authentification du client par JWT avec clé privée pour les connexions Okta et OIDC
L’authentification du client par JWT avec clé privée est une méthode alternative d’authentification du client pour les connexions d’entreprise OpenID Connect (OIDC) et Okta Workforce. Alors que l’authentification du client s’effectue le plus souvent en transmettant un secret client partagé, l’authentification du client par JWT avec clé privée transmet plutôt un JWT signé afin d’améliorer la sécurité de l’application.
En utilisant cette fonctionnalité, vous pouvez éviter certaines faiblesses de sécurité courantes souvent observées avec l’authentification standard par secret client, notamment :
* Un risque accru d’interception et de réutilisation, puisque les secrets client doivent être transmis entre les parties à chaque requête.
* Des mécanismes limités pour appliquer une date d’expiration et empêcher la réutilisation par des acteurs malveillants.
* Un risque accru de fuite ou d’exposition puisque les deux parties détiennent le secret client.
Vous pouvez configurer l’authentification du client par JWT avec clé privée pour vos connexions d’entreprise OIDC et Okta Workforce au moyen de Auth0 Dashboard ou de la Management API.
## Fonctionnement
Le flux de connexion OIDC utilise des points de terminaison authentifiés comme `/oauth/token` ou `/oauth/par` pour vérifier l’identité d’une application auprès du serveur d’autorisation ou du fournisseur OpenID. Avec l’authentification du client par JWT avec clé privée, un JWT d’assertion du client signé est transmise au fournisseur OpenID au lieu d’un secret client.
Le JWT d’assertion du client contient les revendications suivantes :
* Un `aud` (audience) qui identifie le point de terminaison de jeton du fournisseur OpenID.
* Un `jti` (ID JWT) pour permettre un usage unique ou une protection contre la relecture.
* Un `exp` (heure d’expiration) qui limite la période de validité du jeton.
* Un `sub` et `iss` qui identifient l’ID client.
L’authentification du client par JWT avec clé privée offre une méthode d’authentification plus sécurisée, car elle élimine l’utilisation de secrets client partagés. Le JWT est plutôt signé à l’aide de la clé privée de l’application, et le fournisseur OpenID n’a accès qu’à la clé publique.
### Flux d’authentification du client avec Private Key JWT
Après s’être authentifié auprès d’un fournisseur d’identité (IdP) en amont, l’utilisateur est redirigé vers Auth0 avec un code d’autorisation, qui est échangé contre des jetons au point de terminaison de jeton du fournisseur OpenID. Lorsque Private Key JWT est activé pour une connexion, l’appel au point de terminaison de jeton du fournisseur OpenID utilise une assertion du client au lieu d’un secret client, afin de renforcer la sécurité de l’authentification.
Les étapes suivantes présentent un flux d’authentification du client avec Private Key JWT typique.
Pour effectuer ce flux, vous devez d’abord configurer une connexion OIDC ou Okta Workforce, nouvelle ou existante, avec `token_endpoint_auth_method=private_key_jwt`, au moyen de l’Auth0 Dashboard ou de la Management API. Pour en savoir plus, consultez la section [Configurer l’authentification du client avec Private Key JWT](#configure-private-key-jwt-client-authentication).
1. Après avoir configuré votre connexion, Auth0 génère et stocke automatiquement deux paires de clés publiques et privées.
* Une paire de clés correspond à l’ensemble `current` actif, tandis que l’autre est étiquetée `next` pour prendre en charge la [rotation des clés](#rotate-signing-keys).
2. Selon votre IdP, vous devez ensuite soit :
* télécharger la clé publique `current` et téléverser le fichier sur le serveur d’autorisation;
* copier et coller le [`jwks_uri`](#retrieve-signing-keys) dans le serveur d’autorisation.
3. Un utilisateur effectue une action qui nécessite une authentification, comme se connecter à votre application.
4. Auth0 envoie une requête au serveur d’autorisation pour lancer l’authentification.
5. Le serveur d’autorisation affiche à l’utilisateur des écrans d’authentification et de consentement.
6. L’utilisateur s’authentifie et donne son consentement au serveur d’autorisation.
7. Le serveur d’autorisation envoie un code d’autorisation à Auth0.
8. Auth0 génère un JWT d’assertion du client et le signe à l’aide de la clé privée `current`.
9. Auth0 transmet le JWT d’assertion du client au serveur d’autorisation.
10. Le serveur d’autorisation repère l’application associée au `client_id` fourni.
11. Le serveur d’autorisation récupère les clés publiques depuis Auth0 si un `jwks_uri` a été fourni; sinon, il identifie la clé publique enregistrée à l’étape 2.
12. Si le `jwks_uri` a été demandé, Auth0 renvoie les clés publiques sous forme de JWKS.
13. Le serveur d’autorisation valide le JWT en vérifiant la signature à l’aide de la clé publique `current`, identifiée par `kid` dans l’en-tête du JWT `client_assertion`.
14. Le serveur d’autorisation génère un jeton d’accès.
15. Le serveur d’autorisation transmet le jeton d’accès à Auth0.
16. À l’aide du jeton d’accès, Auth0 demande une ressource au serveur de ressources.
17. Le serveur de ressources fournit la ressource pour terminer le flux.
## Configurer l’authentification du client par JWT avec clé privée
Vous pouvez configurer les connexions d’entreprise OIDC et Okta Workforce pour utiliser l’authentification du client par JWT avec clé privée dans l’Auth0 Dashboard ou au moyen de la Management API. Les étapes pour chaque méthode sont indiquées ci-dessous.
* Auth0 génère automatiquement une paire de clés de signature privée et publique pour chaque connexion.
* Vous pouvez utiliser les algorithmes suivants pour signer les JWT d’assertion client : `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `ES256` et `ES384` pour les connexions d’entreprise Okta et OIDC. La valeur par défaut est `RS256` si aucun algorithme n’est précisé.
* Les JWT signés expirent automatiquement après 60 secondes.
#### Auth0 Dashboard
Vous pouvez utiliser le Auth0 Dashboard pour configurer l’authentification du client par JWT avec clé privée pour les connexions OIDC et Okta Workforce, qu’elles soient nouvelles ou existantes.
1. Dans votre Auth0 Dashboard, accédez à [Authentication > Enterprise](https://manage.auth0.com/#/connections/enterprise).
2. À côté de **OpenID Connect** ou de **Okta Workforce**, sélectionnez **Create**.
3. Dans la section **General**, fournissez les détails de votre nouvelle connexion, y compris son nom et l’URL de découverte.
4. Configurez les champs suivants pour activer l’authentification par JWT avec clé privée :
* Réglez **Communication Channel** à **Back Channel**.
* Réglez **Authentication Method** à **Private Key JWT**.
5. Sélectionnez **Create** pour enregistrer votre nouvelle connexion.
1. Dans votre Auth0 Dashboard, accédez à [Authentication > Enterprise](https://manage.auth0.com/#/connections/enterprise).
2. À côté de **OpenID Connect** ou de **Okta Workforce**, sélectionnez **Browse**.
3. Choisissez la connexion appropriée, puis accédez à son onglet **Credentials**.
4. Sous **Authentication Settings**, configurez les éléments suivants :
* Réglez **Communication Channel** à **Back Channel**.
* Réglez **Authentication Method** à **Private Key JWT**.
5. Sélectionnez **Save**.
6. Dans la fenêtre de confirmation, sélectionnez **Change** pour appliquer vos modifications.
#### Management API
Vous pouvez utiliser la Management API pour configurer l’authentification du client par JWT avec clé privée pour les connexions OIDC, nouvelles comme existantes.
Pour créer une nouvelle connexion OIDC qui utilise l’authentification du client par JWT avec clé privée, appelez le point de terminaison [Créer une connexion](https://auth0.com/docs/api/management/v2/connections/post-connections) en définissant les propriétés `connection.options` suivantes de façon appropriée :
| Propriété | Description |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type` | Définissez cette propriété sur `back_channel`. |
| `token_endpoint_auth_method` | Méthode d’authentification utilisée au point de terminaison de jeton du fournisseur d’identité. Définissez-la sur `private_key_jwt` pour utiliser une assertion JWT signée afin de renforcer la sécurité, ou sur `client_secret_post` pour envoyer les informations d’identification dans le corps de la requête. La valeur par défaut est `client_secret_post`. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `token_endpoint_auth_signing_alg` | Facultatif. Algorithme utilisé pour signer les assertions du client. Valeurs acceptées : `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `ES256`, `ES384`. Si aucune valeur n’est définie, la valeur par défaut est `RS256`. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `id_token_signed_response_algs` | Facultatif. Liste des algorithmes autorisés pour vérifier les ID tokens émis par le fournisseur d’identité. Lorsqu’elle est définie, Auth0 rejette les ID tokens signés avec un algorithme qui ne figure pas dans cette liste. Valeurs acceptées : `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `ES256`, `ES384`. Si elle n’est pas définie, Auth0 accepte les ID tokens signés avec n’importe quel algorithme pris en charge. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `token_endpoint_jwtca_aud_format` | Facultatif. Spécifie le format de la revendication `aud` (audience) dans le JWT utilisé pour l’authentification du client au point de terminaison de jeton. Définissez-la sur `issuer` pour utiliser l’URL de l’émetteur OIDC, ou sur `token_endpoint` pour utiliser l’URL du point de terminaison de jeton. La valeur par défaut est `token_endpoint`. |
**Exemple d’appel POST**
```js lines theme={null}
POST /api2/connections
{
strategy: 'oidc',
options: {
type: "back_channel",
token_endpoint_auth_method: "private_key_jwt",
token_endpoint_auth_signing_alg: "RS256",
id_token_signed_response_algs: ["RS256", "RS384"]
},
…
}
```
Pour modifier une connexion OIDC existante afin qu’elle utilise l’authentification du client par JWT avec clé privée, appelez le point de terminaison [Mettre à jour une connexion](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) en définissant les propriétés `connection.options` suivantes de façon appropriée :
| Propriété | Description |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type` | Définissez cette propriété sur `back_channel`. |
| `token_endpoint_auth_method` | Méthode d’authentification utilisée au point de terminaison de jeton du fournisseur d’identité. Définissez-la sur `private_key_jwt` pour utiliser une assertion JWT signée afin de renforcer la sécurité, ou sur `client_secret_post` pour envoyer les informations d’identification dans le corps de la requête. La valeur par défaut est `client_secret_post`. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `token_endpoint_auth_signing_alg` | Facultatif. Algorithme utilisé pour signer les assertions du client. Valeurs acceptées : `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `ES256`, `ES384`. Si aucune valeur n’est définie, la valeur par défaut est `RS256`. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `id_token_signed_response_algs` | Facultatif. Liste des algorithmes autorisés pour vérifier les ID tokens émis par le fournisseur d’identité. Lorsqu’elle est définie, Auth0 rejette les ID tokens signés avec un algorithme qui ne figure pas dans cette liste. Valeurs acceptées : `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `ES256`, `ES384`. Si elle n’est pas définie, Auth0 accepte les ID tokens signés avec n’importe quel algorithme pris en charge. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `token_endpoint_jwtca_aud_format` | Facultatif. Spécifie le format de la revendication `aud` (audience) dans le JWT utilisé pour l’authentification du client au point de terminaison de jeton. Définissez-la sur `issuer` pour utiliser l’URL de l’émetteur OIDC, ou sur `token_endpoint` pour utiliser l’URL du point de terminaison de jeton. La valeur par défaut est `token_endpoint`. |
**Exemple d’appel PATCH**
```js lines theme={null}
PATCH /api2/connections/{id}
{
strategy: 'oidc',
options: {
type: "back_channel",
token_endpoint_auth_method: "private_key_jwt",
token_endpoint_auth_signing_alg: "RS256",
id_token_signed_response_algs: ["RS256", "RS384"]
},
…
}
```
## Récupérer les clés de signature
Une fois votre connexion configurée pour utiliser l’authentification du client par JWT avec clé privée, vous pouvez récupérer ses clés publiques à partir de l’Auth0 Dashboard, de la Management API ou d’une URI JWKS publique.
Pour récupérer les clés de signature dans l’Auth0 Dashboard :
1. Accédez à [Authentication > Enterprise](https://manage.auth0.com/#/connections/enterprise).
2. À côté de **OpenID Connect** ou **Okta Workforce**, sélectionnez **Browse**.
3. Choisissez la connexion appropriée, puis accédez à son onglet **Credentials**.
4. Repérez la section **Credentials** et sélectionnez l’icône **Download** à côté de la clé de signature appropriée.
Pour afficher les clés publiques au moyen de la Management API, appelez le point de terminaison [Get connection keys](https://auth0.com/docs/api/management/v2/connections/get-keys) à l’aide de l’ID de votre connexion.
L’utilisation de ce point de terminaison exige le scope `read:connections_keys`.
**Exemple d’appel GET**
```js lines theme={null}
GET /api2/connections/{id}/keys
```
**Exemple de réponse**
```js lines expandable theme={null}
{
cert: "-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBAgIJP...Ek=
-----END CERTIFICATE-----",
pkcs7: "-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcNAQcCo...AA==
-----END PKCS7-----
",
kid: "E4CXqUP6r92yo0f_sdkdC",
next: true,
fingerprint: "7F:33:86:D9:4A:98:B2:DC:B0:41:74:54:DA:31:E7:74:42:32:96:8C",
thumbprint: "7F3386D94A98B2DCB0417454DA31E7744232968C"
},
{
cert: "-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBAgI...Ss=
-----END CERTIFICATE-----",
pkcs7: "-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcNAQ...AA==
-----END PKCS7-----
",
kid: "_4WuXpXlwwmSE65saKWDM",
current: true,
current_since: "2025-01-24T08:50:06.662Z",
fingerprint: "33:7D:6F:35:46:31:AD:6E:69:43:01:A2:77:DF:8E:73:64:F6:E8:5B",
thumbprint: "337D6F354631AD6E694301A277DF8E7364F6E85B"
},
{
cert: "-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBA...6Q=
-----END CERTIFICATE-----",
pkcs7: "-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcN...AA==
-----END PKCS7-----
",
kid: "roUD9STeDy9qBTx5XjaTz",
previous: true,
current_since: "2025-01-24T08:48:51.523Z",
current_until: "2025-01-24T08:50:06.663Z",
fingerprint: "44:D3:DD:3B:63:99:59:9A:39:D9:F4:F0:4F:1B:AC:BB:18:72:40:5C",
thumbprint: "44D3DD3B6399599A39D9F4F04F1BACBB1872405C"
}
```
Certains fournisseurs d’identité permettent de fournir des clés publiques pour private\_key\_jwt sous la forme d’une URI JWKS publique.
Si des clés publiques ont été générées pour une connexion, vous pouvez les récupérer en ajoutant l’URI suivante à la configuration de votre IdP :
```http wrap lines theme={null}
https://{domaine Auth0}/oauth/connection/{nom de la connexion}/.well-known/jwks.json
```
Les URI JWKS sont assujetties aux limites de débit globales. Vous pouvez mettre en cache les clés publiques pour éviter d’atteindre ces limites. Comme bonne pratique, Auth0 recommande une durée de mise en cache d’au moins 5 à 10 minutes afin d’éviter d’appeler le point de terminaison de l’URI JWKS à chaque tentative de connexion.
## Rotation des clés de signature
L’authentification du client par JWT avec clé privée prend en charge la rotation des clés de signature afin d’offrir une sécurité accrue par rapport au caractère statique et à la longue durée de vie des secrets client partagés. La rotation des clés de signature renforce la sécurité en limitant la durée d’exposition d’une même clé, ce qui réduit la fenêtre pendant laquelle un attaquant pourrait la compromettre. Elle permet aussi de réagir rapidement à la suite d’un incident de sécurité.
Pour éviter toute interruption, Auth0 recommande d’effectuer la rotation des clés de signature au bout d’un an. Vous pouvez utiliser soit l’Auth0 Dashboard, soit la Management API pour effectuer la rotation des clés de signature :
Pour effectuer la rotation de vos clés de signature dans l’Auth0 Dashboard :
1. Accédez à [Authentication > Enterprise](https://manage.auth0.com/#/connections/enterprise).
2. À côté de **OpenID Connect** ou **Okta Workforce**, sélectionnez **Browse**.
3. Choisissez la connexion appropriée, puis ouvrez son onglet **Credentials**.
4. Dans la section **Credentials**, sélectionnez **Rotate Keys**.
5. Dans la fenêtre contextuelle, sélectionnez **Save** pour confirmer la rotation.
Après la rotation, tout JWT en cours signé avec la clé précédente devient immédiatement invalide et sa vérification peut échouer auprès de votre IdP.
Pour consulter les clés publiques au moyen de la Management API, appelez le point de terminaison Rotate Connection Signing Keys à l’aide de l’ID de votre connexion.
L’utilisation de ce point de terminaison nécessite les scopes `create:connections_keys` et `update:connections_keys`.
```js lines theme={null}
POST /v2/connections/{id}/keys/rotate
```
Après la rotation, tout JWT en cours signé avec la clé précédente devient immédiatement invalide et sa vérification peut échouer auprès de votre IdP.
Dans votre connexion OIDC ou Okta Workforce, vos clés de signature se voient attribuer l’un des états suivants :
* **Actuelle** : la clé de signature actuellement utilisée pour l’application.
* **Suivante** : la prochaine clé de signature qui sera utilisée pour l’application une fois la clé actuelle révoquée.
* **Précédente** : une clé de signature expirée ou autrement révoquée qui n’est plus utilisée.
Lorsque l’authentification du client par JWT avec clé privée est activée pour la première fois pour une connexion, seule une paire de clés `current` et `next` est générée. Une clé n’est marquée comme `previous` qu’après une rotation.
Lors de la rotation des clés de signature, les changements suivants se produisent :
1. La clé `current` est supprimée et révoquée, et tout JWT signé avec cette clé échouera à la vérification auprès de l’IdP si l’IdP a été configuré avec le `jwks_uri`.
2. La clé `current` se voit attribuer l’état `previous`.
3. La clé `next` devient la clé active et reçoit l’état `current`. Désormais, les JWT d’assertion du client seront signés avec cette clé.
4. Une nouvelle clé de signature est automatiquement générée pour remplacer la clé ayant fait l’objet de la rotation. La nouvelle clé de signature reçoit l’état `next`.
## En savoir plus
* [Connecter votre application Auth0 à la connexion d’entreprise Okta Workforce](/fr-CA/docs/authenticate/identity-providers/enterprise-identity-providers/okta)
* [Se connecter à un fournisseur d’identité OpenID Connect](/fr-CA/docs/authenticate/identity-providers/enterprise-identity-providers/oidc)