¿Qué tan seguros están expirando los tokens y los tokens de actualización?

Puede ser que el token de acceso termine siendo usado alrededor de la aplicación a través de conexiones HTTP simples. Entonces, si un atacante lo olfateara, solo tendrían acceso a corto plazo. Esto es lo que solía ocurrir en la web como estándar. El inicio de sesión se realizó a través de HTTPS si tuvo suerte, y el resto de su sesión se realizó mediante HTTP simple, transmitiendo el ID de sesión en texto simple.

El token de actualización solo se transmite al servidor de autorización, por lo que es más fácil aplicar HTTPS, lo que significa que un atacante no pudo escuchar a escondidas esta conexión.

Consulte aquí para obtener más información :

  

Hay una razón de seguridad, el refresh_token solo se intercambia   con el servidor de autorización mientras que access_token se intercambia con   servidores de recursos. Esto mitiga el riesgo de una larga vida   access_token leaking (parametrización de consulta en un archivo de registro en un archivo inseguro   servidor de recursos, beta o aplicación de servidor de recursos mal codificada, JS SDK   cliente en un sitio no https que pone el access_token en una cookie,   etc) en el "un token de acceso válido durante una hora, con un token de actualización   bueno por un año o bien-revocada "vs" un token de acceso   good-till-revoked sin un token de actualización ".

Respondí una pregunta similar que terminó siendo marcada como un duplicado a esta. Sin embargo, creo que mi respuesta a esa pregunta proporciona un argumento más sólido de cómo los tokens de actualización proporcionan seguridad adicional. En resumen, si el token de actualización está comprometido, es mucho más fácil detectarlo y tomar las medidas adecuadas, como deshabilitar los tokens de autenticación y tokens de actualización, y obligar al usuario a iniciar sesión nuevamente con sus credenciales. En otras palabras, las credenciales comprometidas pueden cerrarse mucho más rápido cuando se usan los tokens de actualización.

Consideremos que hay un servidor que valida y emite tokens para un cliente.

Cliente (envía el nombre de usuario y la contraseña) - > Servidor

Servidor (valida las credenciales y devuelve acceso y actualiza tokens) - > Cliente

El cliente almacena los tokens de forma segura y utiliza el token de acceso para las llamadas de API adicionales realizadas al servidor (hasta que caduque el token de acceso). Una vez que el token de acceso caduca, el cliente puede recibir un código HTTP 401 (no autorizado) del servidor y se da cuenta de que el token de acceso ya no es válido.

El cliente luego usa su token de actualización y obtiene los nuevos accesos y tokens de actualización del servidor.

Efectos de un token de acceso comprometido: el atacante podrá acceder a los datos hasta que caduque el token de acceso.

Efectos de un token de actualización comprometido: el atacante puede obtener un nuevo acceso y actualizar el token, lo que también puede invalidar el acceso de la víctima. Cuando la víctima intenta obtener un nuevo token de acceso con su token de actualización, fallará porque su token de actualización ya se ha utilizado. La víctima tendría que iniciar sesión nuevamente usando sus credenciales, que volverían a emitir los tokens e invalidarán los tokens robados del atacante.