mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-07-17 17:32:27 -05:00
[GH-ISSUE #7060] Clients not asked to re-authenticate with expired refresh_token
#15390
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tycho on GitHub (Apr 6, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7060
Prerequisites
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Config:
Vaultwarden Build Version
1.35.4-1 (Arch Linux package)
Deployment method
OS Package (apt, yum/dnf, pacman, apk, nix, ...)
Custom deployment method
No response
Reverse Proxy
nginx 1.29.7
Host/Server Operating System
Linux
Operating System Version
Arch Linux, 6.18.20
Clients
Desktop, Browser Extension
Client Version
2026.2.0
Steps To Reproduce
Expected Result
I would expect the client to recognize that the session is no longer valid and prompt for re-authentication.
Actual Result
The client does not recognize that a re-authentication is necessary.
The client silently stops syncing the vault with the server. Explicit refresh attempts yield cryptic error messages.
The client fails to write to vault entries, giving cryptic error messages.
All of the above end up confusing end users, who can't tell when their session is still valid because the client doesn't give them a clear indication that their session validity has expired.
Logs
Screenshots or Videos
No response
Additional Context
It seems possible that the re-authorization workflow is being handled incorrectly somehow:
69f9c7d30d/libs/common/src/services/api.service.spec.ts (L453)Clients expect "invalid_grant" in the response for expired tokens, which may be what's missing:
69f9c7d30d/libs/common/src/services/api.service.ts (L1786-L1797)