Connexion

Je suis en train de bosser sur un petit projet perso et je me retrouve un peu bloqué. J'ai une appli web qui doit récupérer des données depuis un service externe, et j'ai implémenté l'authentification OAuth 2.0 sans trop de souci. Mais maintenant, pour rafraîchir le token d'accès silencieusement, je me demande si je dois vraiment gérer le refresh token côté serveur pour des raisons de sécurité, ou si je peux le faire côté client sans trop de risque dans mon cas. C'est un peu flou pour moi de savoir où placer cette logique.

Pour moi le refresh token doit rester du côté serveur si tu veux rafraichir sans exposer les secrets. En OAuth avec PKCE tu échanges le code contre un access token et un refresh token sur le serveur et tu n envoies pas le refresh token au client. L ideal est de stocker le refresh token dans un cookie http only et d appeler le endpoint de rafraichissement depuis ton backend. Si le token fuit c est une faille

De mon côté je pense a une approche analytique. Le token de rafraichissement sert a prolonger la session sans redemander l authentification. Dans une SPA tu peux envisager un flow avec PKCE et un serveur qui fait l appel au provider pour le rafraichissement et qui renvoie un nouveau access token a l application cliente. Cela evite de stocker le refresh token dans le navigateur et permet des controles de rotation et de révocation. Le mot clé refresh token est central dans ce schéma

Je suis un peu sceptique sur le tout côté client surtout si tu as un refresh token qui peut etre intercepté ou stocké dans le local storage. Si c est le seul choix alors il faut restreindre la durée du token et utiliser la rotation des tokens pour limiter les dégâts.Personnellement je me méfie

On peut reformuler le souci ainsi est ce que la securité et la simplicité justifient d avoir une logique de rafraichissement dans le serveur ou est il acceptable d avancer avec une solution purement client. Le sujet revient sur qui gère l authentification et la session et pas sur l endroit exact ou tombe le refresh token

Option pratique reste de faire connaitre un refresh token passé par le serveur et d utiliser des cookies http only plus le renouvellement via un endpoint securisé. Tu peux aussi limiter la portée et faire rotation du refresh token pour detection de fuite. Dans ce cadre il faut bien tester les scénarios d erreur

Pour les lecteurs le sujet est influencé par les attentes des utilisateurs et le risque toléré dans le produit. Le mot clé refresh token revient comme un outil qui peut creer une impression de securite selon comment on l expose

Connexion
Nom d’utilisateur
Mot de passe	Mot de passe oublié ?
	Se souvenir de moi