Se déconnecter
Lorsqu'un utilisateur se déconnecte d'un site Web, il indique qu'il souhaite se défaire complètement de l'expérience personnalisée. Il est donc important de respecter le modèle mental de l'utilisateur le plus fidèlement possible. Par exemple, une expérience de déconnexion appropriée doit également prendre en compte les onglets que l'utilisateur a pu ouvrir avant de décider de se déconnecter.
Pour offrir une expérience de déconnexion optimale, il est essentiel de veiller à la cohérence des aspects visuels et d'état de l'expérience utilisateur. Ce guide fournit des conseils concrets sur les points à surveiller et sur la façon de proposer une bonne expérience de déconnexion.
Remarques importantes
Lorsque vous implémentez la fonctionnalité de déconnexion sur votre site Web, tenez compte des aspects suivants pour garantir un processus de déconnexion fluide, sécurisé et intuitif:
- Expérience de déconnexion claire et cohérente: fournissez un bouton ou un lien de déconnexion clair et visible de manière cohérente, qui est facilement identifiable et accessible sur l'ensemble du site Web. Évitez d'utiliser des libellés ambigus ou de masquer la fonctionnalité de déconnexion dans des menus, des sous-pages ou d'autres emplacements peu intuitifs.
- Invite de confirmation: implémentez une invite de confirmation avant de finaliser le processus de déconnexion. Cela peut aider à éviter que les utilisateurs ne se déconnectent accidentellement et leur permet de réévaluer s'ils ont vraiment besoin de se déconnecter, par exemple s'ils verrouillent scrupuleusement leur appareil avec un mot de passe sécurisé ou un autre mécanisme d'authentification.
- Gérer plusieurs onglets: si un utilisateur a ouvert plusieurs pages du même site Web dans différents onglets, assurez-vous que la déconnexion d'un onglet met également à jour tous les autres onglets ouverts de ce site Web.
- Rediriger vers une page de destination sécurisée: une fois la déconnexion effectuée, redirigez l'utilisateur vers une page de destination sécurisée indiquant clairement qu'il n'est plus connecté. Évitez de rediriger les utilisateurs vers des pages contenant des informations personnalisées. De même, assurez-vous que les autres onglets ne reflètent plus un état de connexion. Assurez-vous également de ne pas créer de redirection ouverte que des pirates informatiques pourraient exploiter.
- Nettoyage de la session: une fois qu'un utilisateur s'est déconnecté, supprimez complètement toutes les données sensibles de la session utilisateur, les cookies ou les fichiers temporaires associés à la session de l'utilisateur. Cela empêche tout accès non autorisé aux informations utilisateur ou à l'activité du compte, et empêche également le navigateur de restaurer les pages contenant des informations sensibles à partir de ses différents caches, en particulier du cache "Retour/Avance".
- Gestion des erreurs et commentaires: en cas de problème lors de la déconnexion, fournissez aux utilisateurs des messages d'erreur ou des commentaires clairs. Informez-les des risques de sécurité ou des fuites de données potentiels si le processus de déconnexion échoue.
- Considérations d'accessibilité: assurez-vous que le mécanisme de déconnexion est accessible aux utilisateurs handicapés, y compris ceux qui utilisent des technologies d'assistance telles que les lecteurs d'écran ou la navigation au clavier.
- Compatibilité multinavigateur: testez la fonctionnalité de déconnexion sur différents navigateurs et appareils pour vous assurer qu'elle fonctionne de manière cohérente et fiable.
- Surveillance et mises à jour continues: surveillez régulièrement le processus de déconnexion pour détecter d'éventuelles failles ou failles de sécurité. Implémentez des mises à jour et des correctifs en temps opportun pour résoudre les problèmes identifiés.
- Fédération d'identité: si l'utilisateur est connecté à l'aide d'une identité fédérée, vérifiez si la déconnexion du fournisseur d'identité est également compatible et nécessaire. De plus, si le fournisseur d'identité est compatible avec la connexion automatique, n'oubliez pas de l'empêcher.
À FAIRE
- Si vous invalidez un cookie sur le serveur dans le cadre d'un flux de déconnexion (ou d'autres flux de révocation d'accès), veillez également à supprimer le cookie sur l'appareil de l'utilisateur.
- Nettoyez toutes les données sensibles que vous avez pu stocker sur l'appareil de l'utilisateur: cookies, localStorage, sessionStorage, indexedDB, CacheStorage et tout autre magasin de données local.
- Assurez-vous que toutes les ressources contenant des données sensibles, en particulier les documents HTML, sont renvoyées avec l'en-tête HTTP
Cache-control: no-store
afin que le navigateur ne les stocke pas dans un espace de stockage permanent (par exemple, sur disque). De même, les appels XHR/fetch
qui renvoient des données sensibles doivent également définir l'en-tête HTTPCache-Control: no-store
pour éviter toute mise en cache. - Assurez-vous que les onglets ouverts sur l'appareil de l'utilisateur sont à jour avec les révocations d'accès côté serveur.
Nettoyer les données sensibles lors de la déconnexion
Lorsque vous vous déconnectez, envisagez d'effacer les données sensibles éphémères et stockées localement. L'accent mis sur les données sensibles est motivé par le fait que tout effacer entraînerait une expérience utilisateur nettement moins satisfaisante, car cet utilisateur peut très bien revenir. Par exemple, si vous effacez toutes les données stockées en local, vos utilisateurs devront à nouveau confirmer les invites de consentement aux cookies et passer par d'autres processus comme s'ils n'avaient jamais accédé à votre site Web.
Effacer les cookies
Dans la réponse de la page qui confirme l'état de déconnexion, joignez des en-têtes HTTP Set-Cookie
pour effacer tous les cookies associés à des données sensibles ou contenant des données sensibles. Définissez la valeur expires
sur une date lointaine et définissez la valeur du cookie sur une chaîne vide pour plus de sécurité.
Set-Cookie: sensitivecookie1=; expires=Thu, 01 Jan 1970 00:00:00 GMT; secure
Set-Cookie: sensitivecookie2=; expires=Thu, 01 Jan 1970 00:00:00 GMT; secure
...
Scénario hors connexion
Bien que l'approche décrite ci-dessus soit suffisante pour les cas d'utilisation généraux, elle ne fonctionne pas si l'utilisateur travaille hors connexion. Vous pouvez envisager d'exiger deux cookies pour suivre l'état de connexion: un cookie sécurisé HTTPS uniquement et un cookie standard accessible via JavaScript. Si votre utilisateur tente de se déconnecter en mode hors connexion, vous pouvez effacer le cookie JavaScript et effectuer d'autres opérations de nettoyage, si possible. Si vous disposez d'un service worker, vous pouvez également utiliser l'API Background Fetch pour réessayer une requête visant à effacer l'état sur le serveur lorsque l'utilisateur sera en ligne plus tard.
Libérer de l'espace de stockage
Dans la réponse de la page qui confirme l'état de déconnexion, veillez à nettoyer les données sensibles de divers data stores:
sessionStorage: bien que cette variable soit effacée lorsque l'utilisateur met fin à sa session sur votre site Web, envisagez de nettoyer de manière proactive les données sensibles lorsque l'utilisateur se déconnecte, au cas où il oublierait de fermer tous les onglets ouverts sur votre site Web.
// Remove sensitive data from sessionStorage sessionStorage.removeItem('sensitiveSessionData1'); // ... // Or if everything in sessionStorage is sensitive, clear it all sessionStorage.clear();
localStorage, indexedDB, API Cache/Service Worker: lorsque l'utilisateur se déconnecte, nettoyez toutes les données sensibles que vous avez peut-être stockées à l'aide de ces API, car elles persistent entre les sessions.
// Remove sensitive data from localStorage: localStorage.removeItem('sensitiveData1'); // ... // Or if everything in localStorage is sensitive, clear it all: localStorage.clear();
// Delete sensitive object stores in indexedDB: const name = 'exampleDB'; const version = 1; const request = indexedDB.open(name, version); request.onsuccess = (event) => { const db = request.result; db.deleteObjectStore('sensitiveStore1'); db.deleteObjectStore('sensitiveStore2'); // ... db.close(); }
// Delete sensitive resources stored via the Cache API: caches.open('cacheV1').then((cache) => { await cache.delete("/personal/profile.png"); // ... } // Or better yet, clear a cache bucket that contains sensitive resources: caches.delete('personalizedV1');
Vider les caches
- Cache HTTP: tant que vous définissez
Cache-control: no-store
sur les ressources contenant des données sensibles, le cache HTTP ne conserve rien de sensible. - Cache "Précédent/Suivant": de même, si vous avez suivi les recommandations concernant
Cache-control: no-store
et la suppression des cookies sensibles (par exemple, les cookies sécurisés HTTPS uniquement liés à l'authentification) lorsque les utilisateurs se déconnectent, vous n'avez pas à vous soucier de la conservation de données sensibles dans le cache "Précédent/Suivant". En effet, la fonctionnalité de cache avant/arrière supprime les pages de même origine servies avec un en-tête HTTPCache-control: no-store
si elle observe un ou plusieurs des signaux suivants :- Un ou plusieurs cookies sécurisés HTTPS uniquement ont été modifiés ou supprimés.
- Une ou plusieurs réponses pour les appels XHR/
fetch
(émises par la page) incluaient l'en-tête HTTPCache-control: no-store
.
Expérience utilisateur cohérente entre les onglets
Vos utilisateurs peuvent avoir ouvert de nombreux onglets sur votre site Web avant de décider de se déconnecter. À ce stade, il est possible qu'il ait oublié d'autres onglets, voire d'autres fenêtres de navigateur. Il est préférable de ne pas compter sur vos utilisateurs pour fermer tous les onglets et fenêtres pertinents. Adoptez plutôt une approche proactive en vous assurant que l'état de connexion de l'utilisateur est cohérent entre les onglets.
Instructions
Pour obtenir un état de connexion cohérent entre les onglets, envisagez d'utiliser une combinaison d'événements pageshow
/pagehide
et de l'API Broadcast Channel.
Événement
pageshow
: en cas depageshow
persistant, vérifiez l'état de connexion de l'utilisateur et effacez les données sensibles (ou même la page entière) si l'utilisateur n'est plus connecté. Notez que l'événementpageshow
se déclenche avant l'affichage de la page pour la première fois après sa restauration à partir d'une navigation "Retour"/"Avant", ce qui garantit que la vérification de l'état de connexion vous permettra de rétablir la page dans un état non sensible.window.addEventListener('pageshow', (event) => { if (event.persisted && !document.cookie.match(/my-cookie)) { // The user has logged out. // Force a reload, or otherwise clear sensitive information right away. body.innerHTML = ''; location.reload(); } });
API Broadcast Channel: utilisez cette API pour communiquer les modifications de l'état de connexion entre les onglets et les fenêtres. Si l'utilisateur est déconnecté, effacez toutes les données sensibles ou redirigez-le vers une page de déconnexion dans tous les onglets et fenêtres contenant des données sensibles.
// Upon logout, broadcast new login state so that other tabs can clean up too: const bc = new BroadcastChannel('login-state'); bc.postMessage('logged out'); // [...] const bc = new BroadcastChannel('login-state'); bc.onMessage = (msgevt) => { if (msgevt.data === 'logged out') { // Clean up, reload or navigate to the sign-out page. // ... } }
Conclusion
En suivant les conseils de ce document, vous pourrez concevoir une expérience de déconnexion optimale qui empêche les déconnexions involontaires et protège les informations personnelles de l'utilisateur.