Fin des sessions de courte durée : proposition visant à faire appel aux service workers pour améliorer la gestion des cookies sur le Web

William Denniss
Owen Campbell-Moore

Nous apprécions tous la façon dont les applications natives vous demanderont de ne vous connecter qu'une seule fois, puis de se souvenir de vous jusqu'à ce que vous leur demandiez de vous déconnecter. Malheureusement, le Web ne fonctionne pas toujours de cette façon.

Maintenant que les appareils, en particulier les appareils mobiles, sont plus personnels, et que davantage de sites envoient tout le trafic via HTTPS, ce qui réduit le risque de vol de jetons, les sites Web doivent revoir leurs règles concernant les cookies de courte durée et adopter des sessions plus longues et plus conviviales.

Toutefois, même si vous souhaitez prolonger la durée de la session, certains sites Web ne vérifient pas l'authentification de l'utilisateur à chaque requête (en d'autres termes, il n'existe aucun moyen de révoquer le cookie de session une fois émis). Cela conduit normalement à de courtes sessions, où l'utilisateur est obligé de se connecter fréquemment afin que son authentification puisse être à nouveau validée, ce qui permet par exemple un changement de mot de passe pour invalider les sessions existantes dans un laps de temps connu.

Si vous optez pour cette approche, nous disposons d'une solution technique qui peut vous aider à revalider automatiquement le cookie d'authentification sans état. Il fonctionne en disposant d'un jeton secondaire de longue durée qui peut être utilisé pour actualiser votre cookie d'authentification de courte durée existant. Le fait d'exploiter le nouveau modèle de service worker nous permet de "vérifier" régulièrement avec le jeton de longue durée, de vérifier l'authentification de l'utilisateur (par exemple, s'il n'a pas modifié ses mots de passe récemment ou s'il n'a pas révoqué la session) et d'émettre à nouveau un cookie d'authentification éphémère.

Proposition pratique pour migrer vers des sessions longues sécurisées sur le Web

De là, cet article décrit une nouvelle technique que nous proposons, que nous appelons 2-Cookie-Handoff (2CH). Nous espérons utiliser cet article afin de recueillir les commentaires de la communauté pour savoir si cette approche semble positive et, le cas échéant, collaborer avec le secteur sur la documentation des bonnes pratiques d'utilisation de la 2CH.

Les service workers sont une nouvelle technologie compatible avec plusieurs navigateurs tels que Chrome, Firefox, Opera et bientôt dans Edge. Ils vous permettent d'intercepter toutes les requêtes réseau de votre site via un point de code commun sur le client, sans modifier les pages existantes. Cela vous permet de configurer un "nœud de calcul 2CH" pour les utilisateurs connectés, capable d'intercepter toutes les requêtes réseau effectuées par votre page et d'effectuer le changement de jeton, comme le font les applications mobiles.

La plupart du temps, votre serveur dispose déjà d'un point de terminaison utilisé par les applications mobiles pour obtenir un nouveau jeton de courte durée, généralement à l'aide du protocole OAuth. Pour activer le modèle ci-dessus sur le Web, il suffit de mettre à jour ce point de terminaison afin de comprendre quand il est appelé par un service worker, puis de renvoyer un nouveau cookie de session de courte durée au format attendu par les autres pages du site.

Si votre serveur ne dispose pas encore d'un tel point de terminaison, il peut en créer un uniquement pour la gestion des sessions de navigateur.

La séquence de transfert à deux cookies

Le modèle à deux jetons avec les service workers suit assez fidèlement le modèle OAuth 2.0. Si vous exécutez déjà un point de terminaison de jeton OAuth, vous pouvez probablement le réutiliser avec des service workers pour votre authentification Web.

Vous vous demandez peut-être également ce qui se passe si l'utilisateur accède à un navigateur qui n'est pas compatible avec les service workers. Si vous implémentez l'approche ci-dessus, les sessions ne feront simplement aucune différence et continueront de générer de courtes sessions.

Nous avons publié un exemple de client et de backend. Nous espérons que vous l'essayerez par vous-même et que vous répondrez à une enquête sur la gestion des sessions.