> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-actions-triggers-prototype.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Apprenez comment mettre en œuvre l’authentification client JWT avec clé privée pour les connexions de votre entreprise.
# Authentification du client JWT avec clé privée pour les connexions Okta et OIDC
Clé privée JWT L’authentification du client est une méthode de remplacement de l’authentification du client pour le OpenID Connect (OIDC) et les connexions d’entreprise Okta Workforce. L’authentification client s’effectue généralement en transmettant un secret clientsecret client. L’authentification client JWT avec clé privée transmet quant à elle un JWT signé afin de renforcer la sécurité de l’application.
En utilisant cette fonctionnalité, vous pouvez éviter certaines failles de sécurité courantes souvent associées à l’authentification standard par clé secrète, telles que :
* Un risque accru d’interception et de réutilisation, car les informations confidentielles du client doivent être transmises entre les parties à chaque requête.
* Les mécanismes permettant d’imposer l’expiration et d’empêcher la réutilisation par des acteurs malveillants sont limités.
* Un risque accru de fuites ou de divulgation, les deux parties conservant le secret client.
Vous pouvez configurer l’authentification client JWT avec clé privée pour vos connexions OIDC et Okta Workforce Entreprise via Auth0 Dashboard ou Management API.
## Le fonctionnement
Le flux de connexion OIDC utilise des points de terminaison authentifiés, tels que `/oauth/token` ou `/oauth/par`, pour vérifier l’identité d’un client auprès du serveur d’autorisation ou fournisseur OpenID. Avec l’authentification client JWT avec clé privée, un JWT d’assertion client signé est transmis au fournisseur OpenID à la place d’un secret client.
Le JWT d’assertion client contient les demandes suivantes :
* Un `aud` (public) déterminer le public point de terminaison du jeton.
* Un `jti` (JWT d’ID) permettant une utilisation unique ou une protection contre la relecture.
* Une valeur `exp` (durée d’expiration) qui limite la période de validité du jeton.
* Une `sub` et `iss` déterminant l’identifiant client.
L’authentification JWT avec clé privée offre une méthode d’authentification plus sécurisée en supprimant l’utilisation de secrets client partagés. À la place, le JWT est 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 JWT avec clé privée
Une fois qu’un utilisateur s’est authentifié auprès d’un fournisseur d’identité (IdP), l’utilisateur est redirigé vers Auth0 avec un code d’autorisation qui est échangé contre des jetons au niveau du point de terminaison de jetons du fournisseur OpenID. Lorsque l’option « JWT avec clé privée » est activée pour une connexion, l’appel vers le point de terminaison de jetons du fournisseur OpenID utilise une assertion client plutôt qu’un secret client, afin de garantir une sécurité accrue lors de l’authentification.
Les étapes suivantes illustrent un processus type d’authentification client JWT avec clé privée.
Pour terminer ce flux, vous devez d’abord configurer une connexion OIDC ou Okta Workforce (nouvelle ou existante) avec `token_endpoint_auth_method=private_key_jwt` via Auth0 Dashboard ou Management API. Pour en savoir plus, consulter la section [Configurer l’authentification client JWT avec clé privée](#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, une publique et une privée.
* Une paire de clés correspond à l’ensemble `current` actif, tandis que l’autre ensemble est désigné par `next` afin de permettre 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 :
* Copiez-collez le [`jwks_uri`](#retrieve-signing-keys) sur le serveur d’autorisation.
3. Un utilisateur effectue une action qui nécessite une authentification, comme la connexion à votre application.
4. Auth0 envoie une requête au serveur d’autorisation pour lancer l’authentification.
5. Le serveur d’autorisation affiche les écrans d’authentification et de consentement à l’utilisateur.
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 client et le signe à l’aide de la clé privée `current`.
9. Auth0 transmet le JWT d’assertion client au serveur d’autorisation.
10. Le serveur d’autorisation recherche le client à partir de l’`client_id` fourni.
11. Le serveur d’autorisation récupère les clés publiques auprès d’Auth0 si un `jwks_uri` a été fourni; dans le cas contraire, le serveur détermine la clé publique enregistrée à la deuxième étape.
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 nécessaire à l’exécution du flux.
## Configurer l’authentification client JWT avec clé privée
Vous pouvez configurer les connexions OIDC et Okta Workforce Entreprise pour utiliser l’authentification client JWT avec clé privée via Auth0 Dashboard ou Management API. Vous trouverez ci-dessous les étapes à suivre pour chaque méthode.
\*Les paires de clés de connexion 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 Okta et OIDC Entreprise. Si aucun algorithme n’est défini, `RS256` est utilisé.
\*Les JWT signés expirent automatiquement au bout de 60 secondes.
#### Auth0 Dashboard
Vous pouvez utiliser Auth0 Dashboard pour configurer l’authentification client JWT par clé privée pour les connexions OIDC et Okta Workforce, que ce soit pour les nouvelles connexions ou celles existantes.
1. Dans Auth0 Dashboard, accédez à [Authentification > Entreprise](https://manage.auth0.com/#/connections/enterprise).
2. En regard de **OpenID Connect** ou **Okta Workforce**, sélectionnez **Créer**.
3. Dans la section **Général**, indiquez les détails de votre nouvelle connexion, notamment son nom et son URL de découverte.
4. Configurez les champs suivants pour activer le JWT avec clé privée :
\*Réglez le **canal de communication** sur **canal d’appui**.
\*Définissez la **méthode d’authentification** sur **JWT avec clé privée**.
5. Sélectionnez **Créer** pour enregistrer votre nouvelle connexion.
6. Sur la fenêtre de confirmation, sélectionnez **Modifier** pour appliquer vos modifications.
1. Dans Auth0 Dashboard, accédez à [Authentification > Entreprise](https://manage.auth0.com/#/connections/enterprise).
2. En regard de **OpenID Connect** ou **Okta Workforce**, sélectionnez **Parcourir**.
3. Choisissez la connexion souhaitée. Accédez ensuite à son onglet **Identifiants**.
4. Dans la section **Paramètres d’authentification**, configurez les éléments suivants :
\*Réglez le **canal de communication** sur **canal d’appui**.
\*Définissez la **méthode d’authentification** sur **JWT avec clé privée**.
5. Sélectionnez **Enregistrer**.
6. Dans la fenêtre de confirmation, sélectionnez **Modifier** pour appliquer vos modifications.
#### Management API
Vous pouvez utiliser Management API pour configurer l’authentification client JWT par clé privée pour les connexions OIDC, que ce soit pour les nouvelles connexions ou celles existantes.
Pour créer une nouvelle connexion OIDC utilisant l’authentification client 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 configurant correctement les propriétés `connection.options` suivantes :
| Propriété | Description |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type` | Définir cette propriété sur `back_channel`. |
| `token_endpoint_auth_method` | Méthode d’authentification utilisée au point de terminaison du jeton du fournisseur d’identité. Définissez la valeur 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 identifiants dans le corps de la requête. Par défaut, `token-endpoint`. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `token_endpoint_auth_signing_alg` | Facultatif. Algorithme utilisé pour signer les assertions client. Valeurs acceptées : `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `ES256`, `ES384`. Si aucun algorithme n’est défini, `RS256` est utilisé. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `id_token_signed_response_algs` | Facultatif. Liste des algorithmes autorisés pour la vérification des jetons d’ID émis par le fournisseur d’identité. Une fois cette option activée, Auth0 rejette les jetons d’ID signés à l’aide d’un algorithme ne figurant pas dans cette liste. Valeurs acceptées : `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `ES256`, `ES384`. Si cette valeur n’est pas définie, Auth0 accepte les jetons d’ID signés à l’aide de 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 l’attribut `aud` (public) dans le JWT utilisé pour l’authentification client au niveau du point de terminaison du jeton. Définissez la valeur sur `issuer` pour utiliser l’URL de l’émetteur OIDC, ou sur `token_endpoint` pour utiliser l’URL du point de terminaison du jeton. |
**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 pour utiliser l’authentification client 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 configurant correctement les propriétés `connection.options` suivantes :
| Propriété | Description |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type` | Définir cette propriété sur `back_channel`. |
| `token_endpoint_auth_method` | Méthode d’authentification utilisée au point de terminaison du jeton du fournisseur d’identité. Définissez la valeur 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 identifiants dans le corps de la requête. Par défaut, `token_endpoint`. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `token_endpoint_auth_signing_alg` | Facultatif. Algorithme utilisé pour signer les assertions client. Valeurs acceptées : `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `ES256`, `ES384`. Si aucun algorithme n’est défini, `RS256` est utilisé. S’applique uniquement aux stratégies `oidc` et `okta`. |
| `id_token_signed_response_algs` | Facultatif. Liste des algorithmes autorisés pour la vérification des jetons d’ID émis par le fournisseur d’identité. Une fois cette option activée, Auth0 rejette les jetons d’ID signés à l’aide d’un algorithme ne figurant pas dans cette liste. Valeurs acceptées : `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `ES256`, `ES384`. Si cette valeur n’est pas définie, Auth0 accepte les jetons d’ID signés à l’aide de 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 l’attribut `aud` (public) dans le JWT utilisé pour l’authentification client au niveau du point de terminaison du jeton. Définissez la valeur sur `issuer` pour utiliser l’URL de l’émetteur OIDC, ou sur `token_endpoint` pour utiliser l’URL du point de terminaison du jeton. |
**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ération des clés de connexion
Une fois que votre connexion a été configurée pour utiliser l’authentification client JWT avec clé privée, vous pouvez récupérer ses clés publiques via Auth0 Dashboard, Management API ou un URI JWKS public.
Pour récupérer les clés de connexion via Auth0 Dashboard :
1. Rendez-vous à [Authentification > Entreprise](https://manage.auth0.com/#/connections/enterprise).
2. En regard de **OpenID Connect** ou **Okta Workforce**, sélectionnez **Parcourir**.
3. Choisissez la connexion souhaitée. Accédez ensuite à son onglet **Identifiants**.
4. Recherchez la section **Identifiants** et cliquez sur l’icône **Télécharger** située à côté de la clé de connexion correspondante.
Pour consulter les clés publiques via Management API, appelez le point de terminaison [Obtenir les clés de connexion](https://auth0.com/docs/api/management/v2/connections/get-keys) en utilisant l’identifiant de votre connexion.
L’utilisation de ce point de terminaison nécessite la permission `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é autorisent la fourniture des 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 fournisseur d’identité (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 anti-attaques. Vous pouvez utiliser la mise en cache des clés publiques pour éviter d’atteindre ces limites. Autho0 recommande, à titre de pratique exemplaire, un intervalle de mise en cache d’au moins cinq à dix minutes afin d’éviter d’appeler le point de terminaison URI JWKS à chaque tentative de connexion.
## Rotation des clés d’authentification
L’authentification client JWT avec clé privée prend en charge la rotation des clés de connexion, ce qui renforce la sécurité par rapport à la nature statique et durable des secrets clients partagés. La rotation des clés de connexion renforce la sécurité en limitant la durée d’exposition de chaque clé, réduisant ainsi les possibilités qu’un pirate informatique parvienne à les compromettre. Cela permet également d’intervenir rapidement en cas d’incident de sécurité.
Pour éviter toute interruption, Auth0 recommande de renouveler les clés de connexion tous les ans Vous pouvez utiliser Auth0 Dashboard ou Management API pour renouveler les clés de connexion :
Pour effectuer une rotation de vos clés de connexion via Auth0 Dashboard :
1. Rendez-vous à [Authentification > Entreprise](https://manage.auth0.com/#/connections/enterprise).
2. En regard de **OpenID Connect** ou **Okta Workforce**, sélectionnez **Parcourir**.
3. Choisissez la connexion souhaitée. Accédez ensuite à son onglet **Identifiants**.
4. Dans la section **Identifiants**, sélectionnez **Rotation des clés**.
5. Dans la fenêtre contextuelle, sélectionnez **Enregistrer** pour confirmer la rotation.
Une fois la rotation effectuée, tous les JWT en cours de validité signés avec la clé précédente deviennent immédiatement inactifs et risquent de ne pas passer la vérification auprès de votre fournisseur d’identité (IdP).
Pour consulter les clés publiques via Management API, appelez le point de terminaison Rotation des clés de connexion en utilisant l’identifiant de votre connexion.
L’utilisation de ce point de terminaison nécessite les permissions `create:connections_keys` et `update:connections_keys`.
```js lines theme={null}
POST /v2/connections/{id}/keys/rotate
```
Une fois la rotation effectuée, tous les JWT en cours de validité signés avec la clé précédente deviennent immédiatement inactifs et risquent de ne pas passer la vérification auprès de votre fournisseur d’identité (IdP).
Dans votre connexion OIDC ou Okta Workforce, vos clés de connexion se voient attribuer l’un des états suivants :
* **Clé actuelle**: La clé de connexion actuellement utilisée pour l’application.
* **Clé suivante** : La clé de connexion suivante à utiliser pour l’application une fois que la clé actuelle aura été révoquée.
* **Clé précédente** : Une clé de connexion expirée ou autrement révoquée qui n’est plus utilisée.
Lorsque l’authentification client 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 `previous` qu’après la rotation.
Lors de la rotation des clés de connexion, les changements suivants se produisent :
1. La clé `current` est supprimée et révoquée ; tout JWT signé avec cette clé échouera à la vérification auprès du fournisseur d’identité (IdP) si celui-ci a été configuré avec la clé `jwks_uri`.
2. La clé `current` se voit attribuer l’état `previous`.
3. La clé `next` devient la touche active et se voit attribuer l’état `current`. Dorénavant, les JWT d’authentification client seront signés à l’aide de cette clé.
4. Une nouvelle clé de connexion est générée automatiquement pour remplacer la clé qui a fait l’objet d’une rotation. La nouvelle clé de connexion a l’état `next`.
## En apprendre plus
* [Connectez votre application Auth0 à votre connexion Okta Workforce Entreprise](/docs/authenticate/identity-providers/enterprise-identity-providers/okta)
* [Se connecter au Fournisseur d’identité OpenID Connect](/docs/authenticate/identity-providers/enterprise-identity-providers/oidc)