Fonctionnement des jetons d'actualisation

Les applications modernes sécurisées utilisent souvent des jetons d'accès pour garantir qu'un utilisateur puisse accéder aux ressources dont il a besoin. Ces jetons d'accès ont généralement une durée de vie limitée. Cette option est nécessaire pour différents besoins de sécurité. D'une part, les jetons d'accès à durée de vie limitée servent à réduire la période d'utilisation des jetons volés. D'autre part, les informations contenues ou référencées par le jeton d'accès peuvent devenir périmées.

Lorsque les jetons d'accès expirent ou deviennent non valides, mais que l'application a encore besoin d'accéder à une ressource protégée, elle est confrontée au problème d'obtenir un nouveau jeton d'accès sans obliger l'utilisateur à confirmer encore son autorisation. Pour résoudre ce problème, OAuth 2.0 a introduit un artefact appelé jeton d'actualisation. Un jeton d'actualisation permet à l'application d'obtenir un nouveau jeton d'accès sans avertir l'utilisateur.

Un jeton d'actualisation peut être demandé par une application dans le cadre du processus d'obtention d'un jeton d'accès. De nombreux serveurs d'autorisation mettent en œuvre le mécanisme de demande de jeton d'actualisation défini par la spécification OpenID Connect. Dans ce cas, l'application doit inclure l'étendue offline_access à chaque demande de code d'autorisation. Dès que l'utilisateur est authentifié et autorise l'application à accéder à une ressource protégée, l'application reçoit un code d'autorisation qui pourra être échangé sur le point terminal du jeton contre un jeton d'accès et un jeton d'actualisation.

Lorsqu'un nouveau jeton d'accès est nécessaire, l'application peut renvoyer une demande POST au point terminal du jeton en utilisant un type d'autorisation refresh_token (les applications Web doivent inclure uncode secret de client). Pour utiliser un jeton d'actualisation afin d'obtenir un nouveau jeton d'identification, le serveur d'autorisation doit prendre en charge OpenID Connect. En outre, l'étendue de la demande originale doit inclure openid.

Le serveur d'autorisation peut invalider les jetons d'actualisation, même s'ils ont souvent une longue durée de vie. Les jetons d'actualisation peuvent devenir non valides, notamment pour les raisons suivantes :

• le serveur d'autorisation a révoqué le jeton d'actualisation
• l'utilisateur a révoqué son consentement
• le jeton d'actualisation a expiré
• la politique d'authentification de la ressource a changé (par exemple, à l'origine, la ressource n'utilisait que des noms d'utilisateur et des mots de passe, mais elle exige désormais une authentification multiple ou MFA)

Comme les jetons d'actualisation bénéficient d'une durée de vie potentiellement longue, les développeurs doivent s'assurer que des exigences strictes de stockage ont été mises en place pour éviter toute fuite. Par exemple, dans les applications Web, les jetons d'actualisation ne doivent sortir du backend que pour être envoyés au serveur d'autorisation, et le backend doit bénéficier d'une protection appropriée. Le code secret de client doit être protégé de la même manière. Si les applis mobiles ne nécessitent pas de code secret de client, elles doivent néanmoins stocker les jetons d'actualisation sur un site uniquement accessible par l'application client.

Auth0 permet d'obtenir un jeton d'actualisation lorsque vous utilisez le flux de code d'autorisation (pour les applis Web ordinaires ou les applis natives/ mobiles), le flux d'appareil ou l'attribution de mot de passe du propriétaire de ressource. Tous les principaux SDK d'Auth0 prennent en charge l'acquisition, l'utilisation et la révocation des jetons d'actualisation, sans que vous ayez à vous soucier du formatage des messages. Les langages bénéficiant du support SDK incluent Node.js, .NET, PHP et bien d'autres !

Pour en savoir plus sur les jetons d'actualisation Auth0 et leurs méthodes de révocation, consultez la documentation sur les jetons d'actualisation.