¿Es suficiente almacenar una identificación de usuario en JWT para verificar la identidad?

Question

¿Es suficiente almacenar una identificación de usuario en JWT para verificar la identidad?

#1 de Peter Harmann (1 votos)

1

He estado pensando en probar JWT como una alternativa a la autenticación basada en sesiones antiguas por razones de rendimiento (es decir, no hay búsqueda SQL adicional para la identificación de la sesión en la base de datos solo para obtener la identificación del usuario para cada solicitud HTTP) y razones de usabilidad (JWT se usará en los encabezados HTTP en lugar de las cookies para que mi aplicación pueda usarse como API RESTFUL y sea accedida por clientes que no utilizan el navegador, como las aplicaciones móviles, además, agregar JWT en los encabezados HTTP elimina el peligro de CSRF). Dado que la carga útil se firma con un HMAC seguro como SHA256, es casi imposible falsificar la carga útil. Además, la identificación de usuario itslef no es realmente un secreto y la aplicación la utiliza públicamente.

Estoy pensando en usar una carga útil que es algo como esto:

{
  id: "1234abcd",
  iat: 1522779638
}

donde iat es una marca de tiempo de Unix en la que se creó el JWT y esto se puede usar para caducar el mensaje JWT y también para reforzar la seguridad al aleatorizar el hash para la misma ID.

Mi pregunta es, asumiendo que voy a aplicar una conexión HTTPS estricta para mi aplicación en producción, está usando esta carga útil sin cifrar lo suficientemente segura como para verificar la identidad del usuario e iniciar métodos inseguros como los métodos POST (por ejemplo, seguir a un usuario, dejar de seguir a un usuario , etc ...) ¿es tan seguro como la autenticación basada en sesión? ¿Necesito cifrar la carga útil utilizando algo como AES-192 o AES-256 solo para estar más seguro?

cookies jwt

pregunta pls no 06.05.2018 - 18:30

fuente

1 respuesta

Lea otras preguntas en las etiquetas cookies jwt

ID de sesión en el primer cliente Hola Sesión de autenticación de larga duración para aplicaciones móviles nativas

score 1 · Accepted Answer

Esto parece ser suficiente para autenticar al usuario y asegurar el token en tránsito. Sin embargo, el problema podría ser que con este sistema, no tendría una buena manera de revocar tal token. Por lo tanto, si el token es robado, se puede usar para siempre. Es posible que desee tener una forma para que el usuario revoque estos tokens. Hay muchos escenarios donde el token podría ser robado, desde malware a través del teléfono robado para iniciar sesión en una PC insegura, digamos en un cibercafé.

Una posibilidad sería simplemente agregar una sola columna "no antes" a la tabla de usuarios y rechazar tokens con iat más bajo que eso. Por lo tanto, el usuario podría revocar todos los tokens emitidos previamente estableciendo esta columna en la marca de tiempo actual. Esto requeriría acceso a la base de datos, pero solo a la tabla de usuarios con ID, que probablemente querrá hacer de todos modos.