Use refresh tokens (and maybe smart expiry time) with JWT login flow

[n8kim1]

JWT allows for refresh tokens. Right now, the frontend doesn't actually use them, cuz using them is a lot of work. But it'd be nice to!

In particular, because we only use access tokens, people will get locked out quickly -- 5 minutes by default. This can be altered by configuring the access token life (in the backend), to, eg, an hour. But still, the lack of using refresh tokens makes for worse practices, and makes for a more painful user experience.

Do this only if you decide to port to OAuth2 later, see #169. If you want to port to OAuth2 first, then you should just build a refresh flow into the OAuth2-based frontend

See these links for examples of creating a refresh flow by using jQuery's ajax prefilter, which does some stuff before every Ajax HTTP call. In particular, we'd want to validate the access token, and if that fails, get a refresh token, and then carry out the original HTTP request:

• https://gist.github.com/joshmcarthur/16f61bdd971fe1afa17c214578a5ec65
• https://stackoverflow.com/questions/45986487/run-ajax-request-after-jwt-refresh
• https://stackoverflow.com/questions/11793430/retry-a-jquery-ajax-request-which-has-callbacks-attached-to-its-deferred

Also, note that you should securely store refresh tokens if possible. It's not the best idea to store them in cookies/local storage, although that's ok, just not ideal:

• https://stackoverflow.com/questions/57650692/where-to-store-the-refresh-token-on-the-client

By the way, if this is done, change the access token lifetime (as defined on server) back to something reasonable

[j-mao]

https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/#silent-refresh