starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2025-12-09 09:13:02 +03:00
Code Issues 429 Packages Projects Releases 10 Wiki Activity

Session deauthorization doesn't log out offline clients #799

New Issue
Closed
opened 2025-10-09 16:52:01 +03:00 by OVERLORD · 3 comments
OVERLORD commented 2025-10-09 16:52:01 +03:00
Owner
Copy Link

Originally created by @SoOutnumb3r3d on GitHub.

Subject of the issue

Using the Deauthorize Sessions feature of the web client isn't logging out all clients immediately like it should. I've experimented a bunch of times to try to figure out in what scenarios clients are logged out and when they're not.

So far, I've found that after deauthorizing sessions:

  • Clients are logged out immediately if they're running and online
  • Mobile clients are always logged out immediately (I'm running the latest testing build with push, so that may explain that one)
  • For clients that are closed/offline, they are usually not logged out when opening the client following de-auth, but sometimes they are
  • If the clients are NOT logged out, they will still show cached data as behave as if nothing is wrong (this is bad, security-wise). Forcing an explicit sync of the client through its UI, it presents a "sync failed" error, but the client remains logged in and the cached data remains available. Making any changes, though, results in the client logging itself out

I've tested this behaviour against vault.bitwarden.com, and over there deauthorizing sessions does what one expects (immediate logout of all clients, regardless of whether they're running or online/offline).

Deployment environment

Your environment (Generated via diagnostics page)

  • Vaultwarden version: v1.28.1-e7f083de
  • Web-vault version: v2023.5.0
  • OS/Arch: linux/x86_64
  • Running within Docker: true (Base: Debian)
  • Environment settings overridden: false
  • Uses a reverse proxy: true
  • IP Header check: true (CF-Connecting-IP)
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Browser/Server Time Check: true
  • Server/NTP Time Check: true
  • Domain Configuration Check: true
  • HTTPS Check: true
  • Database type: SQLite
  • Database version: 3.41.2
  • Clients used:
  • Reverse proxy and version:
  • Other relevant information:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden:

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": false,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_smtp_img_src": "cid:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": "***",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "***************",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://*****************",
  "domain_origin": "*****://*****************",
  "domain_path": "",
  "domain_set": true,
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "email_attempts_limit": 3,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": null,
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "ip_header": "CF-Connecting-IP",
  "job_poll_interval_ms": 30000,
  "log_file": "/data/vaultwarden.log",
  "log_level": "warn",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "***************",
  "org_events_enabled": false,
  "org_groups_enabled": false,
  "password_hints_allowed": true,
  "password_iterations": 600000,
  "push_enabled": true,
  "push_installation_id": "***",
  "push_installation_key": "***",
  "push_relay_uri": "https://push.bitwarden.com",
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": false,
  "signups_domains_whitelist": "",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "************************",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": "********************",
  "smtp_password": "***",
  "smtp_port": 587,
  "smtp_security": "starttls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": "***************",
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": 180,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": true,
  "websocket_port": 3012,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}
  • Clients used:
    Mac desktop, Windows desktop, web vault, iOS, Safari, Chrome, Edge

Steps to reproduce

  1. Launch and log into desktop client (Mac or Windows). Fully quit client.
  2. Optionally log into a mobile client
  3. Launch and log into at least 2 browser extension clients (I tested on Safari, Chrome, and Edge)
  4. Close all but 1 browser
  5. In the remaining browser, log into the web vault, go into account settings and deauthorize sessions
  6. At this point the web vault, browser extension, and (if previously logged in) mobile clients will immediately log themselves out
  7. Open the desktop client and the other browsers where you logged yourself in before
  8. Some/all of the clients launched in the above step will still be logged in (asking for PIN/biometrics) and showing cached data. You have full access to the data saved in the vault, until you try to change something. Forcing sync results in "sync failed", but no logout.

Expected behaviour

All clients logged out immediately following deauthorization of all sessions.

Actual behaviour

Some clients that were offline when sessions were deauthorized remain logged in with full access to cached data when launched.

Originally created by @SoOutnumb3r3d on GitHub. <!-- # ### NOTE: Please update to the latest version of vaultwarden before reporting an issue! This saves you and us a lot of time and troubleshooting. See: * https://github.com/dani-garcia/vaultwarden/issues/1180 * https://github.com/dani-garcia/vaultwarden/wiki/Updating-the-vaultwarden-image # ### --> <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them. Remember to hide/redact personal or confidential information, such as passwords, IP addresses, and DNS names as appropriate. --> ### Subject of the issue <!-- Describe your issue here. --> Using the Deauthorize Sessions feature of the web client isn't logging out all clients immediately like it should. I've experimented a bunch of times to try to figure out in what scenarios clients are logged out and when they're not. So far, I've found that after deauthorizing sessions: - Clients are logged out immediately if they're running and online - Mobile clients are always logged out immediately (I'm running the latest testing build with push, so that may explain that one) - For clients that are closed/offline, they are usually not logged out when opening the client following de-auth, but sometimes they are - If the clients are NOT logged out, they will still show cached data as behave as if nothing is wrong (this is bad, security-wise). Forcing an explicit sync of the client through its UI, it presents a "sync failed" error, but the client remains logged in and the cached data remains available. Making any changes, though, results in the client logging itself out I've tested this behaviour against vault.bitwarden.com, and over there deauthorizing sessions does what one expects (immediate logout of all clients, regardless of whether they're running or online/offline). ### Deployment environment <!-- ========================================================================================= Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab. That will auto-generate most of the info requested in this section. ========================================================================================= --> ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.28.1-e7f083de * Web-vault version: v2023.5.0 * OS/Arch: linux/x86_64 * Running within Docker: true (Base: Debian) * Environment settings overridden: false * Uses a reverse proxy: true * IP Header check: true (CF-Connecting-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Browser/Server Time Check: true * Server/NTP Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: SQLite * Database version: 3.41.2 * Clients used: * Reverse proxy and version: * Other relevant information: ### Config (Generated via diagnostics page) <details><summary>Show Running Config</summary> **Environment settings which are overridden:** ```json { "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": false, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "_smtp_img_src": "cid:", "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_session_lifetime": 20, "admin_token": "***", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "authenticator_disable_time_drift": false, "data_folder": "data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "***************", "db_connection_retries": 15, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://*****************", "domain_origin": "*****://*****************", "domain_path": "", "domain_set": true, "duo_host": null, "duo_ikey": null, "duo_skey": null, "email_attempts_limit": 3, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 3 * * * *", "emergency_request_timeout_schedule": "0 7 * * * *", "enable_db_wal": true, "event_cleanup_schedule": "0 10 0 * * *", "events_days_retain": null, "extended_logging": true, "helo_name": null, "hibp_api_key": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "invitation_expiration_hours": 120, "invitation_org_name": "Vaultwarden", "invitations_allowed": true, "ip_header": "CF-Connecting-IP", "job_poll_interval_ms": 30000, "log_file": "/data/vaultwarden.log", "log_level": "warn", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": null, "org_creation_users": "***************", "org_events_enabled": false, "org_groups_enabled": false, "password_hints_allowed": true, "password_iterations": 600000, "push_enabled": true, "push_installation_id": "***", "push_installation_key": "***", "push_relay_uri": "https://push.bitwarden.com", "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sendmail_command": null, "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": false, "signups_domains_whitelist": "", "signups_verify": false, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": null, "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "************************", "smtp_from_name": "Vaultwarden", "smtp_host": "********************", "smtp_password": "***", "smtp_port": 587, "smtp_security": "starttls", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": "***************", "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": 180, "trash_purge_schedule": "0 5 0 * * *", "use_sendmail": false, "use_syslog": false, "user_attachment_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "websocket_address": "0.0.0.0", "websocket_enabled": true, "websocket_port": 3012, "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details> * Clients used: <!-- web vault, desktop, Android, iOS, etc. (if applicable) --> Mac desktop, Windows desktop, web vault, iOS, Safari, Chrome, Edge ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start vaultwarden? --> 1. Launch and log into desktop client (Mac or Windows). Fully quit client. 2. Optionally log into a mobile client 3. Launch and log into at least 2 browser extension clients (I tested on Safari, Chrome, and Edge) 4. Close all but 1 browser 5. In the remaining browser, log into the web vault, go into account settings and deauthorize sessions 6. At this point the web vault, browser extension, and (if previously logged in) mobile clients will immediately log themselves out 7. Open the desktop client and the other browsers where you logged yourself in before 8. Some/all of the clients launched in the above step will still be logged in (asking for PIN/biometrics) and showing cached data. You have full access to the data saved in the vault, until you try to change something. Forcing sync results in "sync failed", but no logout. ### Expected behaviour <!-- Tell us what you expected to happen --> All clients logged out immediately following deauthorization of all sessions. ### Actual behaviour <!-- Tell us what actually happened --> Some clients that were offline when sessions were deauthorized remain logged in with full access to cached data when launched.
OVERLORD added the troubleshootinghelp wanted labels 2025-10-09 16:52:01 +03:00
OVERLORD commented 2025-10-09 16:52:05 +03:00
Author
Owner
Copy Link

@SoOutnumb3r3d commented on GitHub:

I don't use Firefox, but when it happens to me on the Safari and Chrome extensions it behaves like the desktop client -- it doesn't log me out when I tell it to sync.

I've been running websockets using port 80 since switching over to the testing build.

To test whether it's influenced by Mobile Push, I still had my vaultwarden:latest container so I just ran a test on that one (which uses 3012 for websockets). Same behaviour as vaultwarden:testing, except that the iOS client didn't log out automatically due to lack of push.

@SoOutnumb3r3d commented on GitHub: I don't use Firefox, but when it happens to me on the Safari and Chrome extensions it behaves like the desktop client -- it doesn't log me out when I tell it to sync. I've been running websockets using port 80 since switching over to the testing build. To test whether it's influenced by Mobile Push, I still had my vaultwarden:latest container so I just ran a test on that one (which uses 3012 for websockets). Same behaviour as vaultwarden:testing, except that the iOS client didn't log out automatically due to lack of push.
OVERLORD commented 2025-10-09 16:52:05 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

I did some quick testing and twice it seemed to fully logout all clients which were connected if i keep them active.
If i close the Desktop Client, and start after the deauth, I am able to unlock (not login) the vault.

If i then try to sync it indeed keeps active and doesn't log out. While it does for the Firefox Extension for example.
It still allows me to unlock, but when i want it to sync, it will log out the extension.

So, there seems to be something strange for the Desktop Client, and i have not yet tested a Bitwarden (Self) hosted environment yet.

I do wonder, what happens if you disable the Mobile Push feature? Does that then still cause the same behaviour?
Also, which web-sockets way do you use? Are you still using port 3012? Or have you disabled those and are you using web-sockets over the main port?

@BlackDex commented on GitHub: I did some quick testing and twice it seemed to fully logout all clients which were connected if i keep them active. If i close the Desktop Client, and start after the deauth, I am able to unlock (not login) the vault. If i then try to sync it indeed keeps active and doesn't log out. While it does for the Firefox Extension for example. It still allows me to unlock, but when i want it to sync, it will log out the extension. So, there seems to be something strange for the Desktop Client, and i have not yet tested a Bitwarden (Self) hosted environment yet. I do wonder, what happens if you disable the Mobile Push feature? Does that then still cause the same behaviour? Also, which web-sockets way do you use? Are you still using port 3012? Or have you disabled those and are you using web-sockets over the main port?
OVERLORD commented 2025-10-09 16:52:05 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

@SoOutnumb3r3d I just tested a Bitwarden Self-Hosted environment, and it behaves exactly the same for me as Vaultwarden does.

There is just one client which doesn't logout, only after a sync it does and that is the Desktop client.
So, for me it works as expected and Vaultwarden behaves the same as Bitwarden does.

I used Chromium and Firefox both extensions and web-vault and also the Desktop Client.
So, i actually think we can't do anything to solve your issue.

All the clients are build to are able to work offline and if someone just disables the internet and unlocks the vault they can access the vault and export (if they know the password of course).

In regards to the Desktop Client, you might want to test it also on vault.bitwarden.com and if that has the same results, report an issue there.

@BlackDex commented on GitHub: @SoOutnumb3r3d I just tested a Bitwarden Self-Hosted environment, and it behaves exactly the same for me as Vaultwarden does. There is just one client which doesn't logout, only after a sync it does and that is the Desktop client. So, for me it works as expected and Vaultwarden behaves the same as Bitwarden does. I used Chromium and Firefox both extensions and web-vault and also the Desktop Client. So, i actually think we can't do anything to solve your issue. All the clients are build to are able to work offline and if someone just disables the internet and unlocks the vault they can access the vault and export (if they know the password of course). In regards to the Desktop Client, you might want to test it also on `vault.bitwarden.com` and if that has the same results, report an issue there.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
better for forum
bug
bug
bug
documentation
duplicate
enhancement
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
SSO
Third party
troubleshooting
troubleshooting
wontfix
No Label help wanted troubleshooting
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#799
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?