> ## 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 mettre en œuvre Private Key JWT Client Authentication pour vos connexions d’entreprise.
# Private Key JWT Client Authentication pour les connexions Okta et OIDC
Private Key JWT Client Authentication est une méthode d’authentification du client alternative pour les connexions d’entreprise OpenID Connect (OIDC) et Okta Workforce. Alors que l’authentification du client se fait le plus souvent au moyen d’un secret client partagé, Private Key JWT Client Authentication utilise plutôt un JWT signé afin de renforcer la sécurité de l’application.
En utilisant cette fonctionnalité, vous pouvez éviter certaines faiblesses de sécurité courantes souvent associées à 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 pour chaque requête.
* Des mécanismes limités pour imposer 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 Private Key JWT Client Authentication pour vos connexions d’entreprise OIDC et Okta Workforce au moyen du 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’un client auprès du serveur d’autorisation ou du fournisseur OpenID. Avec Private Key JWT Client Authentication, une assertion JWT client signée est transmise au fournisseur OpenID au lieu d’un secret client.
L’assertion JWT client contient les claims suivants :
* Un `aud` (audience) qui identifie l’point de terminaison de jeton du fournisseur OpenID.
* Un `jti` (ID JWT) pour permettre un usage unique ou une protection contre les attaques par rejeu.
* Un `exp` (heure d’expiration) qui limite la période de validité du jeton.
* Un `sub` et un `iss` qui identifient le client ID.
Private Key JWT Client Authentication offre une méthode d’authentification plus sécurisée en éliminant l’utilisation de secrets client partagés. Le JWT est plutôt signé à l’aide de la clé privée du client, et le fournisseur OpenID n’a accès qu’à la clé publique.
### Flux d’authentification client Private Key JWT
Une fois que l’utilisateur a terminé son authentification auprès d’un fournisseur d’identité (IdP) en amont, il est redirigé vers Auth0 avec un code d’autorisation, qui est ensuite échangé contre des jetons au point de terminaison de jeton du fournisseur OpenID. Lorsque Private Key JWT est activé pour une connexion, la requête au point de terminaison de jeton du fournisseur OpenID utilise une assertion client plutôt qu’un secret client, pour une authentification plus sécurisée.
Les étapes suivantes illustrent un flux d’authentification client Private Key JWT typique.
Pour suivre ce flux, vous devez d’abord configurer une connexion OIDC ou Okta Workforce, nouvelle ou existante, avec `token_endpoint_auth_method=private_key_jwt`, soit dans votre Auth0 Dashboard, soit au moyen de la Management API. Pour en savoir plus, consultez la section [Configurer l’authentification client 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 actif `current`, tandis que l’autre est libellé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 vers le serveur d’autorisation, ou :
* 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, par exemple 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 les é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 une assertion client JWT et la signe à l’aide de la clé privée `current`.
9. Auth0 transmet l’assertion client JWT au serveur d’autorisation.
10. Le serveur d’autorisation recherche le client à partir du `client_id` fourni.
11. Le serveur d’autorisation récupère les clés publiques à partir d’Auth0 si un `jwks_uri` a été fourni; sinon, il repère la clé publique enregistrée à l’étape 2.
12. Si le `jwks_uri` a été demandé, Auth0 renvoie les clés publiques au format 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 client par Private Key JWT
Vous pouvez configurer les connexions d’entreprise OIDC et Okta Workforce pour utiliser l’authentification client par Private Key JWT à l’aide de l’Auth0 Dashboard ou de la Management API. Les étapes de chaque méthode sont fournies ci-dessous.
* Les paires de clés de signature privées et publiques sont générées automatiquement par Auth0 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 elle n’est pas précisée.
* Les JWT signés expirent automatiquement après 60 secondes.
#### Auth0 Dashboard
Vous pouvez utiliser le Auth0 Dashboard pour configurer la méthode d’authentification du client Private Key JWT pour les nouvelles connexions OIDC et Okta Workforce ainsi que pour les connexions 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**, indiquez les détails de votre nouvelle connexion, y compris son nom et son URL de découverte.
4. Configurez les champs suivants pour activer Private Key JWT :
* Réglez **Communication Channel** sur **Back Channel**.
* Réglez **Authentication Method** sur **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** sur **Back Channel**.
* Réglez **Authentication Method** sur **Private Key JWT**.
5. Sélectionnez **Save**.
6. Dans la fenêtre contextuelle de confirmation, sélectionnez **Change** pour appliquer vos modifications.
#### Management API
Vous pouvez utiliser la Management API pour configurer Private Key JWT Client Authentication pour les connexions OIDC, qu’elles soient nouvelles ou existantes.
Pour créer une nouvelle connexion OIDC qui utilise Private Key JWT Client Authentication, appelez le point de terminaison [Create a Connection](https://auth0.com/docs/api/management/v2/connections/post-connections) avec les propriétés `connection.options` suivantes définies 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`. La valeur par défaut est `RS256` si elle n’est pas définie. 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. Indique le format de la claim `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 de requête 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 Private Key JWT Client Authentication, appelez le point de terminaison [Update a Connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) avec les propriétés `connection.options` suivantes définies 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`. La valeur par défaut est `RS256` si elle n’est pas définie. 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. Indique le format de la claim `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 de requête 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 Private Key JWT Client Authentication, vous pouvez récupérer ses clés publiques à partir de l’Auth0 Dashboard, de la Management API ou d’un URI JWKS public.
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 à l’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, envoyez une requête au 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 nécessite le scope `read:connections_keys`.
**Exemple de requête 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 les clés publiques pour `private_key_jwt` sous la forme d’un URI JWKS (JSON Web Key Set) public.
Si des clés publiques ont été générées pour une connexion, vous pouvez les récupérer en ajoutant l’URI suivant à la configuration de votre IdP :
```http wrap lines theme={null}
https://{auth0 domain}/oauth/connection/{connection name}/.well-known/jwks.json
```
Les URI JWKS sont pris en compte dans les limites de débit globales. Vous pouvez mettre les clés publiques en cache pour éviter d’atteindre ces limites. Comme bonne pratique, Auth0 recommande un intervalle de cache d’au moins 5 à 10 minutes afin d’éviter d’appeler le point de terminaison URI JWKS à chaque tentative de connexion.
## Rotation des clés de signature
Private Key JWT Client Authentication prend en charge la rotation des clés de signature, ce qui offre une sécurité accrue par rapport au caractère statique et durable des secrets client partagés. La rotation des clés de signature améliore la sécurité en limitant le temps d’exposition de chaque clé, ce qui réduit la fenêtre d’opportunité pour un attaquant de 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 une rotation des clés de signature après 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 de **Okta Workforce**, sélectionnez **Browse**.
3. Choisissez la connexion appropriée, puis accédez à 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, tous les JWT en cours signés avec la clé précédente deviennent immédiatement inactifs et leur vérification auprès de votre IdP peut échouer.
Pour afficher les clés publiques au moyen de la Management API, envoyez une requête au point de terminaison Rotate Connection Signing Keys en utilisant l’ID de votre connexion.
L’utilisation de ce point de terminaison exige à la fois les scopes `create:connections_keys` et `update:connections_keys`.
```js lines theme={null}
POST /v2/connections/{id}/keys/rotate
```
Après la rotation, tous les JWT en cours signés avec la clé précédente deviennent immédiatement inactifs et leur vérification auprès de votre IdP peut échouer.
Dans votre connexion OIDC ou Okta Workforce, vos clés de signature se voient attribuer l’un des statuts suivants :
* **Current** : la clé de signature actuellement utilisée pour l’application.
* **Next** : la prochaine clé de signature à utiliser pour l’application une fois la clé actuelle révoquée.
* **Previous** : une clé de signature expirée ou autrement révoquée qui n’est plus utilisée.
Lorsque Private Key JWT Client Authentication est activé 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 retirée de l’utilisation 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 le statut `previous`.
3. La clé `next` devient la clé active et se voit attribuer le statut `current`. Dorénavant, les client assertion JWT 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 d’une rotation. La nouvelle clé de signature a le statut `next`.
## En savoir plus
* [Associer votre application Auth0 à la connexion Okta Workforce Enterprise](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta)
* [Se connecter à un fournisseur d'identité OpenID Connect](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/oidc)