Refresh Tokens in JWT Authentication

Common refresh token strategies used in backend services for JWT token based authentication.

• JWT Token - Short lived tokens with user details and other metadata.
• Refresh Token - Long lived tokens used to get new JWT tokens.

Firebase

Firebase Docs

Firebase Authentication sessions are long lived. Every time a user signs in, the user credentials are sent to the Firebase Authentication backend and exchanged for a Firebase ID token (a JWT) and refresh token. Firebase ID tokens are short lived and last for an hour; the refresh token can be used to retrieve new ID tokens. Refresh tokens expire only when one of the following occurs:

The user is deleted The user is disabled A major account change is detected for the user. This includes events like password or email address updates. The Firebase Admin SDK provides the ability to revoke refresh tokens for a specified user. In addition, an API to check for ID token revocation is also made available. With these capabilities, you have more control over user sessions. The SDK provides the ability to add restrictions to prevent sessions from being used in suspicious circumstances, as well as a mechanism for recovery from potential token theft.

Read more

• JWT Tokens(called ID Tokens) valid upto 1hr
• Refresh Tokens never expire
• Refresh Tokens stored in the database
  • Can be revoked
  • Login on multiple devices can be managed
• Refresh Tokens can be used to get new JWT Tokens
• SDK automatically refreshes the token internally - auth.currentUser.getIdToken(/ forceRefresh / true)
• Other ways - https://stackoverflow.com/questions/38233687/how-to-use-the-firebase-refreshtoken-to-reauthenticate

Supabase

Docs

Read more

• JWT tokens(called access token) valid 5min-1hr
• Session = Session ID + (JWT Token + Refresh Token), stored in auth.sessions table.
• session_id in jwt claim
• Session created on sign-in
• Refresh token can only be used once to get a new (JWT Token + Refresh Token) pair (todo does it have the same session id?)
• Session termination
  • The user clicks sign out.
  • The user changes their password or performs a security sensitive action.
  • It times out due to inactivity.
  • It reaches its maximum lifetime.
  • A user signs in on another device.
• Session expiry and limit number of allowed sessions. (Paid feature lol)
  • Time-boxed sessions, which terminate after a fixed amount of time.
  • Set an inactivity timeout, which terminates sessions that haven't been refreshed within the timeout duration.
  • Enforce a single-session per user, which only keeps the most recently active session.

AWS Cognito

AWS Cognito Docs

Read more

Same as firebase but

• Refresh Tokens are valid for 30 days by default (can be changed)
• Also has UnusedAccountValidityDays
• Has SDK?

PocketBase

Pocketbase Docs

No docs related to that

• https://github.com/pocketbase/pocketbase/discussions/2154#discussioncomment-5425468

From what I found from reading the code

• No refresh token per-se. Tokens can be used to get new tokens
• No tokens stored in database.
• Token key stored in the users table (added to the jwt secret). Can be changed to revoke tokens.
• Hits DB for the token validation on every request to get the secret
• Token expiry = refresh token expiry. Can get a new token as long as the old one is valid. - not sure about this.

Superuser UI refreshes the token automatically when receiving 403 from the server.

Auth0

Blog

https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

• Token reuse detection - Invalidate the complete session if any old (or invalid?) refresh token is used.

Teenybase

Note - WIP

• On login - create session id, refresh token, jwt token
• Store session id and refresh token in the database
• JWT Token - Short lived tokens (5min - 1hour) with user details and other metadata.
• Refresh Token - Long lived tokens used to get new JWT tokens. One time use.
• Automatically refresh token in client SDK if token is expired, also auto check with 401 response from the server.
• Revoke sessions by deleting the session id from the database.
• Limit number of active sessions per user by checking number when creating and refreshing a session. (what if someone creates 100 at once)
• refresh token expiry = inactivity timeout (like 7 or 30 days)
• session id expiry = require re-login after 30 days
• max token refresh to limit number of times token is refreshed
• todo - store ip etc in session, allow to refresh only if ip match
• todo - check session id existence db in every request by passing as raise exception statement if invalid, allows instant invalidation of session
• todo - store used refresh tokens and invalidate the session if reused