Sessions vs authentification basée sur des jetons
Je veux savoir lequel est le plus sûr à implémenter pour l'authentification? & Pourquoi? Authentification basée sur la session OR Authentification basée sur les jetons
Je sais que les sessions peuvent également être utilisées pour d'autres choses, mais pour l'instant, je ne m'intéresse qu'à l'authentification.
Est-il vrai que rien n'est stocké côté serveur si vous utilisez des jetons (même pas en mémoire)? Si oui, alors comment s'identifie-t-il par rapport aux jetons expirés, car cela a également été signé en utilisant le même secret?
Authentification basée sur la session
Dans l'authentification basée sur la session, le serveur effectue tous les travaux lourds côté serveur. De manière générale, un client s'authentifie avec ses informations d'identification et reçoit un identifiant de session (qui peut être stocké dans un cookie) et l'attache à chaque demande sortante suivante. Cela pourrait donc être considéré comme un "jeton" car c'est l'équivalent d'un ensemble d'informations d'identification.
Il n'y a cependant rien d'extraordinaire à propos de cette session_id-String. C'est juste un identifiant et le serveur fait tout le reste. C'est avec état. Il associe l'identifiant à un compte utilisateur (par exemple en mémoire ou dans une base de données). Il peut restreindre ou limiter cette session à certaines opérations ou à une certaine période de temps et peut l'invalider en cas de problème de sécurité et, plus important encore, il peut le faire et changer tout cela à la volée.
De plus, il peut enregistrer les utilisateurs à chaque déplacement sur le (s) site (s) Internet. Les inconvénients possibles sont une mauvaise évolutivité (en particulier sur plusieurs batteries de serveurs) et une utilisation intensive de la mémoire.
Authentification basée sur les jetons
Dans l'authentification basée sur les jetons, aucune session n'est persistante côté serveur (sans état). Les étapes initiales sont les mêmes. Les informations d'identification sont échangées contre un jeton qui est ensuite joint à chaque demande ultérieure (il peut également être stocké dans un cookie).
Cependant, dans le but de réduire l'utilisation de la mémoire, la facilité d'évolutivité et la flexibilité totale (les jetons peuvent être échangés avec un autre client), une chaîne avec toutes les informations nécessaires est émise (le jeton) qui est vérifiée après chaque demande faite par le client au serveur.
Il existe plusieurs façons d'utiliser/créer des jetons:
en utilisant un mécanisme de hachage, par exemple HMAC-SHA1
token = user_id|expiry_date|HMAC(user_id|expiry_date, k)--id et expiry_id sont envoyés en texte clair avec le hachage résultant attaché (k n'est connu que du serveur)
crypter le jeton symétriquement, par ex. avec AES
token = AES(user_id|expiry_date, x)--x représente la clé de cryptage/décryptage
le chiffrer de manière asymétrique, par exemple avec RSA
token = RSA(user_id|expiry_date, private key)
En application
Les systèmes productifs sont généralement plus complexes que ces deux archétypes. Amazon utilise par exemple les deux mécanismes sur son site Web. Des hybrides peuvent également être utilisés pour émettre des jetons comme décrit en 2 et associer également une session utilisateur à celle-ci pour le suivi des utilisateurs ou la révocation éventuelle et conserver la flexibilité client des jetons classiques. Aussi OAuth 2.0 utilise des jetons de porteur spécifiques et de courte durée et des jetons de rafraîchissement de longue durée, par exemple pour obtenir des jetons de porteur.
Sources: