[Auth] Refresh token flow

[awpt1mus]

• currently only access token is being returned after successful login as per standard practices with JWT token authentication , this access token has very short expiry (15 to 20 mins).
• without refresh token the user will have to login again and again after the access token expires
• by implementing refresh token flow , on successful login the client receives 2 tokens,
  • access token - short lived token to be used for protected routes
  • refresh token - long lived token to be used to get new access token when it expires. (typically expires in 1-30 days)
• new endpoint will be added under auth routes /refresh which will expect a refresh token (via cookie / body) and on successful validation return a new access token back.
• when refresh token itself is expired then user will be forced to login as per standard practice.
• Should refresh tokens be stored in database for revoke mechanism ? TBD

[JustDaile]

Should refresh tokens be stored in database for revoke mechanism.. I wouldn't suggest that. Personally, I'd store them in a http only, secure cookie and delete that cookie to revoke.

[awpt1mus]

Should refresh tokens be stored in database for revoke mechanism.. I wouldn't suggest that.

Personally, I'd store them in a http only, secure cookie and delete that cookie to revoke.

If we are storing token in cookie only, how do we handle a scenario where we need to ban a user immediately. If the token is stored in db , we can mark it as revoked then user sends a request to get new access token , they won't get one because we revoked their refresh token. Plus we also mark user as banned so they can't logic and get new refresh token.

[JustDaile]

I'm not sure why we are adding banning, but I would have a new table schema and foreign key for the user. Create a repository for managing banning users, then inject the repository as a dependency in our user service. That way user service can lookup to see if user is banned and banning is its own standalone feature.

[awpt1mus]

Okay forget about banning a user, consider this - a user reports that their refresh token is stolen and being used to do unusual activity on their profile , basically their profile is hacked. In this case we need ability to mark stolen refresh token as revoked.

[JustDaile]

This is why you have short lived tokens and secure refresh tokens. They hacker may gain access via a short lived jwt but it might be much harder to get hold of the refresh token, since we can lock it down. IE we could make it usable from a specific IP address and user agent (browser) such as the one it was issued too. Plenty of other solutions I suppose but it really depends.

[awpt1mus]

Alright,i guess we will address revoking strategy later.