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: 4c4fabd

[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).

[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.