Une session est une période pendant laquelle un client (logiciel ou système d’exploitation) est en communication avec un hôte (application backend ou appareil). Avant de commencer, elle demande généralement à un utilisateur de s’authentifier. On parle alors d’ouverture de session explicite. Enfin, la session se termine souvent lorsque l’utilisateur n’utilise plus le système.
Son rôle est déterminant dans la création des applications web : un utilisateur reste connecté. Le client reçoit des informations de sessions pour maintenir la connexion. Il les conserve dans son profil utilisateur, sous forme de variables, avec une durée éphémère ou longue, et doit les transmettre au serveur pendant toute la communication, sinon la session est perdue.
Dans un serveur web, communicant en HTTP, il existe différentes méthodes pour créer une session avec un utilisateur. Reconnaissable par sa popup, le basic access authentication est simple, mais pas très sécurisé. On le voit dans des services restreints comme la configuration d’un serveur. Les deux autres méthodes sont la session HTTP et le JSON Web Token (JWT).
Dans une session HTTP, le serveur instancie chaque session avec un identifiant de session, ou appelé ID session en anglais. Le client reçoit le jeton dans un cookie (témoin de connexion), petite paire de clé-valeur stockée temporairement, et l’enverra tout le temps au serveur pour prouver la session. Ajoutant une couche à HTTP, la session HTTP devient un protocole avec état, car le serveur conserve l’état de la session entre les requêtes (ID session, nom d’utilisateur…). À la place d’un cookie, il est toutefois possible d’utiliser GET ou POST.
Le JSON Web Token est une chaîne de caractère compactée qui contient un ensemble de revendications vérifiables. Par exemple, l’utilisateur est « tensivehoney », et a un rôle d’administrateur. Dans son utilisation la plus courante, le JWT est généré par le serveur après une authentification, et envoyé à l’utilisateur. Le client le stocke dans un cookie ou le web local, et le transmet à l’application backend pendant toute la session. Les informations sont vérifiables, car le jeton est signé numériquement. Plus besoin de conserver l’état de la session côté serveur, mais de vérifier. Ce protocole sans état (stateless) respecte une des contraintes de l’architecture REST. En OAuth2, le JWT est obtenu à partir d’un serveur d’autorisation (Authorization Server).
La différence fondamentale entre la session HTTP et le JSON Web Token est l’état du protocole. Dans un scénario avec plusieurs applications backend utilisant une session, par exemple des microservices avec une authentification, la session HTTP devra être partagée dans un stockage de session centralisé comme Redis. Tandis qu’avec JWT, tout est déjà dans le client.
