Quel est l'intérêt du jeton de rafraîchissement ?

Question

Je dois avouer que j'ai cette question depuis très longtemps et que je n'ai jamais vraiment compris.

Dire qu'un jeton d'authentification est comme une clé pour un coffre-fort ; lorsqu'il expire, il n'est plus utilisable. Maintenant, on nous donne un jeton de rafraîchissement magique, qui peut être utilisé pour obtenir une autre clé utilisable, et une autre… jusqu'à l'expiration du jeton magique. Alors pourquoi ne pas simplement définir l'expiration du jeton d'authentification comme celle du jeton de rafraîchissement? Pourquoi se donner tout ce mal?

Quelle en est la raison? Est-ce une raison historique?

Answer 1

Je lisais un article l'autre jour par Taiseer Joudeh et je le trouve très utile, il a dit :

À mon avis, il y a trois principaux avantages à utiliser des jetons de rafraîchissement qui sont :

1. Mise à jour du contenu du jeton d'accès : comme vous le savez, les jetons d'accès sont des jetons autonomes, ils contiennent toutes les revendications (informations) sur l'utilisateur authentifié une fois qu'ils sont générés. Maintenant, si vous émettez un jeton à durée de vie prolongée (par exemple, 1 mois) pour un utilisateur nommé "Alex" et l'inscrivez dans le rôle "Utilisateurs", alors ces informations sont contenues dans le jeton généré par le serveur d'autorisation. Si vous décidez plus tard (2 jours après qu'il a obtenu le jeton) de l'ajouter au rôle "Admin", il n'y a aucun moyen de mettre à jour ces informations contenues dans le jeton généré, vous devez lui demander de se ré-authentifier afin que le serveur d'autorisation ajoute ces informations à ce nouveau jeton d'accès généré, ce qui n'est pas faisable dans la plupart des cas. Vous pourriez ne pas pouvoir contacter les utilisateurs qui ont obtenu des jetons d'accès à durée de vie prolongée. Afin de surmonter ce problème, nous devons émettre des jetons d'accès à durée de vie courte (par exemple, 30 minutes) et utiliser le jeton de rafraîchissement pour obtenir un nouveau jeton d'accès, une fois que vous obtenez le nouveau jeton d'accès, le serveur d'autorisation pourra ajouter une nouvelle revendication pour l'utilisateur "Alex" qui l'assigne au rôle "Admin" une fois que le nouveau jeton d'accès est généré

2. Révocation de l'accès aux utilisateurs authentifiés : une fois que l'utilisateur obtient un jeton d'accès à durée de vie prolongée, il pourra accéder aux ressources du serveur aussi longtemps que son jeton d'accès n'expire pas. Il n'y a pas de moyen standard de révoquer les jetons d'accès à moins que le serveur d'autorisation n'implémente une logique personnalisée qui vous oblige à stocker les jetons d'accès générés dans la base de données et à effectuer des vérifications de base de données à chaque demande. Mais avec les jetons de rafraîchissement, un administrateur système peut révoquer l'accès en supprimant simplement l'identifiant du jeton de rafraîchissement de la base de données, donc une fois que le système demande un nouveau jeton d'accès en utilisant le jeton de rafraîchissement supprimé, le serveur d'autorisation rejettera cette demande car le jeton de rafraîchissement n'est plus disponible (nous aborderons ce point en détail).

3. Pas besoin de stocker ou de demander un nom d'utilisateur et un mot de passe : l'utilisation des jetons de rafraîchissement vous permet de demander à l'utilisateur son nom d'utilisateur et son mot de passe une seule fois lors de sa première authentification, puis le serveur d'autorisation peut émettre un jeton de rafraîchissement très long (par exemple, 1 an) et l'utilisateur restera connecté pendant toute cette période à moins que l'administrateur système ne tente de révoquer le jeton de rafraîchissement. Vous pouvez voir cela comme une façon de fournir un accès hors ligne aux ressources du serveur, ce qui peut être utile si vous construisez une API qui sera consommée par une application frontale où il n'est pas pratique de demander fréquemment le nom d'utilisateur et le mot de passe.

Answer 2

Je voudrais ajouter une autre perspective à cela.

Authentification sans état sans accéder à la base de données à chaque requête

Supposons que vous souhaitiez créer un mécanisme de sécurité sans état (sans session) qui puisse authentifier des millions d'utilisateurs, sans avoir à faire un appel à la base de données pour l'authentification. Avec tout le trafic que votre application génère, économiser un appel à la base de données à chaque requête vaut beaucoup! Et cela doit être sans état afin de pouvoir facilement être mis en grappe et étendu à des centaines, voire des milliers de serveurs.

Avec les sessions à l'ancienne, l'utilisateur se connecte, à ce moment-là, nous lisons ses informations utilisateur dans la base de données. Pour éviter de devoir le relire encore et encore, nous le stockons dans une session (généralement en mémoire ou dans un cache en grappe). Nous envoyons l'ID de session au client dans un cookie, qui est attaché à toutes les requêtes suivantes. Lors des requêtes suivantes, nous utilisons l'ID de session pour rechercher la session, qui contient à son tour les informations utilisateur.

Placez les informations utilisateur directement dans le jeton d'accès

Mais nous ne voulons pas de sessions. Donc, au lieu de stocker les informations utilisateur dans la session, mettons-les simplement dans un jeton d'accès. Nous signons le jeton pour que personne ne puisse le falsifier et voilà. Nous pouvons authentifier les requêtes sans session et sans avoir à rechercher les informations utilisateur dans la base de données pour chaque requête.

Pas de session ... pas moyen de bannir des utilisateurs?

Mais ne pas avoir de session a un gros inconvénient. Que se passerait-il si cet utilisateur est banni par exemple? Dans l'ancien scénario, nous supprimons simplement sa session. Il devra alors se reconnecter, ce qu'il ne pourra pas faire. Ban terminé. Mais dans le nouveau scénario, il n'y a pas de session. Comment pouvons-nous le bannir? Nous devrions lui demander (très poliment) de supprimer son jeton d'accès. Vérifier chaque requête entrante contre une liste de bannissement? Oui, cela fonctionnerait, mais maintenant nous devrions à nouveau effectuer cet appel à la base de données que nous ne voulons pas.

Compromis avec des jetons à durée de vie courte

Si nous pensons qu'il est acceptable qu'un utilisateur puisse toujours utiliser son compte, disons, pendant 10 minutes après avoir été banni, nous pouvons créer une situation qui est un compromis entre vérifier la base de données à chaque requête et uniquement à la connexion. C'est là que les jetons de rafraîchissement interviennent. Ils nous permettent d'utiliser un mécanisme sans état avec des jetons d'accès de courte durée de vie. Nous ne pouvons pas révoquer ces jetons car aucun contrôle de base de données n'est effectué pour eux. Nous ne vérifions que leur date d'expiration par rapport à l'heure actuelle. Mais une fois qu'ils expirent, l'utilisateur devra fournir le jeton de rafraîchissement pour obtenir un nouveau jeton d'accès. À ce stade, nous vérifions la base de données et constatons que l'utilisateur a été banni. Nous refusons donc la demande d'un jeton d'accès et le bannissement prend effet.

Answer 3

La réponse référencée (via @Anders) est utile, elle indique:

En cas de compromission, la fenêtre de temps pendant laquelle elle est valable est limitée, mais les jetons sont utilisés via SSL, donc peu susceptibles d'être compromis.

Je pense que la partie importante est que les jetons d'accès sont souvent enregistrés (surtout lorsqu'ils sont utilisés comme paramètre de requête, ce qui est utile pour le JSONP), il est donc préférable qu'ils soient à durée de vie courte.

Il y a quelques raisons supplémentaires, avec des mises en œuvre à grande échelle de OAuth 2.0 par les fournisseurs de services:

1. Les serveurs API peuvent valider de manière sécurisée les jetons d'accès sans recherches en base de données ou appels RPC s'il n'est pas nécessaire de se soucier de la révocation. Cela peut avoir de forts avantages en termes de performances et réduire la complexité pour les serveurs API. Mieux si vous êtes d'accord pour qu'une révocation de jeton prenne 30 à 60 minutes (ou quelle que soit la durée du jeton d'accès). Bien sûr, les serveurs API pourraient également conserver une liste en mémoire des jetons révoqués au cours de la dernière heure également.

2. Étant donné que les jetons peuvent avoir plusieurs étendues avec accès à différents services API, avoir des jetons d'accès à durée de vie courte empêche un développeur de service API d'avoir un accès à vie aux données d'un utilisateur sur le service API B. La compartimentation est bonne pour la sécurité.

Answer 4

Réponse la plus courte possible :

Les jetons de rafraîchissement permettent des temps de dégradation différents / ciblés des jetons. Les jetons de ressource réels ont une durée de vie courte, tandis que le jeton de rafraîchissement peut rester valide pendant des années (applications mobiles). Cela offre une meilleure sécurité (les jetons de ressource n'ont pas besoin d'être protégés) et des performances améliorées (seul l'API de jeton de rafraîchissement doit vérifier la validité par rapport à la base de données).

Answer 5

Voici un complément aux avantages des jetons de rafraîchissement déjà mentionnés.

Sécurité d'abord!

Les jetons d'accès ont une durée de vie limitée. Si quelqu'un vole un jeton d'accès, il n'aura accès aux ressources que jusqu'à ce que le jeton d'accès expire.

"...Mais que se passe-t-il si un jeton de rafraîchissement est volé?"

Si un attaquant vole le jeton de rafraîchissement, il peut obtenir un jeton d'accès. Pour cette raison, il est recommandé de délivrer un nouveau jeton de rafraîchissement à chaque fois qu'un nouveau jeton d'accès est obtenu. Si le même jeton de rafraîchissement est utilisé deux fois, cela signifie probablement que le jeton de rafraîchissement a été volé.

Lorsque le jeton de rafraîchissement change après chaque utilisation, si le serveur d'autorisation détecte qu'un jeton de rafraîchissement a été utilisé deux fois, cela signifie qu'il a probablement été copié et est utilisé par un attaquant, et le serveur d'autorisation peut révoquer immédiatement tous les jetons d'accès et les jetons de rafraîchissement qui y sont associés.

https://www.oauth.com/oauth2-servers/making-authenticated-requests/refreshing-an-access-token/

Bien entendu, ceci n'est qu'une autre couche de sécurité. L'attaquant peut encore avoir le temps d'obtenir des jetons d'accès, jusqu'à ce que le jeton de rafraîchissement soit utilisé une deuxième fois (par l'attaquant ou l'utilisateur réel).

N'oubliez jamais que le jeton de rafraîchissement doit être stocké de manière aussi sécurisée que possible.