Follow

Les techies, j'ai besoin de votre aide (une nouvelle fois). Dans le cadre de la création d'un front&back avec API entre les deux, j'aimerais mettre en place une authentification (la base : login/password), sauf que pour ça il est quand même préférable de passer par du token.
J'ai trouvé intéressant JWT, utilisé partout, normé tout ça. J'ai néanmoins une question : comment faire en sorte que la connexion soit "infinie" (ou presque) ? Sans devoir se reco toutes les 5minutes… Du refresh token ? Thx

· · Web · 2 · 2 · 0

@Sp3r4z Oui, du refresh token : quand le back te renvoie un _Unauthorized_, tu lances le renouvellement puis tu refais la requête qui a foiré. Alternative : tu “poll” le back-end toutes les X minutes ou heures pour le faire.

@meduz D'accord.
Je résume :
1. Je me connecte (login/password)
2. L'API me répond : "connected" et "session token + refresh token" (chacun avec date d'expiration)
3. Client envoie dorénavant le "ST" (enfin JWT)
4. "ST" est expiré
5. API me dit "401 unauthorized"
6. Client renvoie le "RT" (qui est un fait du JWT donc il y a l'ancien "ST" expiré et le "RT" pas expiré)
7. API renvoie nouveau ST et RT
8. Retour à 3.

C'est bien ça ? Si oui, quand RT est expiré, besoin de retourner à 1. ?

@meduz De plus, où/comment stockes-tu tes JWT ? Dans les LocalStorage/SessionStorage (peu sécurisé), dans des cookies (avec HTTPonly, secure et samesite) ?

@Sp3r4z Au taf, on fout ça dans un cookie mais je suis pas certain pour le niveau de sécurité (je connais encore mal l’authentification du projet). En tout cas, localStorage/sessionStorage sont pas des options viables.

Sinon, au niveau du flux, c’est comme tu le décris, il me semble.

À titre perso, j'utilise jamais de JWT dans mes projets (je préfère un vrai back-end intermédiaire entre l’API et le front-end), mais j’exclus pas d’essayer à un moment…

@meduz Merci pour toutes tes réponses, ça m'aide beaucoup :)

SI tu n'utilise pas de JWT, qu'utilises-tu en perso ?

@Sp3r4z Ces bons vieux cookies, avec un rechargement de la page de toutes façons à la connexion / déconnexion.

@meduz Okay, tu n'encapsules pas de JWT dans le cookie, je vois. C'est "similaire" disons, l'effet est le même.

@Sp3r4z Oui. Ça évite aussi d’avoir du JS servi côté client là où le serveur se débrouille très bien, avec une meilleur sécurité.

@meduz Oui, le serveur bosse te le JS client sert vraiment que au client, je comprend bien. Ma problématique sur le projet en question c’est justement décorréler le front des données, et taper une API entre les deux.

@meduz j'ai une question : pour JWT, rien est en base de données? Pas le refres token?
Tu gères comment la révocation du token? ou la déconnexion de toutes les sessions d'une personne?

@Sp3r4z Je sais pas si j'ai la bonne réponse, mais a priori, je dirais :

- Si, tokens en DB: 1 ligne = utilisateur_id + JWT + refresh token + expiration.

- La révocation : à l'expiration ou si l'utilisateur demande à se déconnecter, tu vires l’entrée de DB qui correspond à sa session en cours.

- La déco de toutes les sessions : tu vires toutes les entrées DB de l'utilisateur.

À vérifier avec des experts. 🤓

@meduz Merci pour ta réponse. Je vais étudier cela :)

@Sp3r4z Reviens raconter tes trouvailles à l’occasion. 👋

@meduz Après bon nombre de lecture et d’essais, visiblement JWT c'est pas mal du tout, mais couplé avec du cookie (pour mitigate XSS et CSRF) avec secure+samesite:strict+httponly. Rien du tout en base de donnée, si ce n'est au pire pour la révocation un champ "revocated → timestamp" (si besoin de révocation), ou mécanisme "simpel" du genre.
Avec deux JWT : un "session token" et un "refresh token". Les lib gèrent très bien si un JWT est expiré.
Et basta 1/

@meduz Si on veut être plus "souple" (je ne suis pas sûr d'en voir l'intérêt), un met "session token" dans le Session/LocalStorage HTML, et le "refresh token" dans les cookies (par le serveur). Mais ça fait des aller retour inutiles du client qui demande "tu peux me rafraîchir mon token", alors qu'avec les cookies le back sait déjà si t'es expiré et si t'as le droit ou non.

D'autant que pour déchiffré une signature JWT faut le secret (et i lest secret)… 2/

@meduz Je ne vois pas trop l'intérêt du :
1. client fait une requête
2. serveur dit "tu n'es pas autorisé"
3. client demande un refresh
4. récupère une nouvelle paire (ST + RT)
4 bis. client doit se reconnecter

Alors qu'on pourrait juste faire :
1. client fait une requête
2. serveur voit que c'est expiré
3. refait le cookie (avec ST + RT)
3 bis. RT expiré on dit 401:unauthorized
4. client vire la session

Ça me parait plus transparent ainsi et plus facilement maintenable 3/3

@Sp3r4z Merci pour les infos, c’est intéressant !

Le coup du « pas autorisé / redemande une paire / reco / refait la requête qui a foiré initialement », c’est dans le cas d’une SPA (au taf) car tu peux pas « refaire un cookie » complètement secure sans rechargement de page.

Y’a quand même des trucs qui m’échappent dans le fonctionnement des JWT. :oscar: Je creuserai à l’occasion.

@meduz En effet le refresh de cookie, ne se fait que au refresh d'une page, d'où cette utilisation en SPA tu as raison.

Ça m'échappe aussi un peu trop à mon goût, JWT. Je vais continuer à creuser, notamment sur la partie "il faut un cookie secure" et l'aspect "XSS et CSRF" qui m'ont l'air assez étonnant.

@Sp3r4z mettre la date d'expiration à une date très loin dans le futur ou utiliser la méthode de refresh token. Normalement les librairies jwt ont tout pour ça. C'est assez automatisé pour ne pas se prendre la tête.

@metal3d J'avais pas l'impression qu c'était très "automatisé", dans le sens que le front qui demande à l'API de refresh le token ,c'est des actions à faire/coder, non ?

@Sp3r4z oui c'est bien le front qui demande un refresh parce qu'il dépasse la date d'expiration. C'est plutôt logique dans le process. Mais en soit, ce n'est qu'un appel à faire quand la date est dépassée, côté back tout est généralement bien foutu pour rafraîchir le token. Du moins en Python, c'est un truc qui est facile à gérer avec Flask ou Quart.

@Sp3r4z en fait, c'est simple hein. Le front utilise le back qui, quand le token expire, lui retourne une erreur "hé ho t'es périmé". Dans ça cas, le front fait un appel de refresh, il a son nouveau token et il relance la requête.

@Sp3r4z côté back, comme tu dois normalement vérifier le token à chaque appel du client... C'est cette vérification qui retourne une erreur d'expiration au client. Il lui donne aussi en général une adresse de refresh. Côté client c'est un simple "if erreur d'expiration" à mettre en place.

@metal3d C'est bien ce que j'avais compris, merci de me l'avoir confirmé. C'est ton "assez automatisé" que je n'avais pas, en effet ça reste "basique".

En revanche, côté front, tu stocke ça où ? SessionStorage/LocaleStorage, Cookie , les deux (une partie das cookie, une autre dans SS/LS)?

@Sp3r4z généralement utilise le local storage et j'envoie le token en header. Mais tout va dépendre de ton besoin. Certains préfèrent le cookie http only mais je trouve ça chiant à gérer sur les appels httprequest.

@Sp3r4z j'ajoute juste un truc. Le jwt est pratique car il permet de mettre des data dans le corps du token. Y placer l'id et le nom d'utilisateur c'est pratique. Ça se décode via base64.

@metal3d merci pour toutes tes réponses. JWT me parait etre une bonne chose, je vais partir là dessus, et je verrais pour le stockage front où le mettre.

@Sp3r4z pas de quoi 😉 après c'est mon avis, y'a peut-être des gens pas d'accord avec moi hein.

@metal3d c'est la question du stockage client qui divise, et la durée du refresh token. Le reste est okay pour tout le monde 😃

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!