Esquema de autenticación y autorización JWT

4

Estaba revisando los documentos de Oauth2 y pensé que era un tipo de seguridad permisiva, así que intenté implementar tokens JWT con un esquema especial como el de la imagen para una aplicación móvil que se comunica con una API web.

Notas: no me gustó la idea de tokens de actualización de Oauth2, ya que podrían ser robados y permitir el uso paralelo (por usuarios legítimos y maliciosos) a menos que implemente la detección de robo girándolos (refrescando el token de actualización en cada solicitud) en este caso, ¿por qué los usa? en absoluto?

Cómo funciona el flujo de autenticación:

  1. Un usuario que inicia sesión con credenciales obtiene un jwt de 20 minutos de duración.
  2. Al expirar, el jwt se actualiza presionando la base de datos si está en la lista negra (reiniciar sesión) y, si no, verifica si se usó para generar un nuevo token.
  3. Si nunca se usó para actualizar, se acepta y se usa para emitir un token de acceso de bajo grado.
  4. Si el token se usó antes, o si tenía un cliente + dispositivo + usuario diferente al de su padre, ofrezca una verificación de credenciales (contraseña o código de bloqueo de pantalla)
  5. Si se aprueba, esta verificación emite un nuevo token de primer grado que enumera a todos sus padres e hijos en la base de datos, es como un nuevo inicio de sesión de primer usuario.
  6. Si falla la pantalla de bloqueo, al usuario se le presenta una pantalla de inicio de sesión.

Las preguntas son:

  1. ¿Cuáles son los posibles agujeros de seguridad? (Encontré dos casos de uso: el token de acceso válido robado dura 20 minutos, el mismo problema que los tokens de Oauth. No hay pérdida aquí. Y el token de inactividad robado: el usuario no ha iniciado sesión durante, por ejemplo, 7 días; el token se roba y se usa hasta que el usuario vuelva a iniciar sesión o la cadena de fichas se revoca después de 3 meses de persistencia, nuestra política, y este robo tiene pocas posibilidades ya que la señal debe ser interceptada en la última solicitud que el usuario hace en la aplicación, más delgada que robar una ficha de actualización de Oauth2)
  2. ¿Cuáles son los problemas de experiencia de usuario que un atacante puede causar en la aplicación mientras está en este esquema?
pregunta Asma Hakim 12.05.2016 - 23:28
fuente

1 respuesta

3

Como @jpodwys dice en su comentario, HTTPS es un tránsito seguro. Me parece muy poco probable que un atacante pueda robar un token de actualización OAuth2 y no robar otra información crítica. Es decir, en el momento en que le roban tokens a través de conexiones HTTPS, ya habrá sido pwned y se habrá acabado el juego. OAuth2 es un protocolo bien probado que tiene muchas implementaciones probadas en muchos idiomas. Sospecho firmemente que será más seguro que cualquier cosa que elija diseñar e implementar por su cuenta. En general, rodar el tuyo es un error. Consulte todas estas respuestas por los motivos.

En respuesta a su pregunta sobre por qué existen tokens de actualización, existen para permitir que el usuario revoque la autorización, no para tratar con un token de actualización robado (ya que eso nunca ocurre). Considere el caso en el que un usuario otorga acceso y luego, de forma abrupta, lo revoca. Desea minimizar el retraso entre la revocación que se produce y la revocación que tiene efecto. Una forma de llevar el retraso a (casi) cero es verificando con el proveedor del servicio en cada llamada. Pero verificar con el SP en cada solicitud no es performante. En su lugar, permite que el token de acceso se utilice durante un período de tiempo limitado y obliga a que se renueve de vez en cuando. Esto significa que si el usuario revoca la autorización, entrará en vigencia en un tiempo no mayor que la vida del token de acceso.

    
respondido por el Neil Smithline 13.05.2016 - 03:45
fuente

Lea otras preguntas en las etiquetas