Así que he estado tratando de aprender todo lo que puedo sobre la tokenización de JWT, y auth0 parece ser el centro de información de JWT de facto.
Sin embargo, cuanto más leo sobre los tokens de actualización, más me estremezco: la idea de un refrescante "infinitamente" (o al menos una caducidad muy larga) no me acompaña.
Así que aquí está lo que he decidido implementar.
La arquitectura del sistema: 1. API (capa API pura, también el servidor de autenticación en este momento): crea los tokens y los valida 2. Capa de aplicación (solicitudes de manejo del matraz).
Cuando un usuario intenta ingresar a la aplicación, se envía a la página de inicio de sesión. Ingresan sus detalles, y estos se envían al punto final / autorizar en la API.
Estos detalles se validan y se crea un token con un reclamo que contiene: "iat" emitido en "exp" vencimiento 30 minutos "oct" tiempo de creación original
En lo que respecta al servidor de autenticación y la API, este token caducará en 30 minutos.
Ahora, en la capa de aplicación, cada solicitud comprueba el token y ve si quedan menos de 5 minutos antes de que caduque.
Si encuentra que existe, crea su propio JWT (firmado con el mismo secreto que sabe la API). Utiliza el JWT original (a punto de caducar) como un objeto de carga útil, luego lo envía a un punto final en el auth / refresh_token
El punto final / refresh_token luego valida el token, extrae el token original de la carga, lo valida y si es un token válido (aún no ha caducado). Luego verifica el tiempo original creado y se asegura de que no se haya alcanzado el tiempo de espera máximo (establecido por el cliente de nuestra aplicación); este es un límite duro del sistema de 12 horas (pero nuestros clientes pueden optar por sesiones totales más cortas). Si esas comprobaciones están bien, crea un NUEVO token y lo envía de nuevo a la capa de aplicación.
De esta manera, mi pensamiento es:
-
El servidor Auth siempre puede confiar en esta solicitud de actualización, ya que debe recibir un JWT confiable que contenga el JWT creado originalmente por el servidor Auth. Esto significa que solo pudo haber sido creado por la capa de aplicación (o cualquier servidor que tenga el secreto).
-
El servidor Auth no distribuye infinitamente tokens de actualización.
-
Si el secreto se ve comprometido, de todos modos es un experto, y hasta que sepa que se ha comprometido, no hay mucho que pueda hacer. Por supuesto, tenemos comprobadores de IP para garantizar que las solicitudes de JWT provengan de fuentes confiables, pero aún así: la falsificación de IP no es difícil si el atacante sabía lo que estaban haciendo.
-
La capa de aplicación, tiene la capacidad de detener el envío de actualizaciones eliminando la sesión del usuario; por lo tanto, un JWT comprometido solo sería "peligroso" por hasta 30 minutos.
Mucha gente está muy preocupada por la seguridad, y con razón, pero ¿diría que este enfoque proporciona controles y balances adecuados?
Si no, me encantaría escuchar ideas, mejoras en el proceso, etc. La seguridad definitivamente no es mi fuerte, así que ¡toda la ayuda será muy apreciada!
Saludos.