Various issues with refresh token rotation

[mtt87]

Description 🐜

Took me a bit of time but I think I finally understood why we were seeing so many errors related to refreshing the token in our app.

I'm following the suggested setup to refresh tokens https://next-auth.js.org/tutorials/refresh-token-rotation which works fine.

The issue is the broadcasting that if you have more than 1 tab open with your web app, it will trigger a session check for EVERY tab and then you end up triggering the refreshAccessToken() function multiple times simultaneously with the same set of parameters (same refresh_token)

This creates an issue because the first request will be successful and obtain a new access_token paired with a refresh_token while all the other calls that were made will get a 400 since the old refresh_token has just been invalidated by the first successful call.

Simplest way to fix this would be to have the option to disable broadcasting and let each tab try to refresh the session only when focused.

EDIT: 3 scenarios where this is a problem

• broadcasting getSession event when a session refresh is already in flight
• opening a new page when a session refresh is already in flight
• focusing a different tab when a session refresh is already in flight

Check here for a lock mechanism proposed solution:
#2071 (comment)

How to reproduce ☕️

In the app try to set a clientMaxAge of 10 seconds

      <AuthProvider
        session={pageProps.session}
        options={{
          clientMaxAge: 10,
        }}
      >

Then add a log in [...nextauth].js jwt callback

    async jwt(token, user, account, profile) {
      console.log('JWT')

Open 2 tabs and move between them, you will notice that every 10 seconds there are 2 calls being made to refresh the session and 2 console logs

JWT
JWT

I can create a codesandbox later after I finish work if needed but it's pretty simple to verify I believe 😄

I'm using "next-auth": "3.23.3"

[balazsorban44]

If true, that would be a very nice fix! So basically there is a race condition here, where two calls made to the /ap/auth/session endpoint will both try to refresh the token, and the second one finishing fails. Right?

[mtt87]

Yes correct, let me explain it better with a practical example.

Imagine you issue access_token that expire after 10 minute and a refresh_token that lasts for 1 month that you can use to refresh your access_token.

The way it works is that when you exchange the refresh_token you obtain a new access_token but also a new refresh_token, which means that the previous refresh_token is now invalid.

Now imagine a timeline where you have 3 tabs open with the same app my-app.com

00:00 the user opens my-app.com on a tab and login into the app, the user now has a session that contains

{ access_token: "at1", refresh_token: "rt1", expire_in: "15min" }

00:01 the user opens another tab with my-app.com and after a brief check, the user is already logged in because there is a valid session
00:02 the user opens another tab with my-app.com and after a brief check, the user is already logged in because there is a valid session
00:03 the user open another tab with a different website and starts reading an article for 5 minutes
-- 5 min later --
05:00 the user decides to go back to tabA where your app my-app.com is open, this triggers a broadcast of the session event to tell all the other tabs where your app is open to check the session
05:01 all the 3 tabs have made a call and the token is still valid so nothing happens, just to confirm we still have the originally exchanged access_token and refresh_token

{ access_token: "at1", refresh_token: "rt1", expire_in: "15min" }

05:02 the user opens another tab and keeps browsing
-- the user goes out for lunch, 30 min later --
35:00 the user is back from lunch and selects one of the my-app.com open tabs
35:01 the tab broadcasts the session event and all 3 tabs are checking at the same time if the session is valid
35:02 the access_token is now expired so all the 3 check session calls have triggered refreshAccessToken()

1st request is successful: exchange the refresh_token rt1 with a new access_token and refresh_token so the jwt callback is returning the updated token as following

{ access_token: "at2", refresh_token: "rt2", expire_in: "15min" }

2nd and 3rd request fail with 400 because they are trying to use the refresh_token rt1 that has just been invalidated so the jwt callback is returning the updated token as following

{ access_token: "at1", refresh_token: "rt1", expire_in: "15min", error: "RefreshAccessTokenError" }

Now we have 3 big problems:

1. This happens in a window of milliseconds and it can trigger a rate limit, imagine you have 5 tabs open it's 5req/s, generally these auth endpoint have a rate limit to avoid bruteforcing etc
2. We added error to the token and the client now believes that the the refresh token exchange was unsuccessful (we send the user to the login again)
3. We have lost forever the latest correct access_token and refresh_token because the last call that was made returned the previous token with the error

// The function was called with the old token containing "at1" and "rt1"
{ ...token, error: "RefreshAccessTokenError" }

[balazsorban44]

Love the details, make sense! I'll come back to this, thank you!

At the end of the day, I think the main problem here is not the broadcasting, but the race condition. Similar to #1455

[mtt87]

Yes but unfortunately the race condition is not solvable in a stateless serverless environment that’s why I think the only way to solve it is to prevent this from happening due to the broadcasting.

To solve this at the server level we would need a persisted state of the refresh token requests that are in flight in order to stop the subsequent request and instead wait but it starts to become very complex :)

[balazsorban44]

I see, and I was thinking the same. fixing it by making it possible to disable broadcasting is half way, but what about clientside code where after some stale time, let's say two requests are going to an external api and they use the access token from session?

I know react-query does fetch deduplication, so maybe we need to do something similar in our client code?

[mtt87]

I’m using SWR for the requests which works similarly to react-query for the deduplication and that’s fine. The problem imho is not deduplicating on the client side for a single page but trying to deduplicate for all the pages.

I’m trying to think at the problem from a different perspective: how about the broadcast is not saying “hey all tabs please refresh the session” but rather “hey I’m
TabA and I’m going to refresh the session”.
Then all the other tabs can wait for either a success event, and after that they can refresh their session or a fail event which means they should logout.

[balazsorban44]

Don't know if SWR does that, but react-query deduplicates site-wise, using a React Context. (Or by pages I guess you meant tabs?)

What you are saying how to go about broadcasting does sound interesting, and I would rather not introduce new options, if we can work something out transparently for this.

[mtt87]

What you are saying how to go about broadcasting does sound interesting, and I would rather not introduce new options, if we can work something out transparently for this.

Going to bed now, I’ll write down a proposal tomorrow with some scenario

[mtt87]

On my side the main question for you @balazsorban44 is:

What problems are we trying to solve broadcasting the getSession event?

I see, and I was thinking the same. fixing it by making it possible to disable broadcasting is half way, but what about clientside code where after some stale time, let's say two requests are going to an external api and they use the access token from session?

This problem has nothing to do with next-auth because you can have 100 requests to external API at the same time and they will not trigger the jwt() callback even if you are using a lambda to proxy the requests, I just tested the scenario where I have a serverless API that's using getToken() and it doesn't trigger jwt()

async function handler(req: NextApiRequest, res: NextApiResponse) {
  const token = await getToken({
    req,
    secret: process.env.NEXTAUTH_SECRET,
    encryption: true,
    signingKey: process.env.NEXTAUTH_SIGNIN_KEY,
    encryptionKey: process.env.NEXTAUTH_ENCRYPTION_KEY,
  })
  // call the API with the access_token contained in the encrypted token object
  ...
}

---

Writing down the full picture so if someone wants to read they have more context.

Refresh token rotation scenario

A session is based on session cookies that are set on successful login by the server lambda.

__Secure-next-auth.session-token
__Host-next-auth.csrf-token
__Secure-next-auth.callback-url

The most common scenario is the oAuth based authentication where an oAuth provider on successful login will issue an access_token and a refresh_token.

If you want to have a completely stateless authentication (no databases needed) then you will add these tokens to the JWT.
Due to the nature of these artifacts, it's not a good idea to put them plain unencrypted in a JWT but rather use an encrypted JWT (JWE).

Next-auth supports this by adding

jwt: {
  encryption: true,
  secret: process.env.NEXTAUTH_SECRET,
  signingKey: process.env.NEXTAUTH_SIGNIN_KEY,
  encryptionKey: process.env.NEXTAUTH_ENCRYPTION_KEY,
},

Next-auth uses the jwt() callback to control this, so in the case of a scenario where you have a refresh token you want to add a check to make sure if the access_token is expired, try to refresh it and return the new access_token and refresh_token.

Note: the jwt() callback is triggered every time the user is checking the session, either by calling getSession() or with the useSession() hook.
What they do is calling GET /api/auth/session behind the scenes.

async jwt(token, user, account, profile) {
  // Return previous token if the access token has not expired yet
  if (Date.now() < token.expiresAt) {
    return token
  }
  // Access token has expired, try to update it
  return refreshAccessToken(token)
},

refreshAccessToken() is a function to exchange the refresh_token for a new pair of access_token and refresh_token that are returned and included in the updated encrypted JWT (JWE).
Important: the previous refresh_token is instantly invalidated.

async function refreshAccessToken(token: JWT) {
  try {
    const refreshedTokens = await request(...)
    return {
      ...token,
      accessToken: refreshedTokens.access_token,
      expiresAt: Date.now() + refreshedTokens.expires_in * 1000,
      refreshToken: refreshedTokens.refresh_token ?? token.refreshToken, // Fall back to old refresh token
    }
  } catch (err) {
    return {
      ...token,
      error: 'RefreshAccessTokenError',
    }
  }
}

Next-auth broadcasting

Next-auth creates automatically a broadcast channel on every tab you open with the same web app.
https://github.com/nextauthjs/next-auth/blob/main/src/client/index.js#L39
Every tab is listening for 2 session events:

• getSession: this is broadcasted whenever you unfocus and focus back one of the tabs where your web app is running, telling the other tabs that they should check their session and in the scenario where you have 3 tabs open it will trigger simultaneously 3 API calls to check the session
• signout: this is telling the other tabs that the user is not longer logged in so they should sync and logout the user as well

Broadcasting issue with refresh tokens

If you have 3 tabs checking the session and triggering the jwt() callback 3 times in the same moment, it means that there are 3 refreshAccesstoken() being called, which means that there are 3 API calls to exchange the token, all of them with the same refresh_token currently available.

1st call: 200 successful, receives the new access_token and refresh_token that are returned and added to the encrypted JWT to substitute the existing access_token and refresh_token.
2nd call: 400 error, the refresh_token used to call the function is now invalid as it's just been used. We add the key error: "RefreshAccessTokenError" that's added to the session so the frontend now believes that the user needs to signin from scratch.
3rd call: 400 error, same as above

The problem is that the 2nd and 3rd call are basically "overwriting" the 1st call and now the latest JWT contains the error and the wrong tokens. The refreshed tokens are now lost and unrecoverable.

Serverless stateless environment

It's important to understand that we are in a stateless serverless environment.
We cannot assume that the 3 check session calls mentioned above are going to the same lambda function, they could be different lambda function and all of them are isolated.
We want to keep a stateless auth so there are no databases involved and nothing can be persisted due to the ephemeral nature of a lambda function.

Proposed solution: option to disable broadcasting some events

If we add an option to disable the broadcasting of the getSession event, we can prevent this from happening at the root.
What does it mean in a scenario where we have 3 tabs?
1st tab that gets focus will check the session and trigger a refresh token and update the session accordingly.
2nd tab and 3rd tab are not aware this happened BUT because updating the session with the new tokens basically means to update the cookies, the 2nd and 3rd tab got the session updated automatically in case they have some background stuff (for example they are polling an API from time to time)
When the user opens the 2nd tab it will check its session and nothing happens as the cookie has already been updated with the new tokens not yet expired, same would happen to the 3rd tab.
Since we are still broadcasting the signout event, in case the user decides to logout or their tokens are expired and can't be refreshed, all the other tabs will still be notified.

[mtt87]

@balazsorban44 sorry to bother you, did you have a chance to read my last comment?
My question for you: what problems are we trying to solve broadcasting the getSession event?

[balazsorban44]

Will have a proper read of this in the next few days, I hope. I actually just had to deal with this problem at work, came to a conclusion and used some different approaches, but ultimately I think supporting token rotation will be something that will need some more thinking. This has certainly become rather a feature request than a bug.

[mtt87]

Thanks for the update, I see your point, on my side I was more inclined to define this a bug since refreshing a token feels to me like a basic necessity rather than an "additional feature" for modern web apps 😄
Anyway I'll wait for your next reply and once agreed on the approach I'm happy to contribute if need my help.

[balazsorban44]

I would only call it a bug, if the functionality is already built-in, but do not deliver what it is meant to. A feature request is when we want to introduce a functionality that hasn't existed yet in the library. We still do not have built-in token rotation, and partially from the above mentioned issues, it is not trivial at the moment.

I have looked around the web to see how others are doing it, and honestly, I haven't found a go-to solution. The main problem here be it tab sync or other reasons of race conditions, when a token refresh is in flight and a new request wants an updated token, the old refresh token will be used again, which will lead to a problem.

According to my findings, the only way to avoid this is orchestrating (read deduplication) the client-side requests to /api/auth/session. In our case at work, we are using https://github.com/nextauthjs/react-query which does deduplication automatically. Basically you want to make sure that whenever a request goes to /api/auth/session, other calls rather "subscribe" to that response, than start a new request. When using https://github.com/nextauthjs/react-query broadcasting is avoided as we don't need the useSession hook from next-auth/client (which is the source of the broadcasting logic).

To answer the question

what problems are we trying to solve broadcasting the getSession event?

I have to say I am not 100% sure what real-life use cases @iaincollins have looked at when he originally implemented it, but he probably had a reason. Unfortunately, I wasn't around then yet, so I cannot give an honest answer, maybe if Iain sees this thread one day, he can explain it. Until then, if an option to disable this behavior helps us here in any way, I am all for it, but I don't think it will be enough.

I think if we want to move forward with built-in token rotation, we will need to complicate our clilent-side code slightly, so it handles deduplicated requests to /api/auth/session correctly. I don't think it would be as easy as it sounds, but I might be wrong. In any case, I would like to hold this off until we have a better client implementation #1473

[mtt87]

Sorry but unless there is something that I didn’t understand, I don’t think what you are saying is correct and you might not be looking at the problem from the correct angle.
The problem doesn’t exist when you have a single tab open but only when you have multiple tabs.
When you have a single tab open, since you are wrapping the entire application in the session provider, it looks like even with multiple components depending on useSession you only get 1 api call.
As mentioned before even when calling a lambda API and using getToken utility, that doesn’t trigger a session update as it doesn’t trigger the JWT callback.
Deduplicating requests on a single tab is definitely possible as you said with stuff like react-query or useSWR, but it seems completely irrelevant to the problem.
The problem will still be there unless you deduplicate across ALL the open tabs.

EDIT: I saw your edit after and the reply to my answer, thank you 😄

Thanks for your time and patience

[balazsorban44]

OK, so we might have diverged at to react-query before I managed to check that the built-in Provider actually de-duplicates in a single tab scenario, but after some thinking, yes, it's probably true (https://next-auth.js.org/getting-started/client#options).

So in theory, a single boolean flag to disable broadcasting would do it then? Unless there is a more complicated way that would make it possible to de-duplicate even across open tabs? 😄

[mtt87]

@mtt87 If we store tokens using userId as key, there's a possibility to hijack the token mimicking the cookie with a known userId. I think the flow can be improved if the backend generates a deviceId that we use as the key. userId can be obtained easily by looking at API requests payloads, but the deviceId is always stored privately in the cookie.

👋 I'm not sure about what you say, basically to "mimic" a cookie with a known userId it means that you need to be able to encrypt the token with the private key available to the server, otherwise you can't "mimic" a cookie as it's not clear text but it's encrypted.

Potentially you could have an issue if you use 2 different providers like GitHub and GitLab, I create a username test_user_1 on GitHub and you create test_user_1 on GitLab, then in next-auth if you use test_user_1 as userId property, you can login pretending to be me by logging in with GItLab as we would both be identified by userId: test_user_1
This is simply prevented by using a key like provider:userId so they would be github:test_user_1 and gitlab:test_user_1

[orangecoloured]

it means that you need to be able to encrypt the token with the private key available to the server, otherwise you can't "mimic" a cookie as it's not clear text but it's encrypted.

Ah yes, I completely forgot about this. I was thinking in a context of a plain text cookie. So I guess in a custom setup my point would be valid.

[saby22]

Is there any update to this, apart from #3940 (comment) ?

[saby22]

Tried to implement #3940 (comment)

Here are some of the issues that came up

• I will admit that I am no expert at serverless, but according to my understanding, serverless and databases doesn't really work very well out of the box (at least as of now). Managed redis deployments (redislabs in my case) kept on screaming about exceeding max no. of connections . If anybody wants to take a dig at the whole connections issue can refer to this article.

• While trying to solve the connections issue, I came across RDS Proxy. It seems to address the whole connections issue for relational databases. Downside being, it's not for redis (obvious), and you need to get into the whole AWS ecosystem in order to get this working.

To quote

Amazon RDS Proxy is a fully managed, highly available database proxy for Amazon Relational Database Service (RDS) that makes applications more scalable, more resilient to database failures, and more secure.

Many applications, including those built on modern serverless architectures, can have a large number of open connections to the database server and may open and close database connections at a high rate, exhausting database memory and compute resources. Amazon RDS Proxy allows applications to pool and share connections established with the database, improving database efficiency and application scalability.

• After scouring through the internet, I came across Twemproxy. Tbh, it has a bit of a learning curve, and I couldn't really afford to spend much time behind setting the whole thing up and making sure it works properly in production. This might be a possible solution to the whole connections issue with redis. (not 100% sure though)

• Finally settled on Upstash Redis. Initially it seemed like the perfect solution - the idle connections would be terminated automatically, and also it costs less (since it is serverless). Moreover, they have built a REST API corresponding to the redis commands. The HTTP based REST API would have been a perfect solution (not sure about performance though), but the npm package that implements redlock only works with Ioredis and not other redis client libraries, like Upstash's own library @upstash/redis.

It was working fine for a few days, until redlock started to fail to achieve quorum on multiple occasions. ( not sure why...I am no expert in redlock).

Also we started getting hit with multiple ETIMEDOUT exceptions out of nowhere. A possible explanation might be this.

All of this resulted in a lot of stale data , failing refresh requests and invalid token responses from the backend, resulting in users getting logged out left right and center.

Is the use rotating refresh tokens and a custom back-end API which generates access and refresh token pairs an anti-pattern with NextAuth?

I would love to hear what others have to say about this. Did I steer to a completely wrong direction? Or did I make any wrong assumptions?
@balazsorban44 @mtt87

[saby22]

Unfortunately, we use unstable_getServerSession in getServerSideProps a lot in our company, and it's not really possible for us to migrate the entire auth to be handled on client side right now😅.

I had read your comment #3940 (comment) , and I am aware about Navigator.locks.

It made me wonder, aren't there any other locking algorithms apart from redlock that can be used to achieve this?

I would really love it if the NextAuth team came up with some sort of a solution for this issue.🤞

[mtt87]

Due to the nature of serverless it has to be something outside. You can try to implement your own version of lock with redis perhaps instead of using redlock?

[iamstarcode]

Is the use rotating refresh tokens and a custom back-end API which generates access and refresh token pairs an anti-pattern with NextAuth?

I wouldn't say this is an anti-pattern as providing refresh tokens is the right way to have a good balance between security and UX, where the user is not prompted to login every time they come to your website. If you use an external service like Auth0 this is how it works.

It's just complicated with this "self hosted solution" given the serverless nature of the deployments.

That said now it's been a while since I worked on this but ultimately in my company we found a working solution by implementing the lock mechanism on the client side so if you have a situation where you can avoid using getSession on the server side (like in getServerSideProps) then you are fine.

My fork has this implemented https://github.com/mtt87/next-auth but I haven't worked on this in a while so I'm out of the loop can't provide a lot of help.

Hi @mtt87 , for the past few days have read all of this thread word for word lol. I really appreciate your responses, but I do have a questions though, or should I say I would love to have a recommendation from you. It's true using locking mechanism might definetely result into more bugs, have had redis implemented(a managed redis), and that could in result in longer response time.
But with the client lock you had implimented seems to be the best way in my opinion, more browsers now supports the API. However, what am skeptical about is the avoidance with the useage of getSession, with Server Components flying all around now, can that really be avoided, lol. And I understand useSession can definelety be used as a replacement for getSession and even has better UX. Am just wondering can useSession be truly fully avoided compleleted in your experience? So that I can just go ahead to use your fork.
Thanks will love to hear from you soon.

[mtt87]

I'm not working actively on that project anymore and when I left we were on NextJS 12, no server side components.
I think with server side components this will have to be revisited and we should re-think the implementation.
A possible solution might be to use https://vercel.com/blog/edge-config-ultra-low-latency-data-at-the-edge

[iamstarcode]

Oh! Thanks, will also look into it

[qiqo]

I'm also affected with this issue and I only use one tab. What I do though to test is I've set throttle to slow the connection [i've set it to either GRPS, 2G or Good 2G] to my authentication server to renew the token - so when the tab regains focus, it triggers the JWT callback...

The kicker now would be is since it's throttled connection, I have enough wait time that I can hit the browser's refresh button which actually sends another request to trigger the JWT call back (and this is not an edge case behaviour for users since users can be impatient and will be glad to refresh the browser).

So now comes the issue, since the tab refocus has already caused the script to send a refresh request, and the server has already received it (over slow connection) the refresh token that came earlier has actually been invalidated, but the browser refresh will still use the old token, therefore the entire refresh cycle is broken though this side effect.

This also means that the "new access token" in transit (from the request caused by the tab/browser refocus) is lost because the browser refresh is in progress (while it sends the same token)

This leads to three major draw backs

1. the updated token is lost because:
2. the refresh token sent by the browser is deemed outdated by the refocus event
3. the user gets logged out and has to log in again.

The only remedy I agree would be to have a configurable flag to prevent a refocus to trigger a JWT request/refresh thus giving priority for manual refresh - and I think this is recommended behaviour (if a possible fix is in place) since the refresh is ought to be directly-triggered actions particularly a click to a link or button, or navigation to a route akin to how mobile apps also trigger refreshes.

[lws803]

I'm thinking of a hack, 🤔 what if we intercept the request made to refresh token and add a debouncer there instead? We could use in memory storage to check if the current refreshed token has already been used and if it has, cancel the request to the refresh token endpoint.

Sorta like using an in-memory mutex to prevent multiple resource access

[sradu]

I don't understand how this plugin works with this bug. This seems like a serious breaking issue. I can reproduce it easily:

refresh token is Qz5C7HUHqccHcxp-ZQkXinkNF5n5ReqSdAuLK5pE_Kg
refreshing with Qz5C7HUHqccHcxp-ZQkXinkNF5n5ReqSdAuLK5pE_Kg
new refresh token is JRfhWMs0YlQufLOIkG4mYOxKiPADTvb7JN58DlqABqg

refreshing with Qz5C7HUHqccHcxp-ZQkXinkNF5n5ReqSdAuLK5pE_Kg

used by this code:

    async jwt({ token, user }) {
      if (user) {
        token = { ...token, ...user };

        console.log('refresh token is', token.refresh_token)
        return token;
      }

      console.log('refreshing with', token.refresh_token)

      const newToken = await refreshAccessToken(token);

      console.log('new refresh token is', newToken.refresh_token);

      return newToken;
    },

[mrbodich]

Hey @sradu, did you manage to solve this issue? I've created a bug report #7558, but as I see a lot of devs are experiencing this. For example here #6642 also.

[sradu]

It was quite easy to resolve. I was using Rails and doorkeeper and it (or rack) hangs the request somewhere. There was no desire to search and find a fix by the developers.

Ultimately I decided to proxy my requests to the Rails backend with http-proxy-middleware and next auth session. This solved all my problems and provided a cleaner solution.

[mrbodich]

@sradu Can’t say I understood the solution))

[elvinasv]

Has anything changed in the last two years, or is the go-to solution still #2071 (comment) ?

@balazsorban44 Since #7056 got released, maybe there's a plan for the built-in refresh token strategy?

[AJMcKane]

Is there any update on this? I'm able to replicate this issue on a single tab wherein I have two components on a page that both call useSession()

What's I'm able to replicate is that the initial sign-on works, the first refresh also works. I've modified this call to always call the refresh, so that I don't have to wait X minutes, but I'm observing the behaviour even if I do wait.

I.E

  callbacks: {
    async jwt({ token, account }) {

      console.log("account refresh token", account?.refresh_token)
      console.log("token in jwt callback", token?.refreshToken)

      if (account?.id_token) {
        token.idToken = account?.id_token
      }

      if (account?.access_token) {
        token.accessToken = account?.access_token
      }

      if (account?.refresh_token) {
        token.refreshToken = account?.refresh_token
      }

      if(account?.expires_at) {
        token.accessTokenExpires = new Date(account?.expires_at * 1000).getTime()        
      }

      // if (Date.now() + 60000 < token.accessTokenExpires) {
      //   return token
      // }
      return refreshAccessToken(token)
    }

Combined with the refresh code (which has been taken from the OAuth rotation guide), ends up with logs like so:

--- initial signIn Callback, account populated
account refresh token A882C9821239480A3654B8FC0CE9032C687F4418315F0D13F10754756C86C590
token in jwt callback undefined

--- First refreshAccessToken call
refreshToken Passed to Server A882C9821239480A3654B8FC0CE9032C687F4418315F0D13F10754756C86C590
token persisted 54616CA1EAA0AED6B62C3DEC74D65000109BCD862B5A66A886C0C7DC5CDD7324

--- Second refreshAccessToken Call
account refresh token undefined
token in jwt callback 54616CA1EAA0AED6B62C3DEC74D65000109BCD862B5A66A886C0C7DC5CDD7324
refreshToken Passed to Server 54616CA1EAA0AED6B62C3DEC74D65000109BCD862B5A66A886C0C7DC5CDD7324
token persisted 85CE38B3CEA6E6560E61676B494061F165296E26C7CD0B3F4838E6AC6B8C644C

---  Third refreshAccessToken call, uses the result of the first refreshAccessToken call, instead of the second. 

token in jwt callback 54616CA1EAA0AED6B62C3DEC74D65000109BCD862B5A66A886C0C7DC5CDD7324
refreshToken Passed to Server 54616CA1EAA0AED6B62C3DEC74D65000109BCD862B5A66A886C0C7DC5CDD7324
{ error: 'invalid_grant' }

[filmerjarred]

I also wished to disable the broadcast event (for reasons other than token refresh issues) and found a way to do it. If you ensure this code runs before the nextauthjs package, it will prevent the page receiving and broadcasting auth change events.

// prevent receiving
window.addEventListener("storage", (event) => {
  const message = JSON.parse(event.newValue ?? "{}")
  if (message?.event !== "session" || !message?.data) return
  
  event.stopImmediatePropagation()
  console.log('blocked receiving nextjs-auth storage message', event.newValue)
})

// prevent sending
const originalSetItem = localStorage.setItem.bind(localStorage)
localStorage.setItem = (key, value) => {
  if (key !== "nextauth.message") {
    return originalSetItem(key, value)
  }

  console.log('blocked nextjs-auth storage message', key, value)
}

[lhammarstrom]

Would a potential solution (instead of using Redis) be to use locks with a key corresponding to the user? Some pseudo-code would be:

async jwt({ token, user }) {
    if (user) {
        return { ...user };
    }

    const key = `token-${token.user.email}`;
    const lock = semaphore.acquire(key);

    try {
        lock.waitForUnlock();
        if (tokenIsValid(token)) {
            lock.release();
            return token;
        }

        const refreshedToken = await refreshAccessToken(token);
        lock.release();

        return refreshedToken;
    }
    catch {
        lock.release();
    }
},

Essentially, you acquire a lock and release it after you've gotten your token. Would a library like async-mutex work well for this or would the application get bogged down? I'm used to C# so using semaphores is pretty standard, but get kind of lost with this JS/TS stuff.

[lhammarstrom]

I found a solution that is provider agnostic using async-lock, where the finished product would look something like this:

async jwt({ token, user }) {
    // Will be called on first login, return data from authorize method
    if (user) {
        const jwt = { ...user };
        const key = constructKey(jwt.user.email);

        cache.set<JWT>(key, jwt);
        return jwt;
    }

    if (tokenIsValid(token)) {
        return token;
    }

    let jwt: JWT = {
        ...token,
        error: LOGIN_ERRORS.REFRESH_ERROR,
    };

    const key = constructKey(token.user.email);
    await lock.acquire(key, async () => {
        const currentToken = cache.get<JWT>(key);
        if (!currentToken) {
            return;
        }

        // When this endpoint is called concurrently, the previous request
        // can sometimes already have updated the token in the cache, in that
        // case returned the already cached token
        if (tokenIsValid(currentToken)) {
            jwt = currentToken;
            return;
        }

        // If it's the first request to refresh the tokens then
        // we get new tokens using the refresh endpoint
        const refreshedTokens = await refreshAccessToken(currentToken);

        // Save the new JWT to the cache
        cache.set<JWT>(key, refreshedTokens);

        // Return new JWT token
        jwt = refreshedTokens;
    });

    return jwt;
}

The only thing to implement there is the cache provider, which it seems needs to be somewhere other than in here so that the cache is not destroyed when in dev mode. I believe something like this would be agnostic enough to be included in the standard library without causing too much of an issue. I.E using a form of queue-system to implement the locking and then insert a provider for the cache which implements an interface for getting / setting keys. Also not agaisnt having this stay in user land, but to document it properly as this is a major PIA

[vanenshi]

This seems like a good idea to use the email or id as the lock, but this solution is not going to work for all the users, some tokens are encrypted and hence not readable.
so I was thinking maybe we can generate an instance-id for each browser and use it to understand the request scope. we have to save this instance-id in the cookies to be able to use it, and it will not going to get change. using this solution we might be able to use it regardless of the structure of the token.

[lhammarstrom]

That's fair and I have had the same thoughts but never bothered to implement it. It's not too hard to generate a UUID for each session and keep track of it. This also solves the issue of having multiple sessions across devices.

[todesignandconquer]

If you're using Next.js 13 and the App Router, you can add time-based revalidation with some arbitrary amount to your refresh access token fetch call and it won't call it twice (or more) under all scenarios (single tab, multiple tab). Reason being due to the built-in cache functionality of Next.js 13 in conjunction with a revalidate minimum option, it will recognize the same input parameters (meaning your old refresh token in the body) and won't call it again.

https://nextjs.org/docs/app/building-your-application/caching#time-based-revalidation

[Thanaen]

Unfortunately, I have the impression that the invocations of the JWT callback are so close that the second invocation will systematically miss the data cache :(

[mohammedsafvan]

For me the issue is purely on refreshing the page, or opening a new tab after expiration. if the access_token expired then it will try to fetch new access_token using refresh_token. the refreshing of the page triggers around 3 session checking.

all gives the previous token (expired). so the first one successfully refreshes the token, then the second one (it is also the expired one), so it will try for a refresh_token rotation, but the the first one already redeemed the refresh_token, so it will give an error.(For me it is on the 3rd one Don't know why, may be the token endpoint issue)

The solution I did

i used a map, if a refresh_token rotation occured then it will save the refresh token and newTokenSet as key value pairs, But the lifespan of each entry would be around 2 to 3 seconds. now in the jwt callback if an expired token arrives , it will check if the current refresh_token is present in the map keys, if it is then return from the map, if it is not then fetch a new access_token and save it to the map.

Please note that I only need the access_token in the server so no need to pass it to the session. It is working.But needed others thoughts on this

[mohammedsafvan]

the problem solved by disabling ssr. Now I don't need a caching mechanism

[nguyenhuugiatri]

My solution:

import mem from 'mem'

export const refreshTokenAPI = mem(
  async (tokenType: string, refreshToken: string) => {
    return publicRequest<TAuthToken>('/user/auth/refresh', {
      method: 'POST',
      headers: {
        Authorization: `${tokenType} ${refreshToken}`,
      },
    })
  },
  {
    maxAge: 1_000,
    cacheKey: (arguments_) => arguments_.join(','),
  }
)


  callbacks: {
    async jwt({ token, user }) {
      if (user) {
        token.user = user
        return token
      }

      const isTokenStillValid = token.user.expiredAt - getCurrentTimeStamp() > 0

      if (isTokenStillValid) return token

      try {
        const { accessToken, refreshToken, expiredAt, tokenType } =
          await refreshTokenAPI(token.user.tokenType, token.user.refreshToken)

        return {
          user: {
            ...token.user,
            accessToken,
            refreshToken,
            tokenType,
            expiredAt: expiredAt - REFRESH_TOKEN_OFFSET,
          },
        }
      } catch {
        return {
          ...token,
          error: REFRESH_TOKEN_EXPIRED_ERROR,
        }
      }
    },
  },

[etnichols]

@nguyenhuugiatri could you explain a little bit more on how this solution works in the serverless environment (i.e. Next API routes)? I guess I'm a little confused how the mem package functions in a serverless context, as it requires persistent memory in order to cache values. Is this relying on a serverless function being "warm", and thus allowing multiple requests to access the cache?

I don't totally understand how Next chooses to spin up, re-use, and tear down serverless function execution contexts, but the issue i see here is an edge case where Request 1 refreshes the token (and caches value), but Request 2 _executes in an entirely different serverless function, thus fails to hit the cache.

[etnichols]

See @mtt87's comments on lambdas here: #3940 (comment)

[gera-cl]

@nguyenhuugiatri it works for me, thank you. I use memoizerific instead of memoize but is the same logic

[sophieqgu]

This stopped working for me :(

[jdmnk]

I can confirm this works, I was able to achieve the same result by using memoizee. I'm running next-auth v5.

import memoize from 'memoizee'

export const memRefreshToken = memoize(refreshTokenFn, {
  maxAge: 60 * 1000, // clear cache after 1 minute or whatever works for you
  promise: true, // this is important (set to 'true' if your fn returns a promise)

  // custom hash for caching
  normalizer: function (args) {
    // args is arguments object as accessible in memoized function
    return JSON.stringify(args[0].refreshToken)
  }
})

You might run into issues running this on Edge runtime though. I had to avoid doing that entirely because otherwise my app wouldn't build (removed auth from middleware).

[NanningR]

@nguyenhuugiatri @VGontier-cmd @ARJohnsonKwik @mohammedsafvan

A cleaner solution is to use middleware.ts, as it's more inline with the official next.js docs: https://nextjs.org/docs/pages/building-your-application/authentication

Solution available here (hats off to the guy Rinvii who first came up with it): #9715

In short, you implement the refresh token rotation logic in middleware, and force getServerSession() to read the new session and send it back to the browser by setting the cookies. You do something like this:

import { NextResponse, type NextMiddleware, type NextRequest } from "next/server";
import { encode, getToken, type JWT } from "next-auth/jwt";

import {
	admins,
	SESSION_COOKIE,
	SESSION_SECURE,
	SESSION_TIMEOUT,
	SIGNIN_SUB_URL,
	TOKEN_REFRESH_BUFFER_SECONDS
} from "./config/data/internalData";

let isRefreshing = false;

export function shouldUpdateToken(token: JWT): boolean {
	const timeInSeconds = Math.floor(Date.now() / 1000);
	return timeInSeconds >= token?.expires_at - TOKEN_REFRESH_BUFFER_SECONDS;
}

export async function refreshAccessToken(token: JWT): Promise<JWT> {
	if (isRefreshing) {
		return token;
	}

	const timeInSeconds = Math.floor(Date.now() / 1000);
	isRefreshing = true;

	try {
		const response = await fetch(process.env.AUTH_ENDPOINT + "/o/token/", {
			headers: { "Content-Type": "application/x-www-form-urlencoded" },
			body: new URLSearchParams({
				client_id: process.env.CLIENT_ID,
				client_secret: process.env.CLIENT_SECRET,
				grant_type: "refresh_token",
				refresh_token: token?.refresh_token
			}),

			credentials: "include",
			method: "POST"
		});

		const newTokens = await response.json();

		if (!response.ok) {
			throw new Error(`Token refresh failed with status: ${response.status}`);
		}

		return {
			...token,
			access_token: newTokens?.access_token ?? token?.access_token,
			expires_at: newTokens?.expires_in + timeInSeconds,
			refresh_token: newTokens?.refresh_token ?? token?.refresh_token
		};
	} catch (e) {
		console.error(e);
	} finally {
		isRefreshing = false;
	}

	return token;
}

export function updateCookie(
	sessionToken: string | null,
	request: NextRequest,
	response: NextResponse
): NextResponse<unknown> {
	/*
	 * BASIC IDEA:
	 *
	 * 1. Set request cookies for the incoming getServerSession to read new session
	 * 2. Updated request cookie can only be passed to server if it's passed down here after setting its updates
	 * 3. Set response cookies to send back to browser
	 */

	if (sessionToken) {
		// Set the session token in the request and response cookies for a valid session
		request.cookies.set(SESSION_COOKIE, sessionToken);
		response = NextResponse.next({
			request: {
				headers: request.headers
			}
		});
		response.cookies.set(SESSION_COOKIE, sessionToken, {
			httpOnly: true,
			maxAge: SESSION_TIMEOUT,
			secure: SESSION_SECURE,
			sameSite: "lax"
		});
	} else {
		request.cookies.delete(SESSION_COOKIE);
		return NextResponse.redirect(new URL(SIGNIN_SUB_URL, request.url));
	}

	return response;
}

export const middleware: NextMiddleware = async (request: NextRequest) => {
	const token = await getToken({ req: request });
	const isAdminPage = request.nextUrl.pathname.startsWith("/epa");
	const isAuthenticated = !!token;

	let response = NextResponse.next();

	if (!token) {
		return NextResponse.redirect(new URL(SIGNIN_SUB_URL, request.url));
	}

	if (shouldUpdateToken(token)) {
		try {
			const newSessionToken = await encode({
				secret: process.env.NEXTAUTH_SECRET,
				token: await refreshAccessToken(token),
				maxAge: SESSION_TIMEOUT
			});
			response = updateCookie(newSessionToken, request, response);
		} catch (error) {
			console.log("Error refreshing token: ", error);
			return updateCookie(null, request, response);
		}
	}

	if (isAdminPage && isAuthenticated && !admins.includes(token.email!)) {
		return NextResponse.redirect(new URL("/forbidden", request.url));
	}

	return response;
};

export const config = {
	matcher: ["/dashboard/:path*", "/epa/:path*"]
};

Make sure you read all the comments on the references page to apply this to your situation

[NanningR]

@CptCompiler You're welcome! And, now that I think about it, you're probably right. It was declared as a global variable. It hadn't caused any issues for me yet, but I decided to just remove the variable entirely and increase the refresh buffer to 300 seconds (my access token lifetime is 1 hour). If I encounter any issues, I will come up with a better way to lock the tokens during refreshing. Thanks :)

[maxbec]

I tried to use redis and redlock for that issue. But it is not working due to the edge runtime limitation. Maybe someone of you guys has an idea how to use redlock with authjs?

[asif-jalil]

This solution works for me. Thank you

[tungnt-1562]

@NanningR thanks for the solution, it is working for me.
But tbh I don't understand why it is working (sorry if the reason is obvious, I'm kind of new to NextJS/React).
I tried to implement the refresh logic and lock mechanism in the JWT callback but multiple requests would pass the isRefreshing lock at the same time.
Why in middleware level, this issue not happen?

[NanningR]

@tungnt-1562 It's mentioned here: #9715 (reply in thread)

That thread in general contains more information about this solution, as well as the process of how it came to be.

[asopromadze]

I had similar issue with single tab.
This is my solution, i m using Nextjs page router and SWR for data fetching

const tokenCache = new Map();
// Flag to indicate if a refresh is in progress
let isTokenRefreshing = false;
// Queue to store pending refresh requests
const refreshRequestQueue = new Map();

async function CloudProviderJWT({ token, account }: JWTCallBackInput) {
  if (account && account.id_token) {
    const { status, jwt } = await tokens(account.id_token as string);
    if (status === TokeResponseStatuses.OK) {
      return Object.assign(token, jwt);
    }

    return Promise.reject("An Error occurred, try again later");
  }
  if (Date.now() < (token.accessTokenExpires as number)) {
      return token;
  }

  const key = token.refreshToken as string;

  // check if there's already a cached token for this key
  if (tokenCache.has(key)) {
    return tokenCache.get(key);
  }

  // if refresh is in progress, wait for it to complete
  if (isTokenRefreshing) {
    await new Promise((resolve) => {
      refreshRequestQueue.set(key, resolve);
    });
    // get valid token from cahce
    return tokenCache.get(key);
  }

  // set the refresh flag to indicate that a refresh is in progress
  isTokenRefreshing = true;

  const { jwt, error } = await refresh(key);
  const newToken = error
    ? Object.assign(token, { error })
    : Object.assign(token, jwt);

  // clear the cache
  tokenCache.clear();
  // store the new token in the map
  tokenCache.set(key, newToken);

  // resolve any pending refresh requests
  const resolveFunc = refreshRequestQueue.get(key);
  if (resolveFunc) {
    resolveFunc();
  }

  isTokenRefreshing = false;
  refreshRequestQueue.clear();

  return newToken;
}