Cuando el token de acceso caduca, utiliza el token de actualización para obtener un nuevo token de acceso.

Esto funciona porque el token de actualización tiene una larga vida, normalmente hasta 30 días (pero puede ser incluso más larga si lo desea).

Ejemplo:

• El usuario cierra el navegador
• Vuelve 10 días después
• El usuario envía una solicitud al servidor
• El servidor devolverá una respuesta no autorizada 401 porque el token de acceso ha caducado
• Su aplicación enviará una solicitud para obtener un nuevo token de acceso utilizando el token de actualización
• Si el token de actualización es válido, el servidor devolverá un nuevo token de acceso
• Si el token de actualización caduca, el servidor devolverá una respuesta 401. Eso significa que el usuario necesita iniciar sesión nuevamente.

Consideraciones de Seguridad

Personalmente, creo que JWT para la mayoría de las aplicaciones web no es una idea adecuada debido a las opiniones contradictorias y los consejos sobre cómo almacenar los tokens de forma segura.

Dado que un token de actualización es realmente poderoso, no se recomienda almacenarlo en el navegador. Entonces, ¿dónde lo guardas? Y ahí es cuando esta idea engañosa de los servicios web "sin backend" impulsados por JWT comienza a desmoronarse.

Paradojas con respecto al almacenamiento de tokens:

1. Guárdelo en almacenamiento local : Vulnerable a ataques XSS.
   Esto es realmente grave porque las vulnerabilidades XSS también pueden provenir de bibliotecas JS de terceros, no solo de su propio código. Los piratas informáticos pueden secuestrar una biblioteca de terceros en NPM para inyectar código malicioso y, sin saberlo, es posible que la esté utilizando en su proyecto (podría ser una dependencia de una dependencia de otra dependencia...).

2. Guárdelo en cookies httponly : a salvo de ataques XSS, pero requiere un servidor back-end propio (porque los servidores de autenticación de terceros no pueden establecer cookies para otro dominio).
   Si se detiene a pensar en ello, notará que este caso es exactamente similar a la autenticación de sesión regular donde se guarda un token de sesión en la cookie. Entonces, ¿por qué no usar la autenticación de sesión en lugar de esta complicada configuración de JWT?

Le aconsejo que investigue a fondo esto y decida si realmente necesita JWT para sus aplicaciones web.

Autenticación JWT usando cookies de origen cruzado

Dado que menciona que sus aplicaciones frontend se conectan a un servidor API en otro dominio, parece correcto usar JWT.

Si controla el servidor API, puede configurar encabezados CORS para permitir que el servidor API establezca cookies en los dominios de sus aplicaciones.

Importante:
Dado que se trata de cookies, es vulnerable a los ataques CSRF. Pero > eso es más fácil de prevenir usando tokens CSRF. Eso significa que, con cada solicitud POST, deberá enviar el token CSRF y el servidor API también debe validar ese token CSRF.

Aquí hay un diagrama que hago del flujo de autenticación en ese caso:

Para la Pregunta 2, agregue este código en su archivo settings.py

 SIMPLE_JWT = { 'ACCESS_TOKEN_LIFETIME': timedelta(days=30), 'REFRESH_TOKEN_LIFETIME': timedelta(days=30), }