Manejo de la caducidad del token jwt

Question

Manejo de la caducidad del token jwt

#1 de Julian Knight (1 votos)

2

Tengo un back-end nodejs basado en koajs para mi aplicación personal / hobby. Implementé el manejo de sesión con tokens jwt. Ahora el cliente obtiene su token después de una autenticación de inicio de sesión exitosa, por lo que mi cliente angularjs almacena el token en algún lugar (actualmente en sessionStorage, pero para esta pregunta no nos importa el almacenamiento). Tengo dos preguntas

Cuando necesito actualizar el registro de usuario que representa el jwt, por ejemplo, el usuario activó 2FA, así que le pedí que proporcionara su número de teléfono y me gustaría establecerlo en el registro del usuario. Actualmente, después de una verificación exitosa en el número de teléfono, llamo a mi backend para actualizar el registro de usuario y creo un nuevo token JWT con el registro de usuario actualizado (excluyo la información confidencial del token jwt como hash pwd y otros ..., pero Me gustaría incluir el número de teléfono para uso del lado del cliente). Entonces, básicamente la pregunta es, ¿está bien crear un nuevo token cuando algunas de las credenciales cambian y actualizan el token del lado del cliente existente con este nuevo token? ¿Nunca debería crear otro token, solo para crear el único y solo después de una autenticación exitosa? ¿Cómo actualizo la carga útil en el token?
¿Cómo debo manejar los tokens jwt caducados? En mi mente tengo 3 (posibles) escenarios:
1. El jwt está configurado para una vida corta, digamos 15 minutos. Si el servidor backend responde con un "token ivalid" no autenticado 401 (supongo que este es el comportamiento predeterminado de koa-jwt), cerraré sesión automáticamente a mi cliente y requeriré una nueva autenticación. Pero también configuré un middleware complementario que es el último de la cadena en el backend para volver a crear el token con una caducidad actualizada y el cliente también reemplazaría el token existente con el actualizado. Por lo tanto, si el usuario está activo y utiliza la aplicación, todas las llamadas a API protegidas, en caso de éxito, crearían un nuevo token para reemplazar el token antiguo.
2. El jwt se establece como de larga duración, digamos 1 semana, y si caduca, me inscribo nuevamente en la autenticación del cliente.
3. Copie enlace . Aquí cuando creamos el token jwt después de una autenticación exitosa, enviamos un access_token y un refresh_token. Cuando el access_token caduca y el servidor responde con HTTP 401 'token no válido' (koa-jwt predeterminado), el cliente envía el refresh_token al respaldo para requerir un nuevo access_token (& opcionalmente un nuevo refresh_token). En este caso, no entiendo completamente cómo se verifica el refresh_token con el antiguo access_token para proporcionar un nuevo token. O ¿por qué necesitamos tener un refresh_token?

Básicamente, solo necesito consejos genéricos sobre los temas superiores (actualizaciones de JWT y vencimiento de JWT). Gracias

jwt node.js

pregunta Jim-Y 03.10.2016 - 08:50

fuente

1 respuesta

Lea otras preguntas en las etiquetas jwt node.js

¿Cómo la 'probabilidad de verificación' está inversamente relacionada con la 'tasa de aceptación falsa'? intercepción SSL con certificado de cliente

score 1 · Answer 1

" está bien crear un token nuevo cuando cambian algunas de las credenciales "

Absolutamente. Por lo general, los tokens deberían ser de corta duración, por lo que crear uno nuevo no es un problema.
La respuesta aquí depende en parte de cómo esté manejando el problema de ataque de repetición del hombre en el medio con JWT. Si no está haciendo nada, sus tokens deben ser de corta duración, pero es posible que no desee que sus clientes tengan que volver a iniciar sesión constantemente. Ahí es donde entra el mecanismo de actualización. Le brinda una capacidad intermedia opcional para actualizar tokens. sin un inicio de sesión completo.

Si está manejando el problema de MITM, tendrá implementada seguridad adicional del lado del servidor para validar los tokens del usuario. En ese caso, puedes permitirte tener tokens de vida más larga.

De cualquier manera, si los usuarios cambian sus datos de seguridad de alguna manera, parece sensato invalidar el token y requerir otro inicio de sesión. Pero es totalmente de usted. Debe comprender el valor de los usuarios y sus sesiones y los riesgos. Cuando lo comprende, puede decidir con sensatez la cantidad de riesgo que quiere asumir y la mejor manera de mitigar el riesgo que no desea asumir.