Nous apprécions tous le fait que les applications natives ne vous demandent de vous connecter qu'une seule fois, puis vous retiennent en mémoire jusqu'à ce que vous leur indiquiez que vous souhaitez vous déconnecter. Malheureusement, le Web ne fonctionne pas toujours de cette manière.
Maintenant que les appareils, en particulier les appareils mobiles, sont plus personnels, et que de plus en plus de sites envoient tout leur 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 session, certains sites Web ne vérifient pas l'authentification de l'utilisateur à chaque requête (en d'autres termes, il n'est pas possible de révoquer le cookie de session une fois qu'il a été émis). Cela entraîne généralement des sessions courtes, l'utilisateur étant obligé de se connecter fréquemment pour que son authentification puisse être validée à nouveau. Par exemple, un changement de mot de passe peut invalider les sessions existantes dans un délai connu.
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 à longue durée de vie qui peut être utilisé pour actualiser votre cookie d'authentification à courte durée de vie existant. L'utilisation du nouveau modèle de service worker nous permet de "vérifier régulièrement" le jeton à durée de vie longue, de valider l'authentification de l'utilisateur (par exemple, vérifier s'il n'a pas récemment modifié ses mots de passe ou révoqué la session) et de réémettre un nouveau cookie d'authentification de courte durée.
Proposition pratique pour passer à des sessions longues sécurisées sur le Web
À partir de là, cet article décrit une nouvelle technique que nous proposons d'appeler 2-Cookie-Handoff (2CH). Nous espérons que cet article permettra à la communauté de nous faire part de ses commentaires sur cette approche, et si elle nous semble positive, de travailler avec le secteur sur la documentation des bonnes pratiques d'utilisation de la fonctionnalité 2 canaux.
Les services workers sont une nouvelle technologie compatible avec plusieurs navigateurs, tels que Chrome, Firefox et Opera, et bientôt avec 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 qui peuvent intercepter toutes les requêtes réseau de votre page et effectuer l'échange de jetons comme le font les applications mobiles.
Dans la plupart des cas, 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 pour 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 déjà d'un tel point de terminaison, il peut en créer un uniquement pour la gestion des sessions de navigateur.
Le modèle à deux jetons avec les service workers suit le modèle OAuth 2.0 de manière assez proche. 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 ce qu'il 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, ils ne verront aucune différence et continueront à avoir des sessions courtes.
Nous avons publié un exemple de client et de backend. Nous espérons que vous l'essaierez par vous-même et que vous répondrez à une enquête sur la gestion des sessions.