Mais du coup pourquoi aurait-on besoin du token (qui est quand même une hash) + sa quantité de temps d’expiration + sa date de création + sa date de dernière utilisation, alors qu’on pourrait le remplacer par uniquement : une quantité de temps d’expiration et une date de création + une date de dernière utilisation ?
Le token n’est pas valide indéfiniment, notamment pour des raisons de sécurité. Il faut donc trouver un moyen de le limiter dans le temps en y encodant directement les informations qui permettent de le refuser s’il est périmé.
Mais alors comment s’assurer que le client n’a pas bidouillé lui-même les informations en question afin de pouvoir utiliser le token au-delà de la date prévue ? Le serveur qui délivre le token doit le signer et pour cela il peut utiliser un hash : HASH([infos (en clair)] + clef secrète) = SIGNATURE.
Le client présente donc au serveur les infos, et les infos sont jugées valides car le serveur peut vérifier la signature : pour cela, il suffit de calculer HASH([infos (en clair)] + clef secrète) et de voir si ça correspond bien à la signature que le client donne.
Cela répond donc à la question : alors qu’on pourrait le remplacer par uniquement : une quantité de temps d’expiration et une date de création + une date de dernière utilisation ?
Dans un cas stateless, ce ne serait pas suffisant car le serveur n’a aucun moyen de s’assurer que les infos d’expiration sont authentiques. Le seul moyen de le prouver, c’est d’avoir une signature que seul le serveur est capable de générer, et un hash peut servir à cela.
Pour se passer du besoin de signature, on pourrait aussi délivrer des tokens (qui ne sont pas signés) ayant la forme d’une simple séquence aléatoire (au format UUID4 par exemple) et le serveur se chargerait de vérifier dans une base de données si le token est toujours valide (non périmé, non révoqué) et s’il est associé au bon utilisateur.
Le token avec signature a l’avantage de ne pas avoir besoin de vérifier en BDD à chaque requête, car il peut refourguer les infos aux client qui les lui rendra à chaque requête. Ce principe est la base d’une technique qu’on appelle JWT, assez en vogue pour les API.
Et si a la place du hash c’est le login?
Il est quand même plus sûr d’utiliser un token (avec ou sans signature). Si tu as une fuite du token, tu le révoques et tu en refais un nouveau. Si tu as une fuite du couple utilisateur/mdp, ça devient plus compliqué.
.
Ou c’est juste du bon sens que j’ai pas 
?