The JWT token – Best Practices

Storing a JWT (JSON Web Token) securely is crucial to maintaining the security of your application. Here are some common storage options, along with their pros and cons:

1. Local Storage

• Pros:
  • Easy to implement.
  • Tokens persist across page reloads and browser sessions.
• Cons:
  • Vulnerable to Cross-Site Scripting (XSS) attacks, which can expose the token to attackers.

2. Session Storage

• Pros:
  • Easy to implement.
  • Tokens are cleared when the browser window/tab is closed, providing better security than local storage.
• Cons:
  • Still vulnerable to XSS attacks.
  • Tokens do not persist across browser sessions.

3. Cookies

• Pros:
  • Cookies can be marked as HttpOnly, making them inaccessible to JavaScript and reducing the risk of XSS attacks.
  • Cookies can also be marked with the Secure attribute to ensure they are only sent over HTTPS.
  • Tokens can be set to expire automatically via the expires or max-age attributes.
• Cons:
  • Vulnerable to Cross-Site Request Forgery (CSRF) attacks unless proper CSRF protections are in place.
  • May require additional configurations for cross-origin requests (e.g., with CORS and SameSite policies).

4. Memory (In-memory storage)

• Pros:
  • Very secure as tokens are stored in the memory and not exposed to XSS attacks.
  • Tokens are cleared when the user refreshes the page or closes the browser.
• Cons:
  • Tokens do not persist across page reloads or browser sessions.
  • Can be cumbersome to implement for larger applications, as you may need to handle token persistence in other ways.

Best Practices

• Short-Lived Tokens: Use short-lived access tokens and refresh tokens to minimize the window of opportunity for attackers.
• Refresh Tokens: Store refresh tokens securely (usually in HttpOnly cookies) and rotate access tokens frequently.
• Secure Transmission: Always use HTTPS to prevent token interception during transmission.
• Token Expiry: Implement proper token expiration and invalidation strategies to reduce the risk of token reuse.

The most secure place to store a JWT token is in a HttpOnly cookie with the following attributes:

1. HttpOnly Flag

• Description: This flag ensures that the cookie cannot be accessed or modified via JavaScript, which mitigates the risk of Cross-Site Scripting (XSS) attacks.
• Benefit: Protects the JWT from being stolen by malicious scripts running on the client side.

2. Secure Flag

• Description: This flag ensures that the cookie is only sent over HTTPS, preventing it from being transmitted in plaintext over unencrypted connections.
• Benefit: Ensures the JWT is not exposed to man-in-the-middle attacks.

3. SameSite Attribute

• Description: This attribute controls whether the cookie is sent with cross-site requests. Setting it to Strict or Lax can help mitigate Cross-Site Request Forgery (CSRF) attacks.
• Benefit: Adds an extra layer of security by limiting when the cookie is sent to the server.

4. Short-Lived Tokens

• Description: Use short-lived access tokens and refresh tokens, and rotate them frequently.
• Benefit: Limits the impact if a token is compromised.

5. Token Rotation and Expiry

• Description: Implement token rotation (with refresh tokens) and ensure tokens expire after a short period.
• Benefit: Reduces the risk of prolonged exposure if a token is intercepted.

Storing a JWT in a HttpOnly, Secure, and SameSite cookie is considered the most secure option. This method protects the token from XSS attacks (since it can’t be accessed via JavaScript) and ensures it is only sent over secure connections, mitigating risks associated with token theft and unauthorized access.

Can we store JWT token in backend and how?

Yes, you can store a JWT token in the backend, but it requires a different approach compared to client-side storage. Storing JWTs on the server side can enhance security, especially for sensitive applications. Here’s how you can do it:

1. Storing the JWT in a Server-Side Session

• How It Works:
  • When a user logs in, generate a JWT and store it in a server-side session.
  • Associate the session with the user (e.g., via a session ID stored in a HttpOnly cookie).
  • The server can retrieve the JWT from the session on subsequent requests to verify the user’s identity.
• Implementation:
  • Session Creation: Upon successful login, generate the JWT and store it in a server-side session (e.g., Redis, database, or in-memory store).
  • Session ID: Send a session ID to the client as a HttpOnly cookie.
  • Session Lookup: For each incoming request, use the session ID from the cookie to retrieve the JWT from the server-side store and validate it.
• Pros:
  • Enhanced security: The JWT is never exposed to the client, reducing the risk of client-side attacks like XSS.
  • Centralized token management: You can easily revoke tokens by clearing the session on the server.
• Cons:
  • Requires server-side infrastructure to manage sessions.
  • Less scalable in stateless architectures, as it introduces state on the server.

2. Database Storage (Token Revocation and Blacklisting)

• How It Works:
  • Store JWTs in a database to keep track of active tokens.
  • Useful if you need to revoke or invalidate tokens before their natural expiration.
• Implementation:
  • Token Storage: When a JWT is issued, store it (or its unique identifier) in a database along with user information and an expiration time.
  • Token Lookup: On each request, check if the JWT is in the database and valid (e.g., not revoked or expired).
  • Revocation: If needed, remove the token from the database to effectively revoke it.
• Pros:
  • Full control over token lifecycle: You can revoke or invalidate tokens at any time.
  • Auditing and logging: You can track token usage for security audits.
• Cons:
  • Adds overhead to each request, as the server must query the database to validate the token.
  • Requires additional infrastructure to manage the token store.

3. Hybrid Approach (Combination of Client and Server Storage)

• How It Works:
  • Store short-lived access tokens in the client (e.g., HttpOnly cookie) and refresh tokens in the backend.
  • The refresh token can be stored in a database or server-side session, and used to issue new access tokens when needed.
• Pros:
  • Balances the benefits of client-side and server-side storage.
  • Reduces the frequency of database lookups while maintaining security.
• Cons:
  • Complexity: Requires careful implementation to manage both client-side and server-side tokens securely.

Summary

Storing JWTs on the backend provides greater security, particularly in sensitive applications where client-side storage might be vulnerable. You can store JWTs in server-side sessions, databases, or a combination of both, depending on your application’s needs. Server-side storage allows for centralized token management, easy revocation, and can mitigate risks associated with client-side attacks like XSS. However, it introduces complexity and may impact scalability in stateless architectures.