Best practice for JWT Sessions with accessToken & refreshToken

[BenjaminWFox-Lumedic]

Background/Context
In my application, my initial sign-in flow looks like:

1. User signs in with Azure AD B2C user flow
2. Application adds the accessToken & refreshToken to the NextAuth JWT in the callback
3. Application decrypts the NextAuth JWT in the API to retrieve the accessToken for downstream API call

Per this question in the FAQ my understanding is that 'Access Token rotation' refers to the process of checking the accessToken iat vs exp myself, and then if it is expired, using the refreshToken to get a new accessToken - so I need to handle that myself, or risk a situation where there is a valid NextAuth session but the users accessToken is no longer valid.

Your question

• Is my above understanding of 'Access Token rotation' correct?
• There is an accessTokenExpires property on the account during initial signin - this looks like it's specifically for database adapters? Does it have any other purpose?

What are you trying to do
Make sure I correctly handle scenarios not covered by NextAuth without doing unnecessary work due to misunderstanding terminology or functionality.

Feedback
Documentation refers to searching through online documentation, code comments and issue history. The example project refers to next-auth-example.

• Found the documentation helpful
• Found documentation but was incomplete
• Could not find relevant documentation
• Found the example project helpful
• Did not find the example project helpful

[EthanNC]

I'm looking for an answer to this question, but more specifically when the provider doesn't use refreshTokens. I know the user will have to re-link their account. But how do I force that in my code without removing the account record from my database?

[abeluck]

I found this issue when searching for details on the refresh, access tokens, and expiry time in the database adapter implementation.

These 3 values seem to be unused. As per the linked FAQ

Note: NextAuth.js does not current handle Access Token rotation for OAuth providers for you, if this is something you need, currently you will need to write the logic to handle that yourself.

These values are here for you to use if you need them, it seems.

1. If your provider supports refresh tokens, you'll have to manually refresh them before the expiry period (which isn't captured explicitly)
2. If your provider does not support refresh tokens or your refresh token has expired.. then this is where things get dicey

When a user comes back and signs in again, then next-auth will allow the user, but the stored access, refresh, and access token expiry values are never updated. Indeed, the adapter interface provides no mechanism to update those values.

You cannot delete the account record from the database without also deleting the user record, or you will hit #876

So to use refresh and access tokens reliably, you'll need to use the signIn or jwt callback to capture the new access/refresh tokens from the account parameter and update them in your database/backend.

[liuxiaofeng1981]

When it comes to refresh oauth tokens I'm experiencing issues which I believe is related to cookie size limit. I use AWS Cognito and need to persist not only access token but also refresh token in the jwt callback. It works fine. I handle access token rotation inside the jwt callback manually (as next auth currently does not support it), when access token expired I use the persisted refresh token to get new access token. Except, I found every time when I first time authenticated with Cognito, it gets oauth tokens and then it logs me out. A subsequent login is succesful without the need to enter username and password on Cognito hosted UI again so that means it's already authenticated with the auth provider on the first login. And everything after works fine, no kicking me out after login.

As soon as I removed persisting refresh token in the jwt callback everything works perfect. I understand this is a limitation of cookie size limit itself but also it's very common use case that both access & refresh tokens are required to be persisted in http only cookie. I'm looking for some suggestions or workaround, other than say persist one or both tokens in localstorage? But then that defects the purpose of using NextAuth in the first place as I think the way it automatically handles all those are great.

    callbacks: {
      jwt: async (token, user, account) => {
        const isSignIn = !!user
        if (isSignIn) {
          const { accessToken, refreshToken } = account
          setNextAuthToken(token, accessToken, refreshToken)
        } else {
          // Reaches here whenever session is accessed from client / server, eg. useSession, getSession etc
          logger.info(`JWT callback after sign in ${JSON.stringify(token)}`)
          const timeToRefresh = addMinutes(token.authTime * 1000, RefreshAuthInterval)
          const shouldRefresh = isAfter(new Date(), timeToRefresh)
          logger.info(`shouldRefresh: ${shouldRefresh}, timeToRefresh: ${timeToRefresh}`)
          if (shouldRefresh) {
            const refreshResult = await refreshAuthToken(token.savedRefreshToken)
            if (refreshResult?.AccessToken) setNextAuthToken(token, refreshResult.AccessToken)
          }
        }
        return Promise.resolve(token)
      },
      session: async (session, jwt: NextAuthJWT) => {
        // Add property to session
        session.accessToken = jwt.savedAccessToken
        logger.info(`session callback ${JSON.stringify(session)}`)
        return Promise.resolve(session)
      }
}