Discussion :

[Fectorez]

Contexte : Pour autoriser l'accès d'un client à une ressource de l'API, ce client ajouter un token dans les headers, comme "Bearer <token>" dans le header "Authorization", ce token ayant été obtenu via le login, et expirant dans, disons, 1 jour.

Problème : L'utilisateur peut se retrouver déconnecté en pleine utilisation.

Solution trouvée sur internet : Au login, l'API renvoie un access token et un refresh token. Si l'access token est expiré, on fait appel à une route spécifique en postant le refresh token, ce qui nous renverra un nouvel access token. La validité du refresh token est contrôlée grâce à une liste de refresh token disponibles via une base de données.

Cependant, je trouve cette solution lourde, requiert un backend stateful, et de multiples appels HTTP.
Ce que j'aurais envie de faire, c'est de stocker l'access token dans les cookies du client, et à chaque nouvel appel à n'importe quelle route, le backend générera un nouvel access token qu'il mettra dans les cookies. Ainsi, le client n'a rien à faire.

Mais je me dis que si tout le monde utilise la première solution, c'est qu'il y a une raison, non ? Qu'en pensez-vous ?

[mathieu]

avec ce fonctionnement, c'est comme s'il y avait un jeton d'accès valable sans limite de temps.
une autre façon de faire serait qu'à chaque interaction avec le client, la validité du jeton d'accès est prolongée de 24 heures.

[Fectorez]

Mais c'est justement ce que je propose non ? Mettre un nouveau jeton à chaque appel à l'API ? Dans votre cas aussi le jeton serait infini, non ?

[mathieu]

la différence c'est qu'avec ce que je propose, le client est déconnecté s'il ne passe pas pendant plus de 24 heures.

[Fectorez]

Peut-être que j'aurais dû préciser ma solution : l'API renvoie un nouveau jeton seulement si celui passé dans la requête entrante est toujours valide. On parle bien de la même chose ?