> ## 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.
> Énumère les bonnes pratiques à suivre lors de l’utilisation de jetons dans l’authentification et l’autorisation.
# Bonnes pratiques relatives aux jetons
Voici quelques points de base à garder à l’esprit lorsque vous utilisez des jetons :
* **Gardez-la secrète. Gardez-la en sécurité** : La clé de signature doit être traitée comme toute autre information d’authentification et n’être divulguée qu’aux services qui en ont besoin.
* **N’ajoutez pas de données sensibles au payload** : Les jetons sont signés pour éviter toute manipulation et peuvent être décodés facilement. Ajoutez le minimum de claims au payload pour optimiser les performances et la sécurité.
* **Donnez une date d’expiration aux jetons** : Techniquement, une fois qu’un jeton est signé, il reste valide indéfiniment, à moins que la clé de signature ne soit modifiée ou qu’une date d’expiration ne soit explicitement définie. Cela peut poser problème; prévoyez donc une stratégie pour faire expirer et/ou révoquer les jetons.
* **Privilégiez HTTPS** : N’envoyez pas de jetons sur des connexions non HTTPS, car ces requêtes peuvent être interceptées et les jetons compromis.
* **Tenez compte de tous vos cas d’utilisation en matière d’autorisation** : Il peut être nécessaire d’ajouter un système secondaire de vérification des jetons afin de s’assurer qu’ils ont été générés par votre serveur et de répondre à vos exigences.
* **Stockez et réutilisez :** Réduisez les allers-retours inutiles qui augmentent la surface d’attaque de votre application, et optimisez les limites de jetons de votre plan (le cas échéant) en stockant les jetons d’accès obtenus auprès du serveur d’autorisation. Au lieu de demander un nouveau jeton, utilisez le jeton stocké pour les requêtes futures jusqu’à son expiration. La façon de stocker les jetons dépend des caractéristiques de votre application : les solutions courantes comprennent les bases de données (pour les applications qui doivent effectuer des appels d’API même en l’absence de session) et les sessions HTTP (pour les applications dont la fenêtre d’activité se limite à une session interactive). Pour un exemple de stockage côté serveur et de réutilisation des jetons, consultez [Stockage des jetons](/docs/fr-ca/secure/security-guidance/data-security/token-storage).
## Jetons vs. cookies
En général, les applications monopages (comme React, Vue et AngularJS + Node), les applications mobiles natives (comme iOS et Android) et les API Web (écrites en Node, Ruby, ASP.NET ou un mélange de ces technologies) profitent le plus de l’authentification basée sur les jetons. Les applications web traditionnelles côté serveur ont, pour leur part, traditionnellement utilisé une authentification basée sur les cookies.
L’authentification basée sur les jetons est mise en œuvre en générant un jeton lorsque l’utilisateur s’authentifie, puis en plaçant ce jeton dans l’en-tête `Authorization` de chaque requête subséquente vers votre API. Idéalement, ce jeton devrait être conforme à une norme, comme JSON Web Tokens, puisque vous trouverez des bibliothèques sur la plupart des plateformes et que vous ne voudrez pas implémenter votre propre cryptographie.
Avec les deux approches, vous pouvez obtenir la même quantité d’information sur l’utilisateur. Cela est contrôlé par le paramètre `scope` envoyé dans la requête de connexion (soit en utilisant Lock, notre bibliothèque JavaScript, soit au moyen d’un simple lien). Le `scope` est un paramètre de la méthode `.signin({scope: 'openid name email'})` qui finit par faire partie de la chaîne de requête dans la requête de connexion.
Par défaut, nous utilisons `scope=openid` dans l’authentification basée sur les jetons pour éviter d’avoir un jeton trop volumineux. Vous pouvez contrôler tous les claims standard de OpenID Connect (OIDC) que vous souhaitez obtenir dans le jeton en les ajoutant comme valeurs de scope. Par exemple, `scope=openid name email family_name address phone_number`. Pour en savoir plus, consultez [Standard Claims on openid.net](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims).
Vous pouvez combiner l’authentification basée sur les jetons avec l’authentification basée sur les cookies. Gardez à l’esprit que les cookies fonctionneront très bien si l’application web et l’API sont servies à partir du même domaine; vous n’aurez donc peut-être pas besoin d’une authentification basée sur les jetons. Si c’est nécessaire, nous retournons aussi un JWT dans le flux d’application web. Chacun de nos SDKs le fait différemment. Si vous voulez faire des requêtes à vos API à partir de JavaScript (au lieu d’utiliser le cookie existant), vous devez alors définir les jetons d’accès à l’aide de Web Workers ou de fermetures JavaScript pour gérer la transmission et le stockage des jetons. Pour en savoir plus, consultez la section Browser in-memory scenarios de notre page [Stockage des jetons](/docs/fr-ca/secure/security-guidance/data-security/token-storage).
## Utilisation des jetons d’actualisation
Vous ne pouvez obtenir un jeton d’actualisation que si vous implémentez les flows suivants :
* [Flux du code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow)
* [Flux du code d’autorisation avec clé de preuve pour l’échange de code (PKCE)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce)
* [Flux du mot de passe du propriétaire de la ressource](/docs/fr-ca/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
* [Flux d’autorisation de l’appareil](/docs/fr-ca/get-started/authentication-and-authorization-flow/device-authorization-flow)
Si vous limitez l’accès hors ligne à votre API, au moyen de la mesure de protection configurée à l’aide du commutateur **Allow Offline Access** dans [Auth0 Dashboard > Applications > APIs > Settings](https://manage.auth0.com/#/apis), Auth0 ne renverra pas de jeton d’actualisation pour l’API (même si vous incluez la portée `offline_access` dans votre requête).
Rules s’exécute lors de l’échange du jeton d’actualisation. Pour exécuter une logique particulière, vous pouvez consulter la propriété `context.protocol` dans votre rule. Si la valeur est `oauth2-refresh-token`, cela signifie que la rule s’exécute pendant l’échange.
Lorsque vous tentez d’obtenir un jeton d’actualisation, le paramètre audience n’est pas disponible dans le context object de Rules. Si vous recevez une erreur lorsque vous tentez d’ajouter le paramètre audience, vérifiez qu’il n’est pas défini dans le jeton.
Si vous essayez d’effectuer une redirection avec `context.redirect`, l’authentication flow renverra une erreur.
Si vous avez ajouté des custom claims à vos jetons au moyen d’une rule, les custom claims apparaîtront dans les nouveaux jetons émis lors de l’utilisation d’un jeton d’actualisation tant que votre rule est en place. Bien que les nouveaux jetons n’héritent pas automatiquement des custom claims, Rules s’exécute pendant le flow du jeton d’actualisation, donc le même code sera exécuté. Cela vous permet d’ajouter ou de modifier des custom claims dans les jetons nouvellement émis sans obliger les applications déjà autorisées à obtenir un nouveau jeton d’actualisation.
### Limites des jetons d’actualisation
Auth0 limite à 200 le nombre de jetons d’actualisation actifs par utilisateur et par application. Cette limite s’applique uniquement aux jetons actifs. Si la limite est atteinte et qu’un nouveau jeton d’actualisation est créé, le système révoque et supprime le jeton le plus ancien pour cet utilisateur et cette application. Les jetons révoqués et expirés ne sont pas pris en compte dans cette limite.
#### Tests automatisés
Les jetons d’actualisation s’accumulent à cause des tests automatisés et sont généralement utilisés pendant toute la durée du test. Pour éviter d’accumuler des jetons et de vous heurter aux limites des jetons d’actualisation, vous pouvez utiliser la Management API d’Auth0 pour supprimer les jetons d’actualisation inutiles.
1. [Créer un utilisateur](https://auth0.com/docs/api/management/v2#!/Users/post_users) avec la Management API. Vous utiliserez cet utilisateur pour les tests.
2. La réponse renvoie un `user_id` que vous devez enregistrer pendant les tests pour l’utiliser plus tard.
3. Une fois les tests terminés, [supprimez l’utilisateur](https://auth0.com/docs/api/management/v2#!/Users/delete_users_by_id) au moyen de la Management API. Lorsque l’utilisateur de test est supprimé, les artefacts associés le sont aussi, y compris les jetons d’actualisation.
Pour ce cas d’utilisation, nous ne recommandons pas d’utiliser un ID utilisateur statique. Nous vous déconseillons de conserver les utilisateurs et les artefacts de test, ou de nettoyer les jetons d’actualisation à l’aide des points de terminaison des informations d’identification de l’appareil, car vous pourriez atteindre les limites de débit de la Management API. Pour en savoir plus, consultez [Limites de débit des points de terminaison de la Management API.](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/management-api-endpoint-rate-limits)
Si vous souhaitez conserver l’utilisateur de test pour des tests ultérieurs :
1. Répertoriez les jetons d’actualisation de l’utilisateur à l’aide du [point de terminaison des informations d’identification de l’appareil de la Management API](https://auth0.com/docs/api/management/v2#!/Device_Credentials/get_device_credentials). Le point de terminaison renverra un maximum de 1000 jetons, sans ordre particulier, peu importe le nombre de jetons accumulés ou l’utilisation de la pagination.
2. Supprimez ces informations d’identification [à l’aide de la méthode DELETE](https://auth0.com/docs/api/management/v2#!/Device_Credentials/delete_device_credentials_by_id).
3. Si l’utilisateur a plus de 1k jetons, répétez l’opération de listing et de suppression jusqu’à ce qu’il ne reste plus de jetons pour cet utilisateur.
#### Configurer l’expiration des jetons d’actualisation
Lorsque les utilisateurs se connectent à votre application avec Auth0 et que `offline_access` est demandé dans la demande d’autorisation, un nouveau jeton d’actualisation leur est émis. Si les utilisateurs se déconnectent puis se reconnectent avec le même appareil, un nouveau jeton d’actualisation est émis. Selon la façon dont votre application stocke et utilise les jetons d’actualisation, l’ancien jeton d’actualisation de la première connexion pourrait devenir obsolète, et votre application utilisera très probablement les nouveaux jetons d’actualisation si les deux tokens sont émis avec la même audience. Pour en savoir plus, consultez [Stockage des jetons](/docs/fr-ca/secure/security-guidance/data-security/token-storage).
Pour éviter l’accumulation de jetons d’actualisation obsolètes, même si la limite de refresh tokens supprime d’abord le token le plus ancien, nous vous recommandons de configurer l’expiration des jetons d’actualisation. Les jetons d’actualisation avec rotation et sans rotation (ou réutilisables) peuvent tous être configurés pour expirer selon une expiration après inactivité ou une expiration absolue. Ces deux types d’expiration aident à supprimer les tokens qui ne sont pas activement utilisés et à éviter l’accumulation de tokens pour l’utilisateur. Pour en savoir plus, consultez [Configurer l’expiration des refresh tokens](/docs/fr-ca/secure/tokens/refresh-tokens/configure-refresh-token-expiration).
## Validation des JWT
Nous vous recommandons fortement d’utiliser un middleware ou l’une des bibliothèques open source tierces existantes pour analyser et valider les JWT. Sur [JWT.io](https://jwt.io/#libraries-io), vous trouverez des bibliothèques pour diverses plateformes et divers langages, comme .NET, Python, Java, Ruby, Objective-C, Swift et PHP.
## Algorithmes de signature
L'algorithme utilisé pour signer les jetons émis pour votre application ou votre API. Une signature fait partie d'un JWT et sert à vérifier que l'émetteur du jeton est bien celui qu'il prétend être, et à s'assurer que le message n'a pas été modifié en cours de route. Pour en savoir plus sur les JWT, consultez [JSON Web Tokens](/docs/fr-ca/secure/tokens/json-web-tokens). Pour en savoir plus sur les signatures, consultez [JSON Web Token Structure](/docs/fr-ca/secure/tokens/json-web-tokens/json-web-token-structure).
Vous pouvez choisir parmi les algorithmes de signature suivants :
* **RS256** (signature RSA avec SHA-256) : un algorithme asymétrique, ce qui signifie qu'il y a deux clés : une clé publique et une clé privée qui doit rester secrète. Auth0 détient la clé privée utilisée pour générer la signature, et le consommateur du JWT récupère une clé publique à partir des endpoints de métadonnées fournis par Auth0 et l'utilise pour [valider la signature du JWT](/docs/fr-ca/secure/tokens/json-web-tokens/validate-json-web-tokens).
* **HS256** (HMAC avec SHA-256) : un algorithme symétrique, ce qui signifie qu'il n'y a qu'une seule clé privée qui doit rester secrète, et qu'elle est partagée entre les deux parties. Puisque la même clé sert à la fois à générer la signature et à la valider, il faut veiller à ce qu'elle ne soit pas compromise. Cette clé privée (ou ce secret) est créée lorsque vous enregistrez votre Application (**Client Secret**) ou votre API (**Signing Secret**) et que vous choisissez l'algorithme de signature HS256.
La pratique la plus sécuritaire, et celle que nous recommandons, est d'utiliser **RS256** parce que :
* Avec RS256, vous avez l'assurance que seul le détenteur de la clé privée (Auth0) peut signer des jetons, tandis que n'importe qui peut vérifier si le jeton est valide à l'aide de la clé publique.
* Avec RS256, vous pouvez demander un jeton valide pour plusieurs audiences.
* Avec RS256, si la clé privée est compromise, vous pouvez effectuer une rotation des clés sans avoir à redéployer votre application ou votre API avec le nouveau secret (ce que vous devriez faire si vous utilisiez HS256).
* Avec HS256, si la clé secrète est compromise, vous devriez redéployer l'API avec le nouveau secret.
## Clés de signature
Il est recommandé de partir du principe que plusieurs clés de signature peuvent être présentes dans votre JWKS. Cela peut sembler inutile, puisque le point de terminaison JWKS d’Auth0 contient généralement une seule clé de signature; toutefois, plusieurs clés peuvent s’y trouver lors de la rotation des certificats de signature.
Nous vous recommandons de mettre en cache vos clés de signature afin d’améliorer les performances de l’application et d’éviter de dépasser les limites de débit. Pour savoir comment effectuer la mise en cache de façon sécuritaire tout en récupérant les clés ayant fait l’objet d’une rotation, consultez [Mettre en cache le JSON Web Key Set](/docs/fr-ca/secure/tokens/json-web-tokens/json-web-key-sets#cache-the-json-web-key-set).
## En savoir plus
* [Jetons](/docs/fr-ca/secure/tokens)
* [Stockage des jetons](/docs/fr-ca/secure/security-guidance/data-security/token-storage)