Support: Explain caching of JWT tokens
Hi,
We're using your unami example for authentication with Drupal. After doing some debugging, it looks like the cache in the JWT token logic is not specific to the current logged in user. This is causing the same access token to be returned to different user sessions.
Can you confirm if this a bug or if I'm doing something wrong that's leading to the shared cache?
https://github.com/chapter-three/next-drupal/blob/main/examples/example-umami/lib/jwt.ts#L8
You're right. This will be a shared cache. I'll fix this. Thank you.
(IIRC there was a bug in next-auth preventing this from working properly. I'll see if I can find the issue and update)
Hey @shadcn
What do you think is the best way to handle this for a site that's getting ready to launch? Should I just omit the caching option?
Thanks!
After looking into this, getJWT is passed inititalJWT which appears to be fully populated. Removing the caching logic and returning initialJWT whenever it's accessTokenExpires aged out seems to work fine.
We're going forward with that for now until we hear back from you :)
export async function getJWT(initialJWT: JWT): Promise<JWT> {
// We have a cached token, check the expiry date.
if (Date.now() < initialJWT?.accessTokenExpires) {
return initialJWT
}
// The token has expired, fetch a new one.
return await refreshAccessToken(initialJWT)
}
@andyg5000 Sorry. Been busy with Next.js conf :)
IIRC I had do to this workaround because of a bug in next-auth. Maybe they fixed it?
I'll update my local example and confirm.
Looking forward to seeing the new site :)
I updated to the latest next-auth and I couldn't get this to work. For the reason, I'm always seeing the refresh token as expired. I'll keep looking...