Qu'est-ce qui fait une bonne expérience de déconnexion ?

Kenji Baheux

Lorsqu'un utilisateur se déconnecte d'un site Web, il indique qu'il souhaite quitter complètement une expérience utilisateur personnalisée. Il est donc important de respecter au mieux le modèle mental de l'utilisateur. Par exemple, une expérience de déconnexion appropriée doit également tenir compte des onglets que l'utilisateur a pu ouvrir avant de décider de se déconnecter.

Pour offrir une excellente expérience de déconnexion, il est essentiel d'être cohérent en termes d'aspect visuel et d'état de l'expérience utilisateur. Ce guide fournit des conseils concrets sur les éléments à prendre en compte et sur la façon d'offrir une bonne expérience de déconnexion.

Remarques importantes

Lorsque vous implémentez la fonctionnalité de déconnexion sur votre site Web, faites attention aux aspects suivants pour garantir un processus de déconnexion fluide, sécurisé et intuitif :

Expérience utilisateur de déconnexion claire et cohérente : fournissez un bouton ou un lien de déconnexion clair et visible de manière cohérente, 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 obscurs, des sous-pages ou d'autres emplacements peu intuitifs.
Invite de confirmation : implémentez une invite de confirmation avant de finaliser la procédure de déconnexion. Cela peut empêcher les utilisateurs de se déconnecter accidentellement et leur permettre de réfléchir à nouveau s'ils ont vraiment besoin de se déconnecter, par exemple s'ils verrouillent soigneusement leur appareil avec un mot de passe complexe 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.
Redirigez l'utilisateur 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 qui indique 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 n'indiquent plus que vous êtes connecté. Assurez-vous également de ne pas créer de redirection ouverte dont les pirates informatiques pourraient profiter.
Nettoyage de la session : une fois qu'un utilisateur s'est déconnecté, supprimez complètement toutes les données de session sensibles, les cookies ou les fichiers temporaires associés à la session de l'utilisateur. Cela empêche l'accès non autorisé aux informations utilisateur ou à l'activité du compte. Cela empêche également le navigateur de restaurer les pages contenant des informations sensibles à partir de ses différents caches, en particulier le cache Précédent/Suivant.
Gestion des erreurs et commentaires : fournissez des messages d'erreur ou des commentaires clairs aux utilisateurs en cas de problème lors de la déconnexion. Informez-le de tout risque de sécurité ou fuite de données potentiels si le processus de déconnexion échoue.
Considérations relatives à l'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 comme les lecteurs d'écran ou la navigation au clavier.
Compatibilité entre navigateurs : 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 les éventuelles failles ou lacunes de sécurité. Appliquez des mises à jour et des correctifs en temps voulu 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 prise en charge 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 processus de déconnexion (ou d'autres processus de révocation d'accès), assurez-vous de supprimer également 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 de manière permanente (par exemple, sur le disque). De même, les appels XHR/fetch qui renvoient des données sensibles doivent également définir l'en-tête HTTP Cache-Control: no-store pour empêcher la mise en cache.
Assurez-vous que tous les onglets ouverts sur l'appareil de l'utilisateur sont à jour en ce qui concerne les révocations d'accès côté serveur.

Nettoyer les données sensibles lors de la déconnexion

Lorsque vous vous déconnectez, pensez à 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 bonne, 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 accepter les invites de consentement pour les cookies et effectuer d'autres processus comme s'ils n'avaient jamais visité votre site Web.

Nettoyer les cookies

Dans la réponse de la page qui confirme l'état déconnecté, ajoutez des en-têtes HTTP Set-Cookie pour effacer tous les cookies associés à des données sensibles ou qui en contiennent. Définissez la valeur expires sur une date très ancienne et, par précaution, définissez la valeur du cookie sur une chaîne vide.

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

L'approche décrite ci-dessus est suffisante pour les cas d'utilisation généraux, mais 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é de type HTTPS uniquement et un cookie normal accessible via JavaScript. Si votre utilisateur essaie 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 tirer parti de l'API Background Fetch pour réessayer d'envoyer une requête afin d'effacer l'état sur le serveur lorsque l'utilisateur sera de nouveau en ligne.

Nettoyer l'espace de stockage

Dans la réponse de la page qui confirme l'état déconnecté, veillez à nettoyer les données sensibles de différents data stores :

sessionStorage : bien que cette option soit effacée lorsque l'utilisateur met fin à sa session sur votre site Web, pensez à nettoyer de manière proactive les données sensibles lorsqu'il 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, Cache/Service Worker APIs : lorsque l'utilisateur se déconnecte, supprimez toutes les données sensibles que vous avez pu stocker à l'aide de ces API, car ces données persisteraient d'une session à l'autre.

// 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 with 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');

Nettoyer 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 aucune information 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 des données sensibles dans le cache Précédent/Suivant. En effet, la fonctionnalité de cache amélioré supprime les pages de même origine servies avec un en-tête HTTP Cache-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 émis par la page incluaient l'en-tête HTTP Cache-control: no-store.

Expérience utilisateur cohérente dans les différents onglets

Il est possible que vos utilisateurs aient ouvert de nombreux onglets pour votre site Web avant de décider de se déconnecter. Entre-temps, il aura peut-être oublié les autres onglets, voire les autres fenêtres du navigateur. Il est préférable d'éviter de demander à vos utilisateurs de fermer tous les onglets et fenêtres concernés. Au lieu de cela, adoptez une approche proactive en vous assurant que l'état de connexion de l'utilisateur est cohérent dans tous les onglets.

Instructions

Pour obtenir un état de connexion cohérent dans tous les onglets, envisagez d'utiliser une combinaison d'événements pageshow/pagehide et de l'API Broadcast Channel.

Événement pageshow : lors d'un pageshow persistant, vérifiez l'état de connexion de l'utilisateur et effacez les données sensibles (voire la page entière) si l'utilisateur n'est plus connecté. L'événement pageshow se déclenchera avant le premier rendu de la page lors de sa restauration à partir d'une navigation en arrière/en avant. Votre vérification de l'état de connexion vous permettra ainsi de réinitialiser la page à 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 changements d'é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 excellente expérience utilisateur de déconnexion qui empêche les déconnexions involontaires et protège les informations personnelles de l'utilisateur.