Define the reconnect rules
Write down token expiry, session revocation, allowed subscriptions, and replay windows. Test a role change while a socket is open, then reconnect using both old and new tokens. If the server allows a resume cursor, make sure it cannot retrieve events from a different account. A useful log records connection ID, account reference, subscription, and closure reason without storing a raw bearer token.
Test cases and proof
| Case | Expected result | Proof to keep |
|---|---|---|
| Reconnect with revoked token | Deny private stream at the deployed auth gate | Connection result |
| Role removed during live socket | Stop private events | Event trace |
| Resume cursor from another account | Deny replay | Messages delivered |
Synthetic example
A customer opens a live balance stream, then signs out from another device. Try to reconnect with the old token and resume cursor. The new connection must not gain private-stream access, and the prior stream must follow your documented revocation policy.
Evidence to keep
Record the socket connection ID, token issue time, revocation time, subscription name, and last delivered event. A handshake rejection does not prove an already-open connection stopped sending data. Run the same event after logout and role change, then inspect messages delivered to both old and new sockets. Use fake event payloads with account markers.
A reconnect can happen automatically while the phone is locked. Test that path as well as a manual refresh. Record whether the app asks for sign-in after revocation or silently loops through failed reconnects. A clear recovery screen is part of the expected result for the customer.
A rejected handshake is only one result
The first socket may stay open after a role changes. A reconnect can also use a resume cursor that asks for old events. Check the live stream, new handshake, subscription request, and replay result separately. If the server closes sockets on revocation, the client needs a clear sign-in screen rather than endless silent reconnect attempts. If the server rechecks rights before each event, verify that no private event slips through the gap. Use fake account markers so every delivered message has a known owner.
Related reading
Why these checks matter
OWASP’s WebSocket guide covers authentication and authorization over long-lived connections. Its authorization guide calls for checks on each access path. Reconnect and event replay are fresh access paths. The test also inspects an already-open socket after revocation, since refusing a new handshake alone may leave private events flowing.
Test the protocol’s actual login gate
A WebSocket can authenticate during the HTTP upgrade using a cookie or supported header, or through an application message after upgrade. Browser WebSocket clients cannot set arbitrary Authorization headers through the standard constructor. Name the deployed pattern. For handshake authentication, a revoked credential should fail upgrade. For in-band authentication, the socket may open but must receive no private event or subscription before a valid auth message.
Synthetic account A1 emits events E1, E2, and E3. Connect as A and receive E1. Revoke A, then emit E2 after the chosen revocation window. Expect no E2 on the old socket. Reconnect with the old credential and cursor E1; expect no replay. A server-side close is useful evidence, but the delivered event list is the result.
Keep replay scope and reconnect behavior clear
Try E1’s resume cursor under B’s session and on a different channel. Reject it or re-scope the replay to B’s authorized records under the documented contract. Do not let a cursor name a subscription that bypasses a current permission check. When retention has removed E1, return a clear resync path rather than silently replaying an unbounded history.
Test expired tokens, logout, role removal, and a queued notification separately. If revocation propagation takes five seconds in the test policy, measure it; do not promise immediate denial from a later reconnect result. The client should stop retrying a revoked credential and show sign-in, with backoff for transient network failures. Save connection ID, authentication pattern, subscription, event IDs, revocation time, and close reason. OWASP’s WebSocket guide covers long-lived authentication and message authorization.