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

Identifiants de session liés à l'appareil (DBSC)
Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Les identifiants de session liés à l'appareil (DBSC) 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 persistants pour l'authentification des 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 le fonctionnement de la fonctionnalité et comment l'intégrer à votre site.

Fonctionnement des identifiants de session basés sur l'appareil

De manière générale, le 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 sur un matériel sécurisé, tel qu'un module de plate-forme sécurisée (TPM), le cas échéant. Les sessions utilisent des cookies de courte durée. Lorsqu'un de ces cookies expire, Chrome prouve qu'il est en possession de la clé privée avant de les actualiser. Ce processus associe la continuité de la 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 de manière élégante 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 Sec-Session-Registration.
Ajoutez un point de terminaison d'enregistrement de session qui :
- Associe une clé publique à la session de l'utilisateur.
- Fournit la configuration de la session.
- Transitions vers des cookies éphémères.
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 obligatoire est manquant ou expiré, Chrome met en pause la requête et tente de mettre à jour 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 typiques, DBSC fonctionne avec des modifications minimales de votre logique de connexion.

Étapes de mise en œuvre

Cette section explique les modifications nécessaires à apporter à votre système d'authentification, y compris comment modifier votre flux de connexion, gérer l'enregistrement de la session et gérer les actualisations de 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 d'un utilisateur connecté lorsque le DBSC est actif: enregistrement lors de la connexion, suivi de rafraîchissements réguliers de cookies de courte durée. Vous pouvez tester et implémenter chaque étape indépendamment, en fonction du niveau de sensibilité des sessions de votre application.

Schéma illustrant le flux DBSC

1. Modifier le flux de connexion

Une fois que l'utilisateur se connecte, répondez avec un cookie durable et un en-tête Sec-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
Sec-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é des 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 l'ensemble de votre application.

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

À /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 de longue durée par un cookie de courte durée.

Dans l'exemple suivant, le cookie de courte durée 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 de courte durée 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 diffère la requête de l'utilisateur vers votre application et envoie une requête de rafraîchissement à /RefreshEndpoint:
```
POST /RefreshEndpoint HTTP/1.1
Sec-Session-Id: session_id
```

Votre serveur répond avec un défi:

HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "challenge_value"

Chrome signe le défi à l'aide de la clé privée stockée et réessaie la requête:

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

Votre serveur valide la preuve signée et émet un cookie à durée de vie courte 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.

Modèle d'intégration alternatif

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

Le cookie de longue durée persiste même en cas d'échec de la 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 gestion des cas particuliers.

Précisions et comportement de remplacement

Chrome peut ignorer les opérations DBSC et envoyer des requêtes sans le cookie de courte durée géré par DBSC dans les scénarios suivants:

Le point de terminaison de l'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 TPM est partagé entre les processus système, des actualisations excessives peuvent dépasser ses limites de débit.
Le cookie de courte durée 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. Ce remplacement 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 des modifications minimales apportées à votre application. Elles offrent une protection plus efficace contre le piratage de session en associant les sessions à des appareils spécifiques. La plupart des utilisateurs en bénéficient sans aucune interruption, et le DBSC revient de manière fluide sur le matériel non compatible.

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