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.
- 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
- 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
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
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.
Superuser UI refreshes the token automatically when receiving 403 from the server.