Refresh token

[guanacone]

Backend implementation to attribute and save a refresh token to the DB.

The idea is to save a refresh token when a user logs in that can be checked and used to emit a new token if the user makes a request with an expired token.

[guanacone]

Seems that the issue is coming form gatsby-plugin-node but can point why... Can you assist?

[edwmurph]

left a few comments that might fix the problem you're seeing. also is there a particular guide you're following for setting up refresh tokens that you could share? looks like you want the server to automatically refresh the token?

[edwmurph]

nice this looks like the new LTS for node but now you should also make sure the Dockerfile and github workflows are updated to also use this node version

you could update your github actions to automatically use the value in the nvmrc

or it looks like nvm was added to the github action virtual environments so you could also just update your github actions to use nvm directly

[guanacone]

left a few comments that might fix the problem you're seeing. also is there a particular guide you're following for setting up refresh tokens that you could share? looks like you want the server to automatically refresh the token?

The idea is that when a user logs in a refresh token is saved to the DB and deleted when he logs out. On the front end if a response comes back with a status code 404 and if there's a expired token it will retrieve the refresh token from the DB and if there's a refresh token hit a refresh route to get a new token. (Not sure where exactly on the front end, maybe in the getContent()?)

I did find several tutorials on how to implement the refresh token on the backend but could't find anything good on the client side...

[edwmurph]

i think the build issue you were seeing was caused by other issues and these downgrades can probably be reverted

[edwmurph]

The idea is that when a user logs in a refresh token is saved to the DB and deleted when he logs out. On the front end if a response comes back with a status code 404 and if there's a expired token it will retrieve the refresh token from the DB and if there's a refresh token hit a refresh route to get a new token.

it might help to get a complete picture to update the logout route to delete the refresh token in this iteration?

also it looks like this implementation doesnt pass the refresh token back to the user but i read a few articles on this and it looks like they all suggest passing the refresh token back to the user. and then when the user needs to get a fresh token, it passes that refresh token in the request. otherwise anyone could get a refreshed token without auth?

also it would help if you also implemented the route for refreshing the token in this iteration (assuming you're implementing refresh in that way) so we can make sure refreshing a token automatically works. it's probably good tho to ya at least defer the frontend implementation for this to a separate PR

[edwmurph]

this refresh token should probably have some expiration like 24 hours or something

[guanacone]

Just to let you know that I couldn't do much over the weekend. We got hit by a major hurricane (cat. 4) on Wednesday and it rained over a foot in 4days. We're pretty much without power and internet till today. Will get back to it ASAP.

[edwmurph]

wow that's crazy hope you guys are doing ok. thanks for the update

[guanacone]

Yeah, we had some intense moments, but we're fine.

I spoke yesterday with a friend who is also a developer and he recommended the following approach:

1. API emits JWT at login with a expiration date of a couple days (shorter for an API with sensible data),
2. Frontend sets an interval to hit the refresh route of the API a couple of seconds before the JWT expires. Logic should be implemented to automatically to refresh the JWT on page reload (i.E. if the user closes the browser and comes back later, if by then the JWT is expired, user will need to login agin).
3. At logout JWT will be saved to blacklist.

What do you think?

[edwmurph]

ya i think something along those lines should work but only thing is how is the refresh route authenticated? doesn't the refresh token need to be given to the client?

wouldn't the flow need to be something like:

1. login returns jwt token for standard requests and also refresh token to the client
2. client holds both tokens in local storage
3. on page reload, fetch fresh jwt token using refresh token and setTimeout to refresh token again when it will expire
4. on logout, blacklist both tokens
   ?

[guanacone]

how is the refresh route authenticated
with the same JWT that was emitted at login.

Where in gatsby would the the logic for setTimeout an on page load go? I believe this would need to go at toplevel of the app and not in a specific component or page?

[edwmurph]

there's a couple ways you could do this:

• https://www.gatsbyjs.com/docs/browser-apis/#wrapRootElement
• https://www.gatsbyjs.com/plugins/gatsby-plugin-layout/ to wrap all pages in a standard layout and put whatever toplevel code you want to run in a useEffect in the layout component

[guanacone]

I will close this PR and start fresh.