Cette page a été traduite par l'API Cloud Translation.

Identifiants de session liés à l'appareil (DBSC)

Les identifiants de session liés à l'appareil renforcent l'authentification en ajoutant une sécurité de session basée sur le matériel.

Daniel Rubery

José Luis Zapata

Introduction

De nombreux sites Web s'appuient sur des cookies de longue durée pour authentifier les utilisateurs, mais ceux-ci sont susceptibles d'être détournés. Les identifiants de session liés à l'appareil (DBSC) ajoutent une couche de sécurité matérielle pour atténuer ce risque, en veillant à ce que les sessions soient liées à des appareils spécifiques.

Ce guide est destiné aux développeurs qui gèrent les flux d'authentification dans les applications Web. Il explique comment fonctionne DBSC et comment l'intégrer à votre site.

Fonctionnement de DBSC

De manière générale, DBSC introduit une paire de clés cryptographiques associée à l'appareil de l'utilisateur. Chrome génère cette paire de clés lors de la connexion et stocke la clé privée dans un matériel sécurisé, tel qu'un Trusted Platform Module (TPM), lorsqu'il est disponible. Les sessions utilisent des cookies de courte durée. Lorsqu'un de ces cookies expire, Chrome prouve qu'il possède la clé privée avant de les actualiser. Ce processus associe la continuité de session à l'appareil d'origine.

Si l'appareil d'un utilisateur n'est pas compatible avec le stockage sécurisé des clés, DBSC revient au comportement standard sans interrompre le flux d'authentification.

Présentation de l'implémentation

Pour intégrer DBSC à votre application, vous devez apporter les modifications suivantes :

Modifiez votre flux de connexion pour inclure un en-tête Secure-Session-Registration.
Ajoutez un point de terminaison d'enregistrement de session qui :
- Associe une clé publique à la session de l'utilisateur.
- Diffuser la configuration de la session.
- Transition vers des cookies de courte durée.
Ajoutez un point de terminaison d'actualisation pour gérer le renouvellement des cookies et la validation de la possession des clés.

La plupart de vos points de terminaison existants ne nécessitent aucune modification. Le DBSC est conçu pour être additif et non perturbateur.

Lorsqu'un cookie éphémère requis est manquant ou a expiré, Chrome met la requête en pause et tente d'actualiser le cookie. Cela permet à votre application de continuer à utiliser ses vérifications habituelles des cookies de session pour confirmer que l'utilisateur est connecté. Comme cela correspond aux flux d'authentification classiques, DBSC fonctionne avec des modifications minimes de votre logique de connexion.

Étapes de mise en œuvre

Cette section décrit les modifications nécessaires à apporter à votre système d'authentification, y compris comment modifier votre parcours de connexion, gérer l'enregistrement des sessions et gérer les actualisations des cookies de courte durée. Chaque étape est conçue pour s'intégrer facilement à votre infrastructure existante.

Les étapes d'implémentation suivent le flux commun qu'un utilisateur connecté rencontre lorsque DBSC est actif : l'enregistrement à la connexion, suivi d'actualisations régulières de cookies de courte durée. Vous pouvez tester et implémenter chaque étape indépendamment, en fonction du niveau de sensibilité aux sessions de votre application.

Schéma illustrant le flux DBSC

1. Modifier le flux de connexion

Une fois que l'utilisateur s'est connecté, répondez avec un cookie de longue durée et un en-tête Secure-Session-Registration. Exemple :

L'en-tête de réponse HTTP suivant est renvoyé après l'enregistrement réussi de la session :

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Si l'appareil est compatible avec le stockage sécurisé de clés, Chrome contacte le point de terminaison /StartSession avec une clé publique dans un jeton Web JSON (JWT).

Dans cet exemple, auth_cookie représente votre jeton de session. Vous pouvez nommer ce cookie comme vous le souhaitez, à condition qu'il corresponde au champ name de votre configuration de session et qu'il soit utilisé de manière cohérente dans toute votre application.

2. Implémenter le point de terminaison d'enregistrement de session

À l'étape /StartSession, votre serveur doit :

Associez la clé publique reçue à la session de l'utilisateur.
Répondez avec une configuration de session.
Remplacez le cookie à longue durée de vie par un cookie à courte durée de vie.

Dans l'exemple suivant, le cookie éphémère est configuré pour expirer au bout de 10 minutes :

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Implémenter le point de terminaison d'actualisation

Lorsque le cookie éphémère expire, Chrome lance un flux d'actualisation pour prouver la possession de la clé privée. Ce processus implique des actions coordonnées de la part de Chrome et de votre serveur :

Chrome transfère la demande de l'utilisateur à votre application et envoie une demande d'actualisation à /RefreshEndpoint :
```
POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id
```

Votre serveur répond par un défi :

HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "challenge_value"

Chrome signe le challenge à l'aide de la clé privée stockée et relance la requête :

POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id
Secure-Session-Response: <JWT proof>

Votre serveur valide la preuve signée et émet un cookie éphémère actualisé :

HTTP/1.1 200 OK

Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

Chrome reçoit le cookie actualisé et reprend la requête différée d'origine.

Autre modèle d'intégration

Pour améliorer la résilience, les sites peuvent ajouter un deuxième cookie non DBSC en plus du cookie à courte durée de vie. Ce cookie de longue durée n'est utilisé que pour émettre de nouveaux jetons de courte durée et permet de faire la distinction entre les requêtes réellement non authentifiées et les échecs temporaires de DBSC.

Le cookie de longue durée persiste même en cas d'échec de DBSC.
Le cookie de courte durée est actualisé à l'aide de DBSC et est requis pour les opérations sensibles.

Ce modèle permet aux sites de mieux contrôler la manière de gérer les cas extrêmes.

Précisions et comportement de remplacement

Dans les scénarios suivants, il est possible que Chrome ignore les opérations DBSC et envoie des requêtes sans le cookie éphémère géré par DBSC :

Le point de terminaison d'actualisation est inaccessible en raison d'erreurs réseau ou de problèmes de serveur.
Le TPM est occupé ou rencontre des erreurs de signature. Étant donné que le module TPM est partagé entre les processus système, un nombre excessif d'actualisations peut dépasser ses limites de fréquence.
Le cookie éphémère géré par le DBSC est un cookie tiers, et l'utilisateur a bloqué les cookies tiers dans les paramètres de son navigateur.

Dans ce cas, Chrome utilise le cookie de longue durée s'il est toujours présent. Cette solution de secours ne fonctionne que si votre implémentation inclut à la fois un cookie de longue durée et un cookie de courte durée. Si ce n'est pas le cas, Chrome envoie la requête sans cookie.

Résumé

Les identifiants de session liés à l'appareil améliorent la sécurité des sessions avec un minimum de modifications apportées à votre application. Elles offrent une meilleure protection contre le piratage de session en associant les sessions à des appareils spécifiques. La plupart des utilisateurs en bénéficient sans subir d'interruption, et les identifiants de session liés à l'appareil sont désactivés en douceur sur le matériel non compatible.

Pour en savoir plus, consultez la spécification DBSC.