When the Access token expires, you use the Refresh token to obtain a new Access token.

This works because Refresh token has a long life, typically up to 30 days (but can be even longer if you want).

Example:

• User closes browser
• Comes back 10 days later
• User sends a request to the server
• Server will return 401 Unauthorized response because Access token has expired
• Your app will send a request to obtain a new Access token using the Refresh token
• If the Refresh token is valid, server will return a new Access token
• If the Refresh token is expired, server will return a 401 response. That means user needs to login again.

Security considerations

Personally, I think JWT for most web apps is not an suitable idea because of conflicting opinions and advice on how to securely store the tokens.

Since a Refresh token is really powerful, it is not advised to store it in the browser. So where do you store it? And that's when this misleading idea of "backendless" web services powered by JWT starts to fall apart.

Paradoxes regarding storing tokens:

1. Store it in localstorage: Vulnerable to XSS attacks.
   This is really serious because the XSS vulnerabilities can also come from third party JS libraries, not just from your own code. Hackers can hijack a third-party library on NPM to inject malicious code and you might be unknowingly using it in your project (it might be a dependency of a dependency of another dependency...).

2. Store it in httponly cookies: Safe from XSS attacks but requires a first-party backend server (because third-party auth servers can't set cookies for another domain).
   If you stop to think about it, you'll notice that this case is exactly similar to the regular session auth where a session token is saved in the cookie. So why not just use session auth instead of this complicated JWT setup?

I'm going to advise you to thoroughly research this and decide whether you really need JWT for your web apps.

JWT auth using cross-origin cookies

Since you mention that your frontend apps connect to an API server in another domain, using JWT seems alright.

If you control the API server, you can setup CORS headers to allow the API server to set cookies on your apps' domains.

Important:
Since this involves Cookies, it is vulnerable to CSRF attacks. But > that is easier to prevent using CSRF tokens. That means, with every POST request, you'll need to send CSRF token and the API server must also validate that CSRF token

Here's a diagram I make of the auth flow in that case:

For Question 2, add this code on your settings.py file

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