Token revalidation

[luishdz1010]

Is there a way to check for an expired token and refresh it? I'm using the Auth0 strategy. I expected tokens to be checked for expiration on each request and get a new one if necessary. Is this supported by remix-auth, or how would I implement it?

[sergiodxa]

Token revalidation is out of the scope of Remix Auth and this strategy in particular.

There are multiple ways you could support this:

1. Keep the access and refresh tokens and the expiration date in a database, then run a background job to refresh all expired or near to expire tokens.
2. Keep the same data on the session, then wrap the authenticator.isAuthenticated function to check for that, I wrote about this approach here https://sergiodxa.com/articles/working-with-refresh-tokens-in-remix.

There's probably more things you could do but I think those are the simplest ones.

As a side note, remember you may not need the access token, you only need it if you plan to use the provider API as the authenticated user (e.g. use the user GitHub's access token to fetch private repos), if you only need to know who is the user with the profile object you got from the provider on the strategy callback you will have everything the provider knows about the user, after that you can find or create the user account on your own database and stop caring about the provider tokens.

[bk-jb]

Without knowing how much energy you actually plan to put into remix-auth anymore anyway, I'd kinda like to vote for saying that the statement

Token revalidation is out of the scope of Remix Auth and this strategy in particular.

is a surprising one, at best.
Token authentication without checking for expiration is honestly just broken. Nobody could seriously use it that way. Your library totally should point to that issue and help solving it. You even have that

if (params.get("grant_type") === "refresh_token") {
  params.set("refresh_token", code);
}

in fetchAccessToken token.
Why not make it reachable. Or like provide an updateToken function?

And you could delegate an optional validation of the session in authenticator.isAuthenticated to the strategy whose name is saved in the session anyway, so you wouldn't even need to publish a breaking change. And then make the OAuth2 strategy check for expiration. So that people would need to put that updateToken in their flow.

At least, if you're still serious about remix-auth.

[sergiodxa]

Remix Auth is heavily inspired on Passport.js, and its scope it's based on what Passport.js also supports.

Refreshing tokens is not something that involves Remix Auth because the scope of the library is to let you know who is the user, that's achieved once the strategy verify callback is executed, what you store on your DB and return to save in the session after that depends on your app.

The usage of an access token is a backend related thing, I recommend to keep both tokens and the expiration date on a database, and refresh them on the background instead of on every request as an updateToken method would have to do.

Again, keeping an access token around is something app specific, you should only do that if you plan to keep fetching the identity provider API as the authenticated user, the OAuth2 strategy and all strategies extending it gives you the user profile (to know who is the user), the access and the refresh tokens, and you also get an additional extraParams object where you can receive when your token expires.

About updating the token on the authenticator.isAuthenticated method, that method can't have code specific for refreshing access tokens because that would mean the Authenticator would have to know about the strategies internal implementation, e.g. the FormStrategy doesn't have access tokens.

Also the access and refresh tokens would have to be kept on the session always for that or an updateToken method to work, even if the app doesn't need them.

Which also mean if the app only use an identity provider to know who is the user and ignores the access token we would be refreshing the token just for the sake of doing that.

And yes, I'm still serious about Remix Auth.

BTW, you could create your strategy and implement an updateToken method, the SupabaseStrategy does that to let you interact with specific methods of Supabase and one of them let you refresh a token. This strategy doesn't even extend the OAuth2Strategy since Supabase doesn't use OAuth2.

[bk-jb]

Yea, well, okay, maybe I've misunderstood the scope of what remix-auth-oauth2 wants to provide. Thanks for replying and pointing to the supabase strategy, though. We actually have implemented a flow comparable to this strategy based on remix-auth-oauth2 for our use case.

[luishdz1010]

Thanks for taking the time of answering @sergiodxa, this does help clear things up a bit.

@bk-jb Any chance you could share any implementation bits of your revalidation strategy?

[bk-jb]

Actually, we have revamped the whole flow a bit. We don't use this package here but have built a strategy like this with 2 major differences:

• We don't require the callbackURL that is sent to the authentication server to be different from the original request's URL. That is, we don't do if (url.pathname !== callbackURL.pathname) as this strategy here does in authenticate. Instead, we check whether the headers state and code are there (as they are set by the authentcation server when it redirects back, and used to query the token and put it in the session, as you, too, can see in authenticate of this strategy. This makes it easier for the user to be sent back to where she wanted to go before she was redirected to the authentication server to enter her credentials.
• Secondly, we don't terminate the flow with a 401 on error responses of the authentication server, but we delete the session and restart the authentication flow. This is necessary for token revalidation because your refresh token may be expired, too. In this case, you don't want to see a 401 but be redirected to the authentication server again.

Based on this, we added an updateToken method to our strategy. To bring it to use, we wrote a little utility function that does a "normal" authenticator.isAuthenticated, and if it returns a user, it takes a look in the access token (that we, of course, store in the user that is stored in the session, together with the refresh token), basically like this:

const tokenPayload = JSON.parse(Buffer.from(user.accessToken.split('.')[1], 'base64').toString());
const expiresInSec = tokenPayload.exp - Math.ceil(new Date().getTime() / 1000);

Only if it is not expired, it will return the user. Otherwise, we request a new access token from the authentication server using our updateToken method. We update the user, store it in the session. And since we use cookie session, we commit the session and redirect to the original request's URL to make the client store the cookie with the now updated access token. That basically looks like this:

  async updateToken(request, user, sessionStorage, options) {
    // fetch the refreshed token and user data
    const params = new URLSearchParams(this.tokenParams());
    params.set('client_id', this.clientID);
    params.set('client_secret', this.clientSecret);
    params.set('grant_type', 'refresh_token');
    params.set('refresh_token', user.refreshToken);
    const response = await fetch(this.tokenURL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
      body: params,
    });
    if (!response.ok) {
      // happens e.g. if the refresh token has expired, too
      throw await this.forceReLogin(request, sessionStorage, options);
    }

    // create new user object with updated data
    const { accessToken, refreshToken, extraParams } =
      await this.getAccessToken(response.clone());
    const profile = await this.userProfile(accessToken);
    try {
      user = await this.verify({
        accessToken,
        refreshToken,
        extraParams,
        profile,
      });
    } catch (error) {
      throw await this.forceReLogin(request, sessionStorage, options);
    }

    // save new data in session
    const session = await sessionStorage.getSession(
      request.headers.get('Cookie'),
    );
    session.set(options.sessionKey, user);
    throw redirect(request.url, {
      headers: {
        'Set-Cookie': await sessionStorage.commitSession(session),
      },
    });
  }

  async forceReLogin(request, sessionStorage, options) {
    const session = await sessionStorage.getSession(
      request.headers.get('Cookie'),
    );
    session.unset(options.sessionKey);
    throw redirect(request.url, {
      headers: { 'Set-Cookie': await sessionStorage.commitSession(session) },
    });
  }