Las credenciales de sesión vinculadas al dispositivo (DBSC) fortalecen la autenticación, ya que agregan seguridad de sesión respaldada por hardware.
Introducción
Muchos sitios web dependen de cookies de larga duración para la autenticación de usuarios, pero estas son susceptibles al secuestro de sesiones. Las credenciales de sesión vinculadas al dispositivo (DBSC) agregan una capa de seguridad respaldada por hardware para mitigar este riesgo, lo que garantiza que las sesiones estén vinculadas a dispositivos específicos.
Esta guía está dirigida a los 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 términos generales, el DBSC introduce un par de claves criptográficas asociadas 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 segura (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 actualizarla. Este proceso vincula la continuidad de la sesión al dispositivo original.
Si el dispositivo de un usuario no admite el almacenamiento seguro de claves, la DBSC recurre de forma correcta 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
Secure-Session-Registration. - Agrega un extremo de registro de sesión que haga lo siguiente:
- Asocia una clave pública con la sesión del usuario.
- Publica la configuración de la sesión.
- Se realizan 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 endpoints 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 esta venció, Chrome pausa la solicitud y trata de actualizar la cookie. Esto permite que tu app siga usando sus verificaciones habituales de cookies de sesión para confirmar que el usuario accedió. Dado que coincide con los flujos de autenticación típicos, DBSC funciona con cambios mínimos en tu lógica de acceso.
Pasos de implementación
En esta sección, se explican los cambios necesarios en tu sistema de autenticación, incluido cómo modificar tu flujo de acceso, controlar el registro de sesiones y administrar las actualizaciones de cookies de corta duración. Cada paso está diseñado para integrarse sin problemas en tu infraestructura existente.
Los pasos de implementación siguen el flujo común que experimentaría un usuario que accedió a su cuenta cuando DBSC está activo: registro al acceder, seguido de actualizaciones periódicas 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 acceda, responde con una cookie de larga duración y un encabezado Secure-Session-Registration. Por ejemplo:
El siguiente encabezado de respuesta HTTP se muestra después del registro correcto de la sesión:
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 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 darle a esta cookie el nombre que quieras, siempre y cuando coincida con el campo name en la configuración de tu 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 está configurada 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 minutes Set-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 tanto de Chrome como de tu servidor:
Chrome difiere la solicitud del usuario a tu aplicación y envía una solicitud de actualización a
/RefreshEndpoint:POST /RefreshEndpoint HTTP/1.1 Sec-Secure-Session-Id: session_idTu servidor responde con un desafío:
HTTP/1.1 403 Forbidden Secure-Session-Challenge: "challenge_value"Chrome firma el desafío con la clave privada almacenada y vuelve a intentar la solicitud:
POST /RefreshEndpoint HTTP/1.1 Sec-Secure-Session-Id: session_id Secure-Session-Response: <JWT proof>Tu servidor valida la prueba firmada y emite una cookie actualizada de corta duración:
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=LaxChrome 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 se usa solo para emitir tokens nuevos de corta duración y ayuda a distinguir entre las solicitudes verdaderamente no autenticadas y las fallas temporales del DBSC.
- La cookie de larga duración persiste incluso si falla 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 controlar los casos extremos.
Advertencias y comportamiento de resguardo
En los siguientes casos, es posible que Chrome omita las operaciones de DBSC y envíe solicitudes sin la cookie de corta duración administrada por DBSC:
- No se puede acceder al extremo de actualización debido a errores de red o problemas del servidor.
- El TPM está ocupado o encuentra errores de firma. Dado que el TPM se comparte entre los procesos del sistema, las actualizaciones excesivas pueden superar sus límites de velocidad.
- La cookie de corta duración administrada por el DBSC es una cookie de terceros, y el usuario bloqueó las cookies de terceros en la configuración del navegador.
En estas situaciones, Chrome recurre al uso de la cookie de larga duración si aún está presente. Esta alternativa 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 una mayor protección contra el secuestro de sesiones, ya que vinculan las sesiones a dispositivos específicos. La mayoría de los usuarios se benefician sin experimentar interrupciones, y DBSC recurre a un hardware no compatible de forma correcta.
Para obtener más información, consulta la especificación de DBSC.