session management jwt refresh token

Here’s a practical overview of session management with JWT + refresh tokens.

Core idea

Use two tokens:

1. Access token

   • Short-lived
   • Sent with API requests
   • Usually expires in minutes

2. Refresh token

   • Long-lived
   • Used only to get a new access token
   • Usually expires in days/weeks
   • Stored more securely than access token

---

Typical flow

1) Login

• User sends username/password.
• Server validates credentials.
• Server returns:
  • access_token
  • refresh_token

2) API requests

• Client sends access_token in Authorization: Bearer <token>.
• Server verifies JWT signature and expiry.
• If valid, request is allowed.

3) Access token expires

• Client gets 401 Unauthorized.
• Client sends refresh_token to refresh endpoint.
• Server validates refresh token.
• Server issues a new access token, and often a new refresh token too.

4) Logout

• Server invalidates refresh token server-side.
• Client deletes both tokens.

---

Why use refresh tokens?

JWT access tokens are stateless and fast, but if you make them long-lived, stolen tokens are dangerous.

Refresh tokens let you:

• keep access tokens short-lived
• reduce risk if access token is stolen
• manage sessions more safely

---

Best practices

1) Keep access tokens short-lived

Common lifetime:

• 5–15 minutes

2) Rotate refresh tokens

Every time refresh is used:

• issue a new refresh token
• invalidate the old one

This helps detect token theft.

3) Store refresh tokens securely

Depends on client type:

Web apps

• Prefer HttpOnly Secure cookies
• Avoid localStorage for sensitive tokens if possible

Mobile apps

• Use secure storage like Keychain / Keystore

SPAs

• Often use HttpOnly cookies with CSRF protection

4) Track refresh tokens server-side

Even with JWTs, refresh tokens are often stored/recorded in DB:

• token id / jti
• user id
• expiry
• revoked status
• device/session info

This enables:

• logout
• token revocation
• session listing
• reuse detection

5) Detect refresh token reuse

If an old refresh token is used after rotation:

• assume compromise
• revoke the whole token family/session

---

Common architecture

Access token

• JWT
• self-contained claims:
  • user id
  • roles
  • expiry
  • issuer
  • audience

Refresh token

• Often opaque random string
• Stored hashed in DB
• Associated with a user/session

This is common because refresh tokens don’t need to be JWTs.

---

Example sequence

1. User logs in
2. Server returns:
   • access token: 15 min
   • refresh token: 30 days
3. Client uses access token for requests
4. Access token expires
5. Client calls /auth/refresh
6. Server checks refresh token
7. Server returns new access token + new refresh token
8. Old refresh token becomes invalid

---

Security concerns

• Don’t put refresh tokens in browser localStorage if you can avoid it
• Use HTTPS always
• Use secure cookie flags:
  • HttpOnly
  • Secure
  • SameSite
• Implement revocation and rotation
• Protect refresh endpoint from CSRF if using cookies

---

Simple rule of thumb

• JWT access token = authenticate requests
• Refresh token = maintain login session safely

If you want, I can also give you:

1. a Node.js / Express example,
2. a Spring Boot example, or
3. a database schema for refresh token sessions.