Django SimpleJWT: Some questions with token authentication

I am implementing authentication in Django using SimpleJWT, and have a few questions regarding the same. To give some background I have multiple domains with my backend, some with normal login (username and password), and some with SSO logins.

Question 1: For normal login, I pass username and password in the payload to TokenObtainPairView API, and it gives me access and refresh tokens. How can I get the access and refresh tokens in SSO login, since it does not have any password?

Question 2: Suppose, I store the access tokens in local storage and send the access token to all APIs, and I'm also refreshing it before it expires. But what will happen if the user closes the browser, and we are not able to refresh the access token. The access token expires and the user gets logged out. How can we keep the user logged in for a certain amount of time (say 30 days)?

Question 3: The username and password passed in the payload are visible in the curl, is this a security issue? How can I deal with this?

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),
}

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 web apps is a bad 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 break 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.

Back to Top