> ## 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.
> Répertorie les bonnes pratiques à suivre lors de l’utilisation de jetons pour 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 ne doit être communiquée qu’aux services qui en ont besoin.
* **N’ajoutez pas de données sensibles au payload** : Les jetons sont signés pour prévenir toute altération et peuvent être décodés facilement. Ajoutez le moins de claims possible au payload afin d’optimiser les performances et la sécurité.
* **Définissez une date d’expiration pour les 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 soit explicitement définie. Cela peut entraîner des problèmes; prévoyez donc une stratégie pour faire expirer ou révoquer les jetons.
* **Privilégiez HTTPS** : N’envoyez pas de jetons sur des connexions autres que 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 mécanisme secondaire de vérification des jetons pour garantir qu’ils ont bien été générés par votre serveur et ainsi 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 forfait (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, réutilisez le jeton stocké lors des appels ultérieurs 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é est limitée à une session interactive). Pour voir un exemple de stockage côté serveur et de réutilisation de jeton, consultez [Stockage des jetons](/fr-CA/docs/secure/security-guidance/data-security/token-storage).
## Jetons vs. témoins
En règle générale, les applications monopage (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 à l’aide d’une combinaison de ces technologies) se prêtent mieux à l’authentification basée sur les jetons. Les applications Web traditionnelles côté serveur ont, quant à elles, traditionnellement utilisé l’authentification basée sur les témoins.
L’authentification basée sur les jetons consiste à générer un jeton lorsque l’utilisateur s’authentifie, puis à envoyer ce jeton dans l’en-tête `Authorization` de chaque requête subséquente à votre API. Ce jeton devrait être dans un format standard, comme les JSON Web Tokens, puisque vous trouverez des bibliothèques pour la plupart des plateformes et que vous ne voudrez pas implémenter votre propre cryptographie.
Avec les deux approches, vous pouvez obtenir les mêmes informations de l’utilisateur. Cela est contrôlé par le paramètre `scope` envoyé dans la requête de connexion (soit avec Lock, notre bibliothèque JavaScript, soit avec 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 afin d’éviter d’avoir un jeton trop volumineux. Vous pouvez contrôler toute claim 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 témoins. Gardez à l’esprit que les témoins fonctionnent très bien si l’application Web et l’API sont hébergées sous le même domaine; vous n’aurez donc peut-être pas besoin d’une authentification basée sur les jetons. Au besoin, nous renvoyons aussi un JWT dans le flux de l’application Web. Chacun de nos SDK gère cela différemment. Si vous voulez appeler vos API à partir de JavaScript (au lieu d’utiliser le témoin existant), vous devez alors gérer les jetons d’accès à l’aide de Web Workers ou de closures JavaScript pour assurer la transmission et le stockage des jetons. Pour en savoir plus, consultez la section Browser in-memory scenarios de notre page [Token Storage](/fr-CA/docs/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 flux suivants :
* [Flux de code d’autorisation](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow)
* [Flux de code d’autorisation avec clé de preuve pour l’échange de code (PKCE)](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce)
* [Flux de mot de passe du propriétaire de la ressource](/fr-CA/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
* [Flux d’autorisation de l’appareil](/fr-CA/docs/get-started/authentication-and-authorization-flow/device-authorization-flow)
Si vous limitez l’accès hors ligne à votre API, une mesure de protection configurée au moyen 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 le scope `offline_access` dans votre requête).
Les Rules s’exécutent lors de l’échange du jeton d’actualisation. Pour exécuter une logique particulière, vous pouvez vérifier 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 l’objet de contexte des 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`, le flux d’authentification renverra une erreur.
Si vous avez ajouté des claims personnalisées à vos jetons à l’aide d’une Rule, elles apparaîtront dans les nouveaux jetons émis lors de l’utilisation d’un jeton d’actualisation tant que votre Rule restera en place. Bien que les nouveaux jetons n’héritent pas automatiquement des claims personnalisées, les Rules s’exécutent pendant le flux du jeton d’actualisation, donc le même code sera exécuté. Cela vous permet d’ajouter ou de modifier des claims personnalisées 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 cette 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 comptabilisés dans cette limite.
#### Tests automatisés
Les jetons d’actualisation s’accumulent en raison des tests automatisés et sont généralement utilisés pendant toute la durée des tests. Pour éviter une accumulation de jetons soumise aux limites des jetons d’actualisation, vous pouvez utiliser la Management API d’Auth0 pour supprimer les jetons d’actualisation inutiles.
1. [Créez 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 conserver pendant les tests pour pouvoir 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 ne recommandons pas non plus de conserver les utilisateurs et les artefacts de test, ni de supprimer les jetons d’actualisation à l’aide des points de terminaison des identifiants d’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.](/fr-CA/docs/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 identifiants d’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 identifiants [à 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 listage et de suppression jusqu’à ce qu’il n’en reste plus pour cet utilisateur.
#### Configurer des jetons d’actualisation expirables
Lorsque des utilisateurs ouvrent une session dans votre application avec Auth0 et que `offline_access` est demandé dans la demande d’autorisation, un nouveau jeton d’actualisation leur est émis. S’ils ferment ensuite leur session puis en ouvrent une nouvelle sur 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 peut devenir obsolète, et votre application utilisera très probablement les nouveaux jetons d’actualisation si les deux jetons sont émis avec la même audience. Pour en savoir plus, consultez [Stockage des jetons](/fr-CA/docs/secure/security-guidance/data-security/token-storage).
Pour éviter l’accumulation de jetons d’actualisation obsolètes, même si la limite de jetons d’actualisation supprime d’abord le jeton le plus ancien, nous vous recommandons de configurer l’expiration des jetons d’actualisation. Les jetons d’actualisation avec rotation comme ceux sans rotation (ou réutilisables) peuvent être configurés pour expirer après une période d’inactivité ou après une durée absolue. Ces deux valeurs d’expiration aident à supprimer les jetons qui ne sont plus activement utilisés et à éviter leur accumulation pour l’utilisateur. Pour en savoir plus, consultez [Configurer l’expiration des jetons d’actualisation](/fr-CA/docs/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 tierces open source 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’expéditeur du jeton est bien celui qu’il prétend être et à s’assurer que le message n’a pas été modifié au passage. Pour en savoir plus sur les JWT, consultez [JSON Web Tokens](/fr-CA/docs/secure/tokens/json-web-tokens). Pour en savoir plus sur les signatures, consultez [JSON Web Token Structure](/fr-CA/docs/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 destinataire du JWT récupère une clé publique à partir des points de terminaison de métadonnées fournis par Auth0 et l’utilise pour [valider la signature du JWT](/fr-CA/docs/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. Comme la même clé est utilisée à la fois pour générer la signature et pour 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 (**Secret client**) ou votre API (**secret de signature**) et choisissez l’algorithme de signature HS256.
La méthode la plus sûre, 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 mettre en place 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 devrez redéployer l’API avec le nouveau secret.
## Clés de signature
Il est recommandé de supposer 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 pour améliorer les performances de l’application et éviter d’atteindre les limites de débit, mais assurez-vous que, si le décodage d’un jeton échoue, vous invalidez le cache et récupérez de nouvelles clés de signature avant de réessayer **une seule** autre fois.
## En savoir plus
* [Jetons](/fr-CA/docs/secure/tokens)
* [Stockage des jetons](/fr-CA/docs/secure/security-guidance/data-security/token-storage)