Session Token dans le développement d’applications — ce que c’est, principe de fonctionnement et différences avec JWT

Qu’est-ce qu’un Session Token?

Session Token (identifiant de session) est une chaîne unique que le serveur génère et associe aux données de session après l’authentification de l’utilisateur. Le jeton ne contient aucune information utilisateur — c’est simplement une clé vers les données stockées sur le serveur. Cette approche est appelée authentification stateful : le serveur stocke l’état de chaque session active et le vérifie à chaque requête.

Les données de session incluent : identifiant utilisateur, heure de connexion, adresse IP, user-agent, liste d’autorisations, heure de dernière activité. Lorsque le client envoie une requête avec un session token, le serveur trouve l’enregistrement correspondant dans le stockage de sessions, vérifie sa validité et récupère les données pour traiter la requête. Si l’enregistrement de session est manquant ou a expiré, le serveur renvoie une erreur d’authentification et demande une nouvelle connexion.

Selon OWASP, 2025, le session token reste la norme pour les applications nécessitant une révocation immédiate d’accès — par exemple, dans les systèmes bancaires et les portails d’entreprise où un administrateur doit pouvoir mettre fin à la session d’un utilisateur instantanément. Dans ces systèmes, le session token offre un contrôle total de l’accès qui est inaccessible aux jetons stateless sans mécanismes de blocage supplémentaires.

Comment fonctionne un Session Token

Le processus commence lorsque le client envoie les identifiants au serveur d’authentification. Le serveur vérifie le nom d’utilisateur et le mot de passe, crée un enregistrement de session dans le stockage (généralement Redis ou une base de données) et renvoie un session token unique au client. Le client conserve le jeton et l’envoie avec chaque requête suivante, et le serveur vérifie à chaque fois l’existence et la validité de la session.

Session serveur et stockage

Redis est le stockage de sessions le plus populaire grâce au stockage en mémoire et au support TTL (durée de vie). Chaque session est stockée comme une paire clé-valeur, où la clé est le session token et la valeur est un objet JSON contenant les données de session. Le TTL supprime automatiquement les sessions expirées. Alternatives : Memcached (mémoire seulement, sans persistance sur disque), PostgreSQL/MySQL (persistants mais plus lents) et DynamoDB (pour l’infrastructure AWS).

Exemple de structure de session dans Redis : session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Le serveur met à jour lastAccess à chaque requête, ce qui permet d’implémenter un délai d’inactivité — une terminaison automatique de la session après une période sans activité.

Cookie vs En-tête

Session Token peut être transmis de deux manières : via un cookie HTTP ou via l’en-tête HTTP Authorization. Les cookies sont la méthode traditionnelle pour les applications web : le serveur définit un cookie avec les drapeaux HttpOnly (inaccessible depuis JavaScript), Secure (HTTPS uniquement) et SameSite (protection CSRF). Pour les applications mobiles, l’en-tête Authorization: Bearer <session_token> est plus couramment utilisé, car le mécanisme de cookie n’est pas toujours pratique dans les clients natifs.

Cycle de vie du Session Token

Le cycle de vie du session token comprend trois étapes : la création, le maintien de la session active et la terminaison. Chaque étape nécessite une configuration de sécurité appropriée pour éviter la fuite ou l’interception du jeton.

Création, stockage et suppression

Création — le serveur génère une chaîne aléatoire cryptographiquement sûre de 128 à 256 bits (par exemple, via SecureRandom en Java ou os.urandom en Python). Le jeton doit être imprévisible — l’utilisation d’UUID ou d’horodatage sans entropie n’est pas acceptable. Stockage côté client : sur iOS — Keychain, sur Android — EncryptedSharedPreferences, sur le web — cookie HttpOnly. Suppression se produit à la déconnexion : le client supprime le jeton du stockage, le serveur supprime l’enregistrement de session de Redis. Après la déconnexion, le session token devient inutile — le serveur ne trouve pas d’enregistrement correspondant.

Selon SANS Institute, 2025, une implémentation correcte de la terminaison de session (déconnexion avec nettoyage côté serveur) prévient jusqu’à 70 % des attaques utilisant des jetons volés. Il est crucial non seulement de supprimer le jeton côté client, mais aussi d’invalider la session sur le serveur.

Session Token vs JWT

Session Token et JWT représentent deux approches différentes de l’authentification. Session Token est stateful (le serveur stocke l’état), JWT est stateless (les données à l’intérieur du jeton). Le choix entre eux dépend de l’architecture de l’application et des exigences de sécurité.

Quand choisir Session Token

Session Token est préférable lorsque : une révocation immédiate des sessions est requise (services bancaires, panneaux d’administration), l’application fonctionne sur un ou plusieurs serveurs avec un Redis partagé, les données de session sont volumineuses et ne tiennent pas dans un JWT, ou l’équipe souhaite minimiser le risque de fuite de données par décodage du jeton. Dans ces scénarios, le session token fournit un blocage immédiat de l’accès en cas d’activité suspecte — il suffit de supprimer un enregistrement de Redis pour que toutes les sessions de l’utilisateur deviennent invalides.

Selon Redis, 2025, l’utilisation de TTL au niveau des clés de session (commande EXPIRE) nettoie automatiquement les sessions expirées sans surcharge sur les tâches d’arrière-plan. Pour des sessions avec un TTL d’une heure et une charge de 10 000 utilisateurs simultanés, Redis consomme environ 1 Go de RAM pour une taille de session de 1 Ko, ce qui le rend rentable pour la plupart des applications.

Sécurité du Session Token

La sécurité du session token repose sur deux principes : le jeton doit être imprévisible et protégé lors de la transmission et du stockage. Les principales menaces sont l’interception du jeton (man-in-the-middle, XSS), sa prédiction (génération faible) et la fixation de session (session fixation).

Protection contre le vol du jeton

La protection comprend : l’utilisation de HTTPS pour toutes les requêtes avec jeton, la définition d’un TTL court de session (15–60 minutes d’inactivité), la liaison de la session à l’IP et au user-agent (vérification supplémentaire à chaque requête), l’utilisation des drapeaux Secure et HttpOnly pour les cookies, et la rotation régulière du session token après des opérations sensibles (changement de mot de passe, élévation de privilèges). OWASP recommande également d’implémenter une Gestion de Sessions avec invalidation de l’ancienne session lors de la création d’une nouvelle après connexion — cela empêche la fixation de session.

Selon OWASP ASVS, 2025, une session doit être liée à au moins deux facteurs : le jeton lui-même (ce que le client possède) et l’IP/user-agent (ce que le serveur sait). Si ces facteurs ne correspondent pas, le serveur doit mettre fin à la session et demander une ré-authentification.

Exemple d’implémentation en Kotlin

Ci-dessous un exemple d’implémentation côté serveur d’un session token en Kotlin avec Spring Boot et Redis. Le serveur génère un jeton cryptographiquement sûr via SecureRandom, enregistre la session dans Redis avec TTL et la vérifie à chaque requête. Le code démontre trois opérations principales : la création de session, la validation et l’invalidation.

data class Session(
    val userId: Long,
    val role: String,
    val createdAt: Long,
    val lastAccess: Long
)

object SessionManager {
    private val redis = JedisPool("localhost", 6379)

    fun createSession(userId: Long, role: String): String {
        val token = generateSecureToken()
        val session = Session(userId, role, now(), now())
        redis.resource.use { conn ->
            conn.setex("session:$token", 3600, toJson(session))
        }
        return token
    }

    fun validateSession(token: String): Session? {
        redis.resource.use { conn ->
            val json = conn.get("session:$token") ?: return null
            return fromJson(json)
        }
    }

    fun invalidateSession(token: String) {
        redis.resource.use { it.del("session:$token") }
    }

    private fun generateSecureToken(): String {
        val bytes = ByteArray(32)
        SecureRandom().nextBytes(bytes)
        return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)
    }
}

Cette implémentation utilise JedisPool pour une connexion thread-safe à Redis. La méthode createSession définit un TTL d’une heure (3600 secondes) — après cette période, Redis supprimera automatiquement l’enregistrement. La méthode validateSession renvoie null pour les sessions inexistantes ou expirées, ce qui permet au serveur de traiter correctement une requête avec un jeton invalide et de renvoyer HTTP 401.