Flujo de token de actualización de JWT

Estoy creando una aplicación móvil y estoy usando JWT para la autenticación.

Parece que la mejor manera de hacer esto es emparejar el token de acceso JWT con un token de actualización para que pueda caducar el token de acceso con la frecuencia que desee.

1. ¿Cómo se ve un token de actualización? ¿Es una cadena aleatoria? ¿Está cifrada esa cadena? ¿Es otro JWT?
2. El token de actualización se almacenaría en la base de datos en el modelo de usuario para acceder, ¿correcto? Parece que debería estar encriptado en este caso
3. ¿Enviaría el token de actualización después de un inicio de sesión de usuario y luego haría que el cliente acceda a una ruta separada para recuperar un token de acceso?

Suponiendo que se trata de OAuth 2.0, ya que se trata de JWT y tokens de actualización ...:

1. al igual que un token de acceso, en principio, un token de actualización puede ser cualquier cosa, incluidas todas las opciones que describa; un JWT podría usarse cuando el servidor de autorización quiere ser apátrida o quiere aplicar algún tipo de semántica de "prueba de posesión" al cliente que lo presenta; tenga en cuenta que un token de actualización difiere de un token de acceso en que no se presenta a un servidor de recursos, sino solo al servidor de autorización que lo emitió en primer lugar, por lo que la optimización de validación autónoma para JWTs-as-access-tokens sí no mantener para actualizar tokens

2. eso depende de la seguridad / acceso de la base de datos; si otras partes / servidores / aplicaciones / usuarios pueden acceder a la base de datos, entonces sí (pero su millaje puede variar según dónde y cómo almacene la clave de cifrado ...)

3. un servidor de autorización puede emitir tokens de acceso y tokens de actualización al mismo tiempo, según la concesión que utilice el cliente para obtenerlos; la especificación contiene los detalles y las opciones de cada una de las subvenciones estandarizadas

A continuación se muestran los pasos para revocar su token de acceso JWT:

1. Cuando inicie sesión, envíe 2 tokens (token de acceso, token de actualización) en respuesta al cliente.
2. El token de acceso tendrá menos tiempo de expiración y Refresh tendrá un tiempo de expiración más largo.
3. El cliente (Front end) almacenará el token de actualización en su almacenamiento local y el token de acceso en las cookies.
4. El cliente utilizará un token de acceso para llamar a las API. Pero cuando expire, elija el token de actualización del almacenamiento local y llame a la API del servidor de autenticación para obtener el nuevo token.
5. Su servidor de autenticación tendrá una API expuesta que aceptará el token de actualización y verificará su validez y devolverá un nuevo token de acceso.
6. Una vez que expire el token de actualización, se cerrará la sesión del usuario.

Por favor, avíseme si necesita más detalles, también puedo compartir el código (Java + Spring boot).

Para sus preguntas:

P1: Es otro JWT con menos reclamos presentados con un largo tiempo de vencimiento.

P2: No estará en una base de datos. El backend no se almacenará en ningún lado. Simplemente descifrarán el token con una clave privada / pública y también lo validarán con su tiempo de caducidad.

P3: Sí, correcto

Basado en esta implementación con Node.js de JWT con token de actualización :

1) En este caso usan un uid y no es un JWT. Cuando actualizan el token, envían el token de actualización y al usuario. Si lo implementa como un JWT, no necesita enviar el usuario, porque lo haría dentro del JWT.

2) Implementan esto en un documento separado (tabla). Para mí tiene sentido porque un usuario puede iniciar sesión en diferentes aplicaciones cliente y podría tener un token de actualización por aplicación. Si el usuario pierde un dispositivo con una aplicación instalada, el token de actualización de ese dispositivo podría invalidarse sin afectar a los otros dispositivos conectados.

3) En esta implementación, responde al método de inicio de sesión con token de acceso y token de actualización. Me parece correcto.