authExchange: proactively update authState

[wereHamster]

I'm using authExchange with a pretty standard JWT-based auth flow. Since the access tokens are short lived, I expect that willAuthError / didAuthError will trigger frequently, causing re-auth. Since our JWTs include an expiration time, I could use that to proactively update the authState even before the JWT actually expires.

I see several options how to ingrate that feature:

1. Extend addAuthToOperation: if I detect that the JWT is about to expire, somehow tell authExchange to trigger an async getAuth flow.
2. Allow a soft failure from willAuthError: indicate to the authExchange to run the operation as usual, but also the getAuth flow in parallel to that.
3. Have another callback that is dedicated to that feature (eg. shouldAuth). The authExchange would call this function during each request, and if it returns true then trigger an async getAuth.

[JoviDeCroock]

A solution that I've used is to use willAuthError to check expiry time and do something like:

if (isAboutToExpire(authState.token)) {
  authState.shouldRefresh = true;
  return true
}

This will put you into getAuth where you can get your regular token or check the shouldRefresh and initiate a refreshToken request.

[wereHamster]

That will still incur the delay of refreshing the token before the request. Ideally I'd like to avoid it and refresh the token in parallel to any other requests which may be fired around the same time. Something like:

• [T-55s] A regular GraphQL request is about to be sent. I detect that the JWT is about to expire and signal to the auth exchange to proactively run getAuth.
• [T-53s] GraphQL request successfully completes.
• [T-51s] A regular GraphQL request is about to be sent. I again signal to the auth exchange to run getAuth. But because the request is already running the auth exchange will not send another one.
• [T-50s] GraphQL request successfully completes
• [T-45s] getAuth completes, the auth exchange updates the authState.
• [T-30s] Another GraphQL request is about to be sent. The authState now contains the JWT with an expiration time far in the future (so it's actually T-7200s now).

(T=0 is when the token expires)

[kitten]

You'll have to write your own auth state management and use it in parallel. This isn't uncommon; you'd probably want some kind of auth singleton that manages your token and return it in the authExchange's getAuth to use it as your regular state in there.

I'd actually say though that if you're worried that your access tokens are too short lived, the solution isn't to send requests more often. The solution is to make them live longer.
I know this may be obvious but I do want to note that if you're auth endpoint becomes degraded or slow, or you have a user on a mobile connection, extremely short-lived access tokens become an issue. So making sure that they at least live for 20min.