Comment gérer le blocage des cookies tiers dans les navigateurs

De nombreux navigateurs bloquent les cookies tiers et les cookies sur les requêtes adressées à des domaines autres que le domaine indiqué dans la barre d’adresse du navigateur. Ces cookies sont également appelés cookies inter-domaines. Ce bloc rompt le flux implicite et nécessite de nouveaux modèles d’authentification pour la connexion des utilisateurs. Dans la plateforme d’identité Microsoft, nous utilisons le flux d’autorisation avec Proof Key for Code Exchange (PKCE), et actualisons les jetons pour maintenir les utilisateurs connectés quand des cookies tiers sont bloqués.

Qu’est-ce que l’Intelligent Tracking Protection (ITP) et la Privacy Sandbox ?

Apple Safari intègre une fonctionnalité de protection de la confidentialité activée par défaut, nommée protection intelligente contre le tracking ou ITP (Intelligent Tracking Protection). Chrome a lancé une initiative de confidentialité des navigateurs nommée Privacy Sandbox. Ces initiatives englobent de nombreux efforts de confidentialité des navigateurs et ont différentes chronologies. Les deux initiatives bloquent les cookies « tiers » sur les demandes qui traversent des domaines, Safari et Brave bloquant les cookies tiers par défaut. Chrome a récemment annoncé le blocage prochain des cookies tiers par défaut. Privacy Sandbox inclut des modifications apportées au stockage partitionné ainsi qu’au blocage des cookies tiers.

Une forme courante de tracking, ou suivi, de l’utilisateur consiste à charger un iframe sur un site tiers en arrière-plan, et à utiliser des cookies pour mettre en corrélation l’utilisateur sur Internet. Malheureusement, ce modèle est également la manière standard d’implémenter le flux implicite dans des applications monopages. Un navigateur qui bloque les cookies tiers pour protéger la confidentialité des utilisateurs peut également bloquer les fonctionnalités d’une application monopage.

La solution décrite dans cet article fonctionne dans tous ces navigateurs, ou partout où des cookies tiers sont bloqués.

Vue d’ensemble de la solution

Pour continuer à authentifier les utilisateurs dans des applications monopages, les développeurs d’applications doivent utiliser le flux de code d’autorisation. Dans le flux de code d’authentification, le fournisseur d’identité émet un code, et l’application monopage échange le code contre un jeton d’accès et un jeton d’actualisation. Lorsque l’application requiert des jetons supplémentaires, elle peut utiliser le flux de jetons d’actualisation pour obtenir de nouveaux jetons. Microsoft Authentication Library (MSAL) pour JavaScript v2.0, et versions ultérieures, implémente le flux de code d’autorisation pour les applications monopage et, moyennant des mises à jour mineures, peut remplacer MSAL.js 1.x instantanément. Consultez le guide de migration pour déplacer une application monopage d’un flux de code implicite vers un flux de code d’authentification.

Pour la plateforme d’identité Microsoft, les applications monopages et les clients natifs suivent des recommandations de protocole similaires :

• Utilisation d’une vérification de code PKCE
  • PKCE est requis pour les applications monopages sur la plateforme d’identité Microsoft. PKCE est recommandé pour les clients natifs et confidentiels.
• Pas d’utilisation de clé secrète client

Les SPA ont deux autres restrictions :

• L’URI de redirection doit être marqué en tant que type spa pour activer CORS sur les points de terminaison de connexion.
• Les jetons d’actualisation émis via le flux de code d’autorisation vers les URI de redirection spa ont une durée de vie de 24 heures au lieu de 90 jours.

Implications sur les performances et l’expérience utilisateur

Certaines applications utilisant le flux implicite tentent de se connecter sans effectuer de redirection en ouvrant un iframe de connexion à l’aide de prompt=none. Dans la plupart des navigateurs, cette requête répond avec des jetons pour l’utilisateur actuellement connecté (en supposant que le consentement est octroyé). Ce modèle signifie que les applications n’ont pas besoin d’une redirection de page complète pour connecter l’utilisateur, ce qui améliore les performances et l’expérience utilisateur, car l’utilisateur visitant la page web et est déjà connecté. Étant donné que prompt=none dans un iframe n’est plus une option lorsque des cookies tiers sont bloqués, les applications doivent adapter leurs modèles de connexion pour qu’un code d’autorisation soit émis.

Sans cookies tiers, il existe deux façons de réaliser la connexion :

• Redirections de page complète
  • Lors du premier chargement de l’application monopage, rediriger l’utilisateur vers la page de connexion s’il n’existe aucune session (ou si la session a expiré). Le navigateur de l’utilisateur accède à la page de connexion, présente les cookies contenant la session utilisateur, puis est redirigé vers l’application avec le code et les jetons dans un fragment.
  • La redirection a pour effet que l’application monopage est chargée deux fois. Suivez les meilleures pratiques de mise en cache des applications monopages afin que l’application ne soit pas entièrement téléchargée deux fois.
  • Songez à instaurer une séquence de préchargement dans l’application, qui vérifie l’existence d’une session de connexion et redirige vers la page de connexion avant que l’application décompresse et exécute entièrement la charge utile JavaScript.
• Fenêtres contextuelles
  • Si l’expérience utilisateur (UX) d’une redirection de page complète ne fonctionne pas pour l’application, envisagez d’utiliser une fenêtre contextuelle pour gérer l’authentification.
  • Quand la fenêtre contextuelle achève la redirection vers l’application après l’authentification, le code dans le gestionnaire de redirection stocke le code d’authentification et les jetons dans un stockage local à l’usage de l’application. MSAL.js prend en charge les fenêtres contextuelles pour l’authentification, comme la plupart des bibliothèques.
  • Les navigateurs réduisant la prise en charge des fenêtres contextuelles, ils pourraient ne pas être l’option la plus fiable. Une interaction utilisateur avec l’application monopage avant la création de la fenêtre contextuelle pourrait être nécessaire pour répondre aux besoins du navigateur.

Apple décrit une méthode de fenêtre contextuelle comme étant un correctif de compatibilité temporaire pour donner à la fenêtre d’origine l’accès à des cookies tiers. Si Apple peut supprimer ce transfert d’autorisations à l’avenir, cela n’aura pas d’incidence sur les conseils prodigués ici.

Ici, la fenêtre contextuelle est utilisée en tant que vecteur de navigation interne vers la page de connexion afin qu’une session soit trouvée et qu’un code d’authentification puisse être fourni. Cela devrait continuer à fonctionner à l’avenir.

Les développeurs peuvent continuer à utiliser prompt=none en s’attendant à constater un taux plus élevé d’erreurs interaction_required lorsque des cookies tiers sont bloqués. Nous vous suggérons d’avoir toujours une méthode interactive de secours, si des échecs se produisent lors de l’acquisition silencieuse de jeton.

Utilisation d’iframes

Un modèle courant dans les applications web consiste à utiliser un iframe pour incorporer une application dans une autre : le frame de niveau supérieur gère l’authentification de l’utilisateur et l’application hébergée dans l’iframe peut confirmer que l’utilisateur est connecté, en extrayant les jetons en mode silencieux à l’aide du flux implicite. Toutefois, il existe quelques mises en garde pour cette hypothèse—que les cookies tiers soient activés ou bloqués dans le navigateur.

L’acquisition silencieuse de jeton ne fonctionne plus quand les cookies tiers sont bloqués. L’application incorporée dans l’iframe doit basculer vers l’utilisation de fenêtres contextuelles pour accéder à la session de l’utilisateur, car elle ne peut pas accéder à la page de connexion dans un cadre incorporé.

Vous pouvez obtenir l’authentification unique entre les applications en iframe et parentes avec l’accès de l’API de script JavaScript cross-origin et same-origin en passant un indicateur d’utilisateur (compte) de l’application parente à l’application en iframe. Pour plus d’informations, consultez Utilisation de MSAL.js dans des applications en iframe dans le référentiel MSAL.js sur GitHub.

Implications pour la sécurité des jetons d’actualisation dans le navigateur

Des attaques par scripts de site à site ou des packages JS compromis peuvent voler un jeton d’actualisation et l’utiliser à distance jusqu’à ce qu’il expire ou soit révoqué. Les développeurs d’applications sont responsables de la réduction du risque d’écriture de scripts intersites de leur application. Afin de réduire le risque de vol de jetons d’actualisation, les jetons émis pour les applications monopages ont une durée de vie de seulement 24 heures. Après 24 heures, l’application doit acquérir un nouveau code d’autorisation en visitant la page de connexion via un cadre de niveau supérieur.

Ce modèle de jeton d’actualisation à durée de vie limitée a été choisi en tant que un compromis entre la sécurité et une expérience utilisateur dégradée. À défaut de jetons d’actualisation ou de cookies tiers, le flux de code d’autorisation (tel que recommandé par le projet des meilleures pratiques actuelles de sécurité OAuth) devient onéreux quand de nouveaux jetons ou des jetons supplémentaires sont requis. Une redirection de page complète ou une fenêtre contextuelle est requise pour chaque jeton, chaque fois qu’un jeton expire (généralement toutes les heures pour les jetons de la plateforme d’identités Microsoft).

Atténuations des risques spécifiques au type d’utilisateur

Tous les utilisateurs et toutes les applications ne sont pas affectés de la même manière par les cookies tiers. Il existe certains scénarios où, en raison de l’architecture ou de la gestion des appareils, des appels silencieux pour renouveler des jetons peuvent être effectués sans cookies tiers.

Pour des scénarios d’appareils d’entreprise managés, certaines combinaisons de navigateur et de plateforme prennent en charge l’accès conditionnel d’appareil. Appliquer l’identité de l’appareil réduit le besoin de cookies tiers, car l’état d’authentification peut provenir de l’appareil au lieu du navigateur.

Pour les scénarios d’application Azure AD B2C, les clients peuvent configurer un domaine de connexion personnalisé pour correspondre au domaine de l’application. Les navigateurs ne bloquent pas les cookies tiers dans ce scénario, car les cookies restent dans le même domaine (par exemple, login.contoso.com à app.contoso.com).

Limitations sur la déconnexion front-channel sans cookies tiers

Lors de la déconnexion d’un utilisateur d’une application monopage, MSAL.js recommande d’utiliser la méthode de déconnexion contextuelle ou de redirection. Bien que cela efface la session d’authentification sur le serveur et dans le stockage du navigateur, il existe un risque que, sans accès aux cookies tiers, les applications fédérées ne voient pas une déconnexion toutes en même temps. Il s’agit d’une limitation connue de la spécification OpenID Front-Channel Logout 1.0. Pour les utilisateurs, cela signifie que les jetons d’accès existants pour d’autres applications et pour le même utilisateur continueront d’être valides jusqu’à leur heure d’expiration. Un utilisateur peut se déconnecter de l’application A dans l’onglet A, mais l’application B dans l’onglet B s’affiche toujours comme connectée pour le temps de validité restant du jeton d’accès. Lorsque le jeton de l’application B expire et qu’un appel est effectué au serveur pour obtenir un nouveau jeton, l’application B reçoit comme réponse du serveur que la session a expiré et invite l’utilisateur à s’authentifier.

La page de déconnexion de Microsoft et les meilleures pratiques de confidentialité Internet recommandent aux utilisateurs de fermer toutes les fenêtres de navigateur après s’être déconnecté d’une application.

Étapes suivantes

Pour plus d’informations sur MSAL.js et le flux de code d’autorisation, consultez :

• Flux du code d’autorisation.
• MSAL.js 2.0 quickstart.