Best Practices for Securely Refreshing Auth Tokens: Seeking Feedback on My Session-Based Solution

Hey all!

So after reading about different ways to refresh the user auth token - I would like to make sure Im using best practices in the process

My main goal is to keep the user logged in for as long as possible while keeping it secure

After reading some of Ray Deck recommendation on how to build a refresh mechanism I reached this solution Im thinking of:

When the user logs in an auth token is created (1 hour expiry) and a session is created (with 1 week expiry). The session will hold a refresh token. Both are stored as cookies on the user, with the auth token expiry timestamp as well

(Im thinking of a session table to store the refresh token because I understand its more secure than actually saving the refresh token itself in the frontend)

Then:

If the front end recognizes that the auth token timestamp is coming soon, or after a bad auth request was made - it will send a request to refresh the auth token and send the session_id which was saved on the front end as parameter

Then the refresh api will make sure the session was not expired (or banned) and generate a new auth token to be sent to the front end

I would love to get some feedback from the community about this implemenation:

  1. Would you say this is best practice?

  2. How would you handle the refresh tokens? Ive seen recommendation to update the session expiry date & refresh token every time I refresh the auth token

  3. I guess this approach means that if a session expired the user will have to log in again. Are there ways to keep him logged in longer? in my current bubble app users can come back after long periods of time and still be kept logged in

Thanks!!!

1
2 replies