Credenciales de sesión vinculadas al dispositivo (DBSC)

bookmark_border Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Las credenciales de sesión vinculadas al dispositivo (DBSC) fortalecen la autenticación, ya que agregan seguridad de la sesión respaldada por hardware.

Daniel Rubery

José Luis Zapata

Introducción

Muchos sitios web dependen de cookies de larga duración para la autenticación de usuarios, pero estas son susceptibles al robo de sesión. Las credenciales de sesión vinculadas al dispositivo (DBSC) agregan una capa de seguridad respaldada por hardware para mitigar este riesgo y garantizar que las sesiones estén vinculadas a dispositivos específicos.

Esta guía está dirigida a desarrolladores que mantienen flujos de autenticación en aplicaciones web. En él, se explica cómo funciona el DBSC y cómo integrarlo en tu sitio.

Cómo funciona DBSC

En un nivel alto, la DBSC presenta un par de claves criptográfica asociado con el dispositivo del usuario. Chrome genera este par de claves durante el acceso y almacena la clave privada en hardware seguro, como un módulo de plataforma de confianza (TPM), cuando está disponible. Las sesiones usan cookies de corta duración. Cuando vence una de estas cookies, Chrome demuestra la posesión de la clave privada antes de actualizarlas. Este proceso vincula la continuidad de la sesión al dispositivo original.

Si el dispositivo de un usuario no admite el almacenamiento de claves seguro, las DBSC vuelven de forma fluida al comportamiento estándar sin interrumpir el flujo de autenticación.

Descripción general de la implementación

Para integrar DBSC en tu aplicación, debes realizar los siguientes cambios:

• Modifica tu flujo de acceso para incluir un encabezado Sec-Session-Registration.
• Agrega un extremo de registro de sesión que cumpla con los siguientes requisitos:
  • Asocia una clave pública con la sesión del usuario.
  • Publica la configuración de la sesión.
  • Transiciones a cookies de corta duración
• Agrega un extremo de actualización para controlar la renovación de cookies y la validación de posesión de claves.

La mayoría de tus extremos existentes no requieren ningún cambio. El DBSC está diseñado para ser aditivo y no disruptivo.

Cuando falta una cookie de corta duración obligatoria o está vencida, Chrome pausa la solicitud y trata de actualizarla. Esto permite que tu app siga usando sus verificaciones habituales de cookies de sesión para confirmar que el usuario accedió. Dado que esto coincide con los flujos de autenticación típicos, la DBSC funciona con cambios mínimos en la lógica de acceso.

Pasos de implementación

En esta sección, se describen los cambios necesarios en tu sistema de autenticación, como modificar el flujo de acceso, controlar el registro de la sesión y administrar las actualizaciones de cookies de corta duración. Cada paso está diseñado para integrarse sin problemas con tu infraestructura existente.

Los pasos de implementación siguen el flujo común que experimentaría un usuario que accedió cuando el DBSC está activo: registro en el acceso, seguido de actualizaciones regulares de cookies de corta duración. Puedes probar e implementar cada paso de forma independiente, según el nivel de sensibilidad de la sesión de tu app.

1. Modifica el flujo de acceso

Después de que el usuario accede, responde con una cookie de larga duración y un encabezado Sec-Session-Registration. Por ejemplo:

Se muestra el siguiente encabezado de respuesta HTTP después de que se registra correctamente la sesión:

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 el dispositivo admite el almacenamiento seguro de claves, Chrome se comunica con el extremo /StartSession con una clave pública en un token web JSON (JWT).

El auth_cookie en este ejemplo representa tu token de sesión. Puedes asignarle el nombre que desees a esta cookie, siempre que coincida con el campo name en la configuración de la sesión y se use de forma coherente en toda la aplicación.

2. Implementa el extremo de registro de sesión

En /StartSession, tu servidor debe hacer lo siguiente:

• Asocia la clave pública recibida con la sesión del usuario.
• Responde con una configuración de sesión.
• Reemplaza la cookie de larga duración por una de corta duración.

En el siguiente ejemplo, la cookie de corta duración se configura para que venza después de 10 minutos:

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. Implementa el extremo de actualización

Cuando vence la cookie de corta duración, Chrome inicia un flujo de actualización para demostrar la posesión de la clave privada. Este proceso implica acciones coordinadas de Chrome y tu servidor:

1. Chrome aplaza la solicitud del usuario a tu aplicación y envía una solicitud de actualización a /RefreshEndpoint:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   

2. Tu servidor responde con un desafío:

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

3. Chrome firma el desafío con la clave privada almacenada y vuelve a intentar la solicitud:

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

4. Tu servidor valida la prueba firmada y emite una cookie de corta duración actualizada:

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

5. Chrome recibe la cookie actualizada y reanuda la solicitud diferida original.

Patrón de integración alternativo

Para mejorar la resiliencia, los sitios pueden agregar una segunda cookie que no sea de DBSC junto con la cookie de corta duración. Esta cookie de larga duración solo se usa para emitir nuevos tokens de corta duración y ayuda a distinguir entre solicitudes realmente no autenticadas y fallas temporales de DBSC.

• La cookie de larga duración persiste incluso si falla el DBSC.
• La cookie de corta duración se actualiza con DBSC y es obligatoria para las operaciones sensibles.

Este patrón les brinda a los sitios más control sobre cómo manejar los casos extremos.

Advertencias y comportamiento de resguardo

Chrome puede omitir las operaciones de DBSC y enviar solicitudes sin la cookie de corta duración administrada por DBSC en las siguientes situaciones:

• No se puede acceder al extremo de actualización debido a errores de red o del servidor.
• El TPM está ocupado o encuentra errores de firma. Debido a que el TPM se comparte entre los procesos del sistema, las actualizaciones excesivas pueden exceder sus límites de frecuencia.
• La cookie de corta duración administrada por DBSC es una cookie de terceros, y el usuario bloqueó las cookies de terceros en la configuración de su navegador.

En estas situaciones, Chrome vuelve a usar la cookie de larga duración si aún hay una. Este resguardo solo funciona si tu implementación incluye una cookie de larga duración y una de corta duración. De lo contrario, Chrome envía la solicitud sin una cookie.

Resumen

Las credenciales de sesión vinculadas al dispositivo mejoran la seguridad de la sesión con cambios mínimos en tu aplicación. Proporcionan protecciones más sólidas contra el secuestro de sesión, ya que vinculan las sesiones a dispositivos específicos. La mayoría de los usuarios se benefician sin experimentar ninguna interrupción, y el DBSC recurre de forma fluida al hardware no compatible.

Para obtener más información, consulta la especificación de DBSC.