Autenticación sin estado con JWT: el token de actualización no es sin estado

10

En mi arquitectura actual, mi backend emite un JWT de vuelta al cliente (móvil). La razón principal para optar por un JWT es la autenticación sin estado, es decir, el servidor no necesita almacenar datos en la sesión / base de datos, lo que significa menos problemas de sobrecarga y escalabilidad.
Una estrategia común es iniciar sesión en el usuario y devolver el JWT de corta duración (aproximadamente 15 minutos, mientras leo), junto con un token de actualización que el usuario almacena en el cliente. El token de actualización nunca caduca y solo se puede revocar. El propósito sería evitar el envío de un JWT de larga duración a través del cable demasiadas veces y solo actualizar el JWT cuando caduque; cuando un atacante consigue el token de corta duración, la ventana de tiempo de ataque es breve.

El problema es que esta historia parece estar llena de agujeros cuando lo pienso. Por favor ayúdame a aclarar.

  1. Un tiempo de caducidad de 15 minutos significaría que algunos usuarios también podrían enviar un token de actualización a través del cable 10 veces / día. Esa podría ser una frecuencia tan alta como la que haría un usuario con un token de acceso regular y de corta duración. Por lo tanto, el argumento del token de actualización parece cuestionable.
  2. Si cuestionas SSL, entonces no sé por qué tantas empresas usan autenticación básica. Para usar JWT con token de actualización, probablemente deberías usar HTTPS de todos modos.
  3. ¿Cuál es el beneficio de JWT si luego necesita almacenar un token de actualización en la sesión / base de datos para emitir un nuevo jwt al cliente? En este caso, el token de actualización actuaría como una especie de contraseña (aunque me doy cuenta de que no es exactamente la misma) que se almacena en el servidor. Esto hace que el flujo de autenticación sea esencialmente estable y parece eliminar el beneficio de usar JWT por completo. Además, con un breve período de caducidad de 15 minutos, significa que tiene una gran cantidad de gastos generales, por lo que necesita obtener un token de acceso actualizado casi cada vez que verifica su teléfono si hay un intervalo de 30 minutos. No solo existe la sobrecarga para verificar el token de actualización almacenado, sino que también debe verificar si la ficha de actualización está en la lista negra, lo que significa otra sobrecarga de rendimiento. (Editar: la última comprobación se puede eliminar simplemente eliminando el token de actualización de la base de datos cuando se revoca).
  4. Un token de actualización requiere varios viajes de ida y vuelta al servidor:
    • Se devuelve 401 cuando el token de acceso ha caducado (servidor de recursos).
    • Es necesario solicitar un nuevo token de acceso en el servidor de autenticación
    • La solicitud al servidor de recursos debe reiniciarse.

¿Puede alguien explicarme lo que me estoy perdiendo aquí?

    
pregunta Trace 11.06.2017 - 00:04
fuente

2 respuestas

8

Una de las principales críticas de los tokens de sesión sin estado es la falta de un cierre de sesión seguro. Tener un token de acceso / actualización separado permite un compromiso. Puede reducir en gran medida la cantidad de acceso a la base de datos, a la vez que tiene una función de cierre de sesión segura con un retraso de 15 minutos.

El diseño no hace nada para proteger contra el secuestro de sesión, es decir, la captura maliciosa del token. Solo use SSL, es ubicuo en estos días.

Puede reducir la cantidad de viajes de ida y vuelta con cierto cuidado. Muchas bibliotecas HTTP de clientes le permiten realizar una autenticación proactiva, lo que evita el viaje de ida y vuelta adicional para obtener un 401.

Estoy de acuerdo en que no es un diseño particularmente sensato. La mayoría de los sitios web tienen una base de datos pesada, por lo que revisar un token en cada solicitud no es mucho más costoso. Y aunque el concepto básico de tokens de acceso / actualización es seguro, me preocupa que la complejidad adicional invite a fallas en la implementación.

    
respondido por el paj28 20.06.2017 - 20:09
fuente
1

A menos que haya otras respuestas a esta pregunta, mi solución actual es que se trata de evaluar las ventajas y desventajas del riesgo de seguridad contra el desempeño.

Mi consideración principal es aumentar la ventana de tiempo del token de acceso jwt "de corta duración" de 15 minutos a un día.
Esto se debe a que se requiere HTTPS y que las solicitudes solo se realizan internamente, es decir, los tokens no viajan entre dominios.

Esto significa que, en términos de rendimiento, la actualización del token solo se realiza una vez al día. Teóricamente, SSL debería proporcionar suficiente seguridad en mi caso; Un solo día de la ventana de ataque es simplemente una medida de seguridad por encima de algo que no debería ocurrir en primer lugar.

Aunque los tokens de actualización esencialmente hacen que el proceso de autenticación sea completo, esto puede ser aceptable, ya que la mayoría de las solicitudes (en este caso durante un día) al servidor de recursos aún ocurren utilizando el jwt.

    
respondido por el Trace 11.06.2017 - 02:16
fuente

Lea otras preguntas en las etiquetas