fix(#947): only call refresh when auth token is expired

[anjarupnik]

🔗 Linked issue

Fixes #947

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

The server-side refresh plugin (refresh-token.server.ts) triggers a token refresh with the condition refreshToken.value && token.value. This means it only refreshes when both the refresh token and the auth token are present — but this is the opposite of what's needed.

When the auth token expires, it's no longer available in the server request. However, the refresh token is still present and should be used to obtain a new auth token. With the current logic, the refresh is never triggered in this scenario.

This PR flips the condition to refreshToken.value && !token.value, so the refresh is called when a refresh token exists but the auth token is missing/expired. It also removes the Authorization header from the refresh request, since there is no valid token to send.

📝 Checklist

• I have linked an issue or discussion.
• I have added tests (if possible).
• I have updated the documentation accordingly.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@sidebase/nuxt-auth@1087

commit: a89a929

[phoenix-ru]

While I fully agree with the proposed implementation, I think that we still should conditionally add the access token to headers as it was before to keep compatibility with servers which expect it:

Suggested change

	if (refreshToken.value && !token.value) {
	if (refreshToken.value) {

// include header in case of auth is required to avoid 403 rejection
const headers = token.value
  ? new Headers({
      [provider.token.headerName]: token.value
    } as HeadersInit)
  : undefined

Otherwise it can be considered a breaking change.

Note for the context: local provider would likely be deprecated in version 2 due to sometimes ambiguous implementations like the current one, where library doesn't know the full usecase, such as what is required by the underlying back-end for the refresh call. Instead, users will be able to customize the behaviour and exact requirements of their backend when #1062 lands (currently pending team review).

[anjarupnik]

Hi @phoenix-ru, thanks for the quick review. I’ve applied your suggestion. Keeping the access token in the headers conditionally makes sense here to preserve compatibility with backends that require it and to avoid a breaking change.

I also like the direction of the new approach, because cases like this show how hard it is for the library to support every backend-specific use case. For example, with the current approach, we may refresh the token unnecessarily on every page load, since we do not check whether the existing token is expired first.

[phoenix-ru]

Thanks, I will do a functional check tomorrow and we can merge this

[phoenix-ru]

Hi @anjarupnik and thanks for taking the time to fix a long-standing issue. I've left review above regarding compatibility which I believe needs to be preserved to land this.

[phoenix-ru]

@anjarupnik Thank you again, I was able to functionally test this and it looks like the situation from #947 does not occur on this PR