Estaré usando JWT para la autenticación de mi API REST. Estoy utilizando servicios de nube de terceros y la escritura de la base de datos es muy costosa, por lo que estoy tratando de evitar escribir en la base de datos tanto como pueda. Debido a esto, quiero evitar el uso de un token de actualización porque de esa forma tendría que actualizar la base de datos con frecuencia (la escritura es casi 10 veces más cara que la lectura). Mi plan general para el flujo de autenticación es el siguiente:
1) Registros de usuarios (asumiendo que la autenticación de correo electrónico está completa y todo) y la siguiente tabla de base de datos se llena como tal:
| Username | HashedPassword | TokenIncrement | AccountStatus
------------------------------------------------------------
Bob | someGiberish | 1 | Valid
2) El servidor genera un token que es válido durante 15 minutos. Tiene un campo TokenIncrement etiquetado como 1
3) El usuario interactúa con mi aplicación utilizando el token
4) El token ha caducado
5) El usuario intenta usar el token caducado
6) El servidor detecta que está vencido (todo lo demás, como el emisor, el asunto, etc., son válidos)
7) El servidor no actualizará este token.
8) El servidor lee la base de datos para este usuario. Ve que la cuenta es válida y que el incremento del token es igual a 1. Esta es la misma información que se almacena en el token, por lo que el servidor crea un token nuevo para el usuario.
9) En el camino, el token es robado (o el usuario cree que sí lo es) por lo que informa que su cuenta ha sido pirateada.
10) Este token robado se puede usar para seguir haciendo cosas maliciosas y se puede actualizar constantemente hasta que se considere que la cuenta está realizando actividades sospechosas.
10) Mi servidor luego incrementaría el campo de la base de datos TokenIncrement a 2.
11) Ahora, todos los token antiguos no podrían actualizarse porque tendrían un TokenIncrement de 1. Esto significa que cuando se estaban verificando, el token diría 1, pero la base de datos mostraría 2, no lo harían. partido.
12) El usuario válido volverá a iniciar sesión y obtendrá el token adecuado con el incremento que muestra 2 y podrá hacer lo que sea necesario.
Con este método, la única vez que necesitaría una escritura en la base de datos es cuando se hackea una cuenta, en lugar de actualizar la base de datos cada vez que caduque el token de actualización.
Además de las fallas de seguridad heredadas de JWT, ¿hay algún agujero obvio en esta estrategia (entiendo que nada es realmente seguro)?
Alegría