oauth-2.0 - español - jwt vs oauth2

¿Es realmente necesario un token de actualización cuando se utiliza la autenticación de token JWT?

Question

Me estoy refiriendo a otra publicación SO que discute el uso de tokens de actualización con JWT.

JWT (JSON Web Token) prolongación automática de la caducidad

Tengo una aplicación con una arquitectura muy común donde mis clientes (web y móvil) hablan con una API REST que luego habla con una capa de servicio y una capa de datos.

Entiendo la autenticación de token JWT, pero estoy un poco confundido sobre cómo debo usar tokens de actualización.

Quiero que mi autenticación JWT tenga las siguientes propiedades:

1. JWT Token tiene un vencimiento de 2 horas.

2. El token se actualiza cada hora por el cliente.

3. Si el token de usuario no se actualiza (el usuario está inactivo y la aplicación no está abierta) y caduca, deberá iniciar sesión cada vez que desee reanudar.

Veo que muchas personas afirman que hacen de esta una mejor experiencia el uso del concepto de token de actualización, sin embargo, no veo el beneficio de esto. Parece una complejidad añadida al tener que gestionarlo.

Mis preguntas son las siguientes:

1. Si IRA a utilizar un token de actualización, ¿no sería igualmente beneficioso tener una caducidad a largo plazo para las buenas prácticas en ese token también?
2. Si IRA utilizar un token de actualización, ¿ese token se conservará con el ID de usuario y / o el token de JWT?
3. Cuando actualizo mi token cada 1 hora, ¿cómo funciona esto? ¿Querré crear un punto final que acepte mi token JWT o mi token de actualización? ¿Esto actualizará la fecha de caducidad de mi token JWT original o creará un token nuevo?
4. ¿Existe realmente la necesidad de un token de actualización dados estos detalles? Parece que si el usuario solo está utilizando un token JWT para tomar un token nuevo (según el enlace de arriba), entonces el token de actualización está obsoleto.

Answer 1

Creo que para este escenario usted podría trabajar solo con el token de acceso, haciendo la vida más fácil para sus clientes pero manteniendo los beneficios de seguridad de un token de actualización.

Así es como funcionaría:

1. Cuando su usuario inicia sesión con credenciales (nombre de usuario / contraseña), devuelve un JWT de corta duración. También crea un registro db donde almacena:

   • ID de JWT
   • ID de usuario
   • dirección IP
   • agente de usuario
   • un indicador valid (predeterminado en VERDADERO)
   • Creado en
   • updatedAt

2. Su cliente envía el JWT en cada solicitud. Mientras el JWT no haya caducado, tendrá acceso a los recursos. Si el JWT expiró, lo actualiza entre bambalinas y devuelve tanto el recurso como un encabezado X-JWT adicional con el nuevo JWT.

3. Cuando el cliente recibe una respuesta con un encabezado X-JWT , descarta el JWT anterior y usa el nuevo para futuras solicitudes.

Cómo funciona la actualización de JWT en el servidor

1. Busque el registro de db correspondiente utilizando el id de JWT.
2. Compruebe si el indicador valid sigue siendo verdadero, de lo contrario rechace.
3. Opcionalmente, puede comparar la dirección IP de solicitud y el agente de usuario con la dirección de IP almacenada y el agente de usuario, y decidir rechazar si algo parece sospechoso.
4. Opcionalmente, puede verificar los campos createdAt o updatedAt del registro db, y decidir no actualizar si ha pasado demasiado tiempo.
5. Actualice el campo updatedAt en el registro db.
6. Devuelva el nuevo JWT (que es básicamente una copia del JWT vencido, pero con un tiempo de vencimiento extendido).

Este diseño también le daría la opción de revocar todos los tokens para un usuario (por ejemplo, si el usuario pierde su teléfono o actualiza su contraseña).

Beneficios:

• Su cliente nunca tiene que verificar los tiempos de expiración o hacer solicitudes de token de actualización, todo lo que hace es verificar si hay un encabezado X-JWT en las respuestas.
• Puede agregar una lógica de actualización personalizada basada en la dirección IP, el agente de usuario, la antigüedad máxima de token o una combinación de ellos.
• Puedes revocar algunos o todos los tokens para un usuario.

Answer 2

Permítanme abordar sus preguntas un poco más tarde y comenzar discutiendo sobre el propósito de un token de actualización.

Así que la situación es:

El usuario abre la aplicación y proporciona sus credenciales de inicio de sesión. Ahora, lo más probable es que la aplicación esté interactuando con un servicio backend REST. Debido a que REST no tiene estado, no hay realmente una manera de autorizar el acceso a las API. Por lo tanto, hasta ahora en la discusión, no hay forma de verificar si un usuario autorizado está realmente accediendo a las API o si solo se están realizando algunas solicitudes aleatorias.

Ahora para poder resolver este problema, necesitamos una manera de saber que las solicitudes provienen de un usuario autorizado. Entonces, lo que hicimos fue introducir algo que se llama un token de acceso. Entonces, una vez que el usuario se autentica correctamente, se le emite un token de acceso. Se supone que este token es un token largo y altamente aleatorio (para garantizar que no se pueda adivinar). Aquí es donde el JWT entra en escena. Ahora es posible que no desee almacenar ningún detalle específico del usuario en un token JWT. Lo ideal sería que simplemente guardara detalles muy simples y extremadamente no sensibles en el JWT. La manipulación del hash JWT para recuperar los detalles de otros usuarios (IDOR, etc.) está a cargo de JWT (la biblioteca que se está utilizando).

Así que por ahora nuestro problema de acceso autorizado está resuelto.

Ahora hablamos de un escenario de ataque. Digamos que el uso de todos los usuarios anteriores, Alice, que utiliza la aplicación, tiene el token de acceso autorizado y ahora su aplicación puede realizar solicitudes a todas las API y recuperar los datos según su autorización.

Supongamos que ALGUIEN Alicia pierde el token de acceso o, de otra manera, un adversario, Bob, obtiene acceso al token de acceso de Alicia. Ahora Bob, a pesar de no estar autorizado, puede realizar solicitudes a todas las API para las que Alice estaba autorizada.

ALGO QUE IDEALMENTE NO QUEREMOS.

Ahora la solución a este problema es:

1. O detectan que algo de este tipo está sucediendo.
2. Reduce la propia ventana de ataque.

Usando solo el token de acceso solo, es difícil lograr la condición 1 anterior, ya sea Alicia o Bob, es el mismo token autorizado que se está utilizando y, por lo tanto, las solicitudes de los dos usuarios no son distinguibles.

Así que intentamos obtener 2 arriba y, por lo tanto, agregamos una caducidad a la validez del token de acceso, digamos que el token de acceso es válido por el tiempo ''t'' (corta duración).

¿Cómo ayuda? Bueno, incluso si Bob tiene el token de acceso, solo puede usarlo hasta que sea válido. Tan pronto como caduque, tendrá que recuperarlo de nuevo. Ahora, por supuesto, se podría decir que puede obtenerlo de la misma manera que lo hizo la primera vez. Pero, de nuevo, ¡no hay nada como 100% de seguridad!

El enfoque anterior todavía tiene un problema y, en algunos casos, uno inaceptable en realidad. Cuando el token de acceso caduque, se requerirá que el usuario ingrese sus credenciales de inicio de sesión y obtenga un token de acceso autorizado nuevamente, lo cual, al menos en el caso de las aplicaciones móviles, es una experiencia de usuario mala (no aceptable).

Solución: Aquí es donde entra el token de actualización. De nuevo, es un token impredecible aleatorio que también se emite a la aplicación junto con el token de acceso en primer lugar. Este token de actualización es un token especial de larga vida útil, que garantiza que tan pronto como caduque el token de acceso, solicite al servidor un nuevo token de acceso, lo que elimina la necesidad de que el usuario vuelva a ingresar sus credenciales de inicio de sesión para recuperar un nuevo token de acceso autorizado, una vez que haya expirado uno existente.

Ahora puede preguntar, Bob también puede tener acceso al token de actualización, similar a la forma en que comprometió el token de acceso. SÍ. Él puede. Sin embargo, ahora resulta fácil identificar una incidencia de este tipo, que no era posible en el caso de un token de acceso solo, y tomar las medidas necesarias para reducir el daño causado.

Cómo ?

Para cada usuario autenticado (en el caso de una aplicación móvil, en general), se envía a la aplicación un token de actualización y un par de token de acceso asignados uno a uno. Por lo tanto, en un momento dado, para un único usuario autenticado, solo habrá un token de acceso correspondiente a un token de actualización. Ahora suponga que si Bob ha comprometido el token de actualización, lo usaría para generar un token de acceso (porque el token de acceso es lo único que está autorizado para acceder a los recursos a través de las API). Tan pronto como Bob (el atacante) realice una solicitud con el token de acceso recién generado, debido a que el token de acceso de Alice (usuario genuino) aún es válido, el servidor lo verá como una anomalía, porque para un solo token de actualización solo puede haber un autorizado token de acceso a la vez. Al identificar la anomalía, el servidor destruiría el token de actualización en cuestión y, junto con él, todos los tokens de acceso asociados también se invalidarán. De este modo, se evita cualquier acceso posterior, genuino o malicioso, a cualquier autorización que requiera recursos. El usuario, Alice, tendría que autenticarse nuevamente con sus credenciales y obtener un par de tokens de actualización y acceso válidos.

Por supuesto, aún podría argumentar que Bob podría volver a tener acceso para actualizar y acceder a tokens y repetir toda la historia anterior, lo que potencialmente podría llevar a un DoS en Alice, el verdadero cliente real, pero nuevamente no hay nada como 100% de seguridad. .

También como buena práctica, el token de actualización también debe tener una caducidad, aunque sea bastante largo.