Discussion :

[kelinox]

Bonjour,

Je suis actuellement en train de développer une appli mobile sous android studio. Faisant le système de login, je vais utiliser les tokens pour la connexion et la gestion de droit. J'utilise la bibliotèque jjwt : https://github.com/jwtk/jjwt
Je suis actuellement capable de créer les tokens et de les décrypter en suivant la documentation github. Seulement, j'ai un petit souci lors de l'expiration du token. J'aimerai créer un refresh token lors du login et avec ce dernier créer des access tokens pour des questions de sécurités évidentes. J'ai bien compris le principe dans la théorie, seulement dans la pratique j'ai un peu de mal.
Je ne sais pas exactement quelles sont les informations que doit contenir le refresh token, et je n'ai aucune idée de comment créer un access token à partir du refresh token.
Si vous pouviez m'éclairer la dessus merci.

[tchize_]

un refreshtoken et un accesstoken on en général la même structure. C'est leur usage qui les différencie.


Un refreshtoken est utilisé entre ton application et ton service d'authentification (A). Ton application lui dit en gros "hé, c'est toujours moi, tu peux me refiler un nouvel accessToken valide pendant 5 minutes?"
Un accesstoken est utilisé entre ton application et le service (S) qui a besoin de savoir qui tu es, ton application s'amène avec et lui dit "hé, tiens A m'a filé ça pour prouver qui je suis, tu peux me filer mes données?"


dans tous les cas se sont

des JWT
avec une signature cryptographique
avec une date de validité (longue pour le refresh, courte pour l'access)
avec du contenu (id utilisateur, groupes, whatever)

le refreshtoken est secret, on ne le partage avec personnes d'autre que l'autorité qui l'a émise
l'accesstoken est moins secret, on le partage avec toutes les app où on a besoin de montre patte blanche

[kelinox]

Ok, j'ai bien compris ce principe. Mon problème est que je vois pas comment faire la phase

"hé, c'est toujours moi, tu peux me refiler un nouvel accessToken valide pendant 5 minutes?"

à partir de mon refresh token.

[tchize_]

ben t'as un service, qui vérifie que t'as bien le refresh token (soit en parametre, soit dans tes headers, a décider) et qui génère un nouveau token, l'access token. Ce n'est pas très différent de créer un service qui prend l'accesstoken et qui te retourne tes données si tu y est autorisé.


La difficulté c'est de faire tout ça correctement dans les règle avec tous les dangers coté sécurité et ce n'est pas sur une question qu'on répondra à tout, il y a pas mal de chose à gérer (révocation, communication entre serveurs en backend pour valider les tokens, tokens permanent, etc)


Si t'as pas envie de t'emmerder avec cette partie, il existe déjà des serveur oauth qui font déjà tout le travail d'authentification et que tu peux réutiliser (keycloak par exemple)

[kelinox]

Quelle est la meilleur solution implémenté cela soit même ou alors utiliser une api toute faîte ?
Car pour la révocation, communication entre le serveur tout le système peut être mis en place, il faut juste que je comprenne comment à partir d'un refresh token je peux générer un access token(tout en vérifiant qu'il est valable).

[tchize_]

Sur cette partie là j'ai du mal à comprendre ce que tu trouve difficile. Un refresh token et un access token se valident exactement de la même façon. C'est juste que quand tu génère un refreshtoken tu le génère pour une longue période alors que quand tu génère un access token tu le génère pour une courte période. Le refresh token contient tout ce qu'il faut pour identifier l'utilisateur et le valider, comme tout bon JWT signé, l'access token même chose mais il est plus court. Après il est recommandé de garder un db des refreshtokent que t'as généré pour pouvoir les invalider coté serveur avant leur fin de vie. Et tu peux envisager de générer des accesstoken différents en fonction des services ciblés.

Si tu as du mal avec ces concepts, je te conseille plutot de passer par une api d'authentification éprouvée et de suivre ses recommandation, sinon tu pars pour un gros plantage sécurité.