Login with device doesn't work with multiple replicas #2244

New Issue

OVERLORD · 2026-02-05T03:42:03+03:00

OVERLORD commented

2026-02-05 03:42:03 +03:00

Originally created by @denysvitali on GitHub (Apr 23, 2025).

Vaultwarden Support String

Your environment (Generated via diagnostics page)

Vaultwarden version: v1.33.2
Web-vault version: v2025.1.1
OS/Arch: linux/aarch64
Running within a container: true (Base: Debian)
Database type: PostgreSQL
Database version: PostgreSQL 17.4 (Debian 17.4-1.pgdg110+2) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
Environment settings overridden!: true
Uses a reverse proxy: true
IP Header check: true (X-Forwarded-For)
Internet access: true
Internet access via a proxy: false
DNS Check: true
Browser/Server Time Check: true
Server/NTP Time Check: n/a
Domain Configuration Check: true
HTTPS Check: true
Websocket Check: true
HTTP Response Checks: true

Config & Details (Generated via diagnostics page)

Show Config & Details

Environment settings which are overridden: DOMAIN, ADMIN_TOKEN

(The rest of the config was omitted)

Vaultwarden Build Version

v1.33.2

Deployment method

Official Container Image

Custom deployment method

Vaultwarden deployed via a Deployment and connected to an PostgreSQL HA cluster (via CloudNativePG).

Reverse Proxy

Traefik

Host/Server Operating System

Linux

Clients

Web Vault

Steps To Reproduce

Deploy Vaultwarden in HA mode (multiple replicas)
Use "Login With Device"

Expected Result

User is able to log-in on the first try

Actual Result

User has to be "lucky" that the accepted authentication response ends up on the same instance as the client is listening on (websocket).

Additional Context

When deployed using Kubernetes, multiple replicas and using PostgreSQL - Login With Device is partially faulty.

It looks like the implementation of the /anonymous-hub websocket server doesn't consider the fact that the accepted login message doesn't come from the same instance where the client is listening on.

sequenceDiagram
    participant Client as Client Device
    participant AuthDevice as Authorizing Device
    participant PodA as Vaultwarden Pod A
    participant PodB as Vaultwarden Pod B
    participant DB as PostgreSQL

    Note over PodA,PodB: Kubernetes with multiple replicas
    
    Client->>PodA: 1. Connect to /anonymous-hub WebSocket
    PodA-->>PodA: 2. Create WebSocket connection
    Client->>PodA: 3. Send device login request
    PodA->>DB: 4. Store device_token in PostgreSQL
    PodA-->>Client: 5. Return verification text/fingerprint
    
    AuthDevice->>PodB: 6. Load approval page (different pod!)
    AuthDevice->>PodB: 7. Approve device login
    PodB->>DB: 8. Update token status to approved
    
    PodB-->>PodB: 9. Send approval notification
    Note over PodB: ❌ Problem: Notification sent within Pod B
    
    Note over Client,PodA: But client is connected to Pod A's WebSocket!
    Note over Client: Client never receives approval notification
    Note over Client: WebSocket times out or fails

Originally created by @denysvitali on GitHub (Apr 23, 2025). ### Vaultwarden Support String ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.33.2 * Web-vault version: v2025.1.1 * OS/Arch: linux/aarch64 * Running within a container: true (Base: Debian) * Database type: PostgreSQL * Database version: PostgreSQL 17.4 (Debian 17.4-1.pgdg110+2) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit * Environment settings overridden!: true * Uses a reverse proxy: true * IP Header check: true (X-Forwarded-For) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Browser/Server Time Check: true * Server/NTP Time Check: n/a * Domain Configuration Check: true * HTTPS Check: true * Websocket Check: true * HTTP Response Checks: true ### Config & Details (Generated via diagnostics page) <details><summary>Show Config & Details</summary> **Environment settings which are overridden:** DOMAIN, ADMIN_TOKEN (The rest of the config was omitted) </details> ### Vaultwarden Build Version v1.33.2 ### Deployment method Official Container Image ### Custom deployment method Vaultwarden deployed via a `Deployment` and connected to an PostgreSQL HA cluster (via CloudNativePG). ### Reverse Proxy Traefik ### Host/Server Operating System Linux ### Clients Web Vault ### Steps To Reproduce 1. Deploy Vaultwarden in HA mode (multiple replicas) 2. Use "Login With Device" ### Expected Result User is able to log-in on the first try ### Actual Result User has to be "lucky" that the accepted authentication response ends up on the same instance as the client is listening on (websocket). ### Additional Context When deployed using Kubernetes, multiple replicas and using PostgreSQL - Login With Device is partially faulty. It looks like the implementation of the `/anonymous-hub` websocket server doesn't consider the fact that the accepted login message doesn't come from the same instance where the client is listening on. ```mermaid sequenceDiagram participant Client as Client Device participant AuthDevice as Authorizing Device participant PodA as Vaultwarden Pod A participant PodB as Vaultwarden Pod B participant DB as PostgreSQL Note over PodA,PodB: Kubernetes with multiple replicas Client->>PodA: 1. Connect to /anonymous-hub WebSocket PodA-->>PodA: 2. Create WebSocket connection Client->>PodA: 3. Send device login request PodA->>DB: 4. Store device_token in PostgreSQL PodA-->>Client: 5. Return verification text/fingerprint AuthDevice->>PodB: 6. Load approval page (different pod!) AuthDevice->>PodB: 7. Approve device login PodB->>DB: 8. Update token status to approved PodB-->>PodB: 9. Send approval notification Note over PodB: ❌ Problem: Notification sent within Pod B Note over Client,PodA: But client is connected to Pod A's WebSocket! Note over Client: Client never receives approval notification Note over Client: WebSocket times out or fails ```

OVERLORD added the bug label 2026-02-05 03:42:03 +03:00

OVERLORD closed this issue

2026-02-05 03:42:09 +03:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#2244