A todos nos encanta que las aplicaciones nativas te pedirán que accedas solo una vez y, luego, te recuerden hasta que les digas que quieres salir. Desafortunadamente, la Web no siempre funciona así.
Ahora que los dispositivos, en especial los dispositivos móviles, son más personales, y con una mayor cantidad de sitios que envían todo el tráfico a través de HTTPS para reducir el riesgo de robo de tokens, los sitios web deberían reconsiderar sus políticas de cookies de corta duración y adoptar sesiones de mayor duración más fáciles de usar.
Sin embargo, incluso si quieres que la sesión dure más, algunos sitios web no verifican la autenticación del usuario en cada solicitud (en otras palabras, no se puede revocar la cookie de sesión una vez que se emite). Por lo general, esto genera sesiones cortas, ya que el usuario se ve obligado a acceder con frecuencia para que su autenticación pueda volver a validarse, lo que permite, por ejemplo, un cambio de contraseña para invalidar las sesiones existentes durante un período conocido.
Si usas este enfoque, tenemos una solución técnica que puede ayudarte a volver a validar de forma automática la cookie de autenticación sin estado. Funciona mediante un token secundario de larga duración que se puede usar para actualizar la cookie de autenticación de corta duración existente. Si aprovechamos el nuevo patrón de service worker, podemos “registrar” con regularidad el token de larga duración, verificar la autenticación del usuario (por ejemplo, comprobar si no cambió recientemente sus contraseñas o revocado la sesión de alguna otra manera) y volver a emitir una nueva cookie de autenticación de corta duración.
Una propuesta práctica para migrar a sesiones largas seguras en la Web
A partir de aquí, en esta publicación se describe una nueva técnica que proponemos: 2-Cookie-Handoff (2CH). Esperamos usar este artículo para escuchar los comentarios de la comunidad sobre si este enfoque parece positivo y, de ser así, para trabajar con la industria en la documentación de las prácticas recomendadas para el uso de 2CH.
Los service workers son una tecnología nueva compatible con varios navegadores, como Chrome, Firefox y Opera, y pronto estará disponible en Edge. Te permiten interceptar todas las solicitudes de red de tu sitio a través de un punto de código común en el cliente, sin modificar las páginas existentes. Esto te permite configurar un "trabajador 2CH" para los usuarios que accedieron a su cuenta, que puede interceptar todas las solicitudes de red que realiza tu página y realizar el intercambio de tokens como lo hacen las apps para dispositivos móviles.
Muchas veces, tu servidor ya tiene un extremo que usan las apps para dispositivos móviles a fin de obtener un nuevo token de corta duración, por lo general, mediante el protocolo OAuth. Para habilitar el patrón anterior en la Web, debes actualizar ese extremo para que comprenda cuándo lo llama un service worker y, luego, mostrar una nueva cookie de sesión de corta duración con el formato que ya esperan otras páginas del sitio.
Si tu servidor aún no cuenta con un extremo de este tipo, puede crear uno solo para la administración de las sesiones del navegador.
El patrón de dos tokens con service workers sigue de cerca el patrón de OAuth 2.0. Si ya ejecutas un extremo de token de OAuth, es probable que puedas volver a usarlo con service workers para la autenticación web.
Es posible que también te preguntes qué sucede si el usuario visita un navegador que no es compatible con los service workers. Si implementas el enfoque anterior, no experimentarán ninguna diferencia y seguirán teniendo sesiones cortas.
Publicamos un cliente y un backend de muestra. Esperamos que lo pruebes por tu cuenta y respondas una encuesta sobre la administración de sesiones.