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 aimons tous la façon dont les applications natives vous demandent de vous connecter une seule fois et se souviennent de vous jusqu'à ce que vous décidiez 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 reconsidérer leurs règles concernant les cookies de courte durée et adopter des sessions plus conviviales et plus longues.

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 qu'il a été émis. Cela entraîne généralement des sessions de courte durée, où l'utilisateur est obligé de se connecter fréquemment pour que son authentification puisse être de nouveau validée. Ainsi, un changement de mot de passe peut invalider des sessions existantes pendant une durée connue.

Si vous utilisez cette approche, nous disposons d'une solution technique qui peut vous aider à revalider automatiquement le cookie d'authentification sans état. Il fonctionne avec un jeton secondaire de longue durée qui peut être utilisé pour actualiser votre cookie d'authentification de courte durée existant. L'utilisation du nouveau modèle de service worker nous permet de nous "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 récemment modifié son mot de passe ou s'il n'a pas révoqué la session) et émettre un nouveau cookie d'authentification de courte durée.

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

Cet article décrit une nouvelle technique que nous suggérons d'appeler 2-Cookie-Handoff (2CH). Nous espérons pouvoir utiliser cet article pour recueillir les commentaires de la communauté et nous dire si cette approche semble positive, et, le cas échéant, collaborer avec les acteurs du secteur pour documenter les bonnes pratiques d'utilisation du 2CH.

Cette nouvelle technologie est compatible avec plusieurs navigateurs tels que Chrome, Firefox et Opera, et sera bientôt disponible sur Edge. Ils vous permettent d'intercepter toutes les requêtes réseau en provenance 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 l'échange de jetons, 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, ce point de terminaison doit simplement être mis à jour afin de comprendre quand il est appelé par un service worker, puis renvoyer un nouveau cookie de session de courte durée mis en forme d'une manière que les autres pages du site s'attendent déjà.

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 du navigateur.

La séquence "2-cookie-handoff"

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 mettez en œuvre l'approche ci-dessus, ils ne constateront tout simplement pas de différence et continueront à enregistrer de courtes sessions.

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