Authentication in WebSocket connections in Express - Deep Dive

Overview - Authentication in WebSocket connections

What is it?

Authentication in WebSocket connections means verifying who is trying to connect before allowing them to communicate. Unlike regular web pages, WebSockets keep a connection open for a long time, so checking identity once at the start is important. This process ensures only trusted users can send or receive messages through the WebSocket. It usually happens during the initial handshake or right after the connection opens.

Why it matters

Without authentication, anyone could connect to your WebSocket server and send or receive messages, which can lead to data leaks, unauthorized actions, or security breaches. Imagine a chat room where strangers can join without permission and see private conversations. Authentication protects your app’s data and users by making sure only the right people get access.

Where it fits

Before learning this, you should understand basic WebSocket concepts and how HTTP authentication works. After this, you can explore advanced security topics like token refresh, encryption, and scaling authenticated WebSocket servers.

Mental Model

Core Idea

Authentication in WebSocket connections is the process of verifying a user’s identity once when the connection starts to keep the communication secure and trusted.

Think of it like...

It’s like showing your ID at the entrance of a club before the door lets you in and keeps you inside for the whole night without checking again.

Client                      Server
  │                           │
  │--- WebSocket handshake --->│  (includes auth info)
  │                           │
  │<-- Accept or Reject -------│
  │                           │
  │==== Open secure channel ===│
  │                           │

Build-Up - 7 Steps

1

Foundation

Basics of WebSocket Connections

Concept: Understand what a WebSocket connection is and how it differs from regular HTTP.

A WebSocket connection starts with a handshake over HTTP, then upgrades to a persistent, full-duplex channel. This means both client and server can send messages anytime without reopening connections. Unlike HTTP requests that open and close quickly, WebSockets stay open until closed explicitly.

Result

You know that WebSocket connections are long-lived and allow two-way communication.

Understanding the persistent nature of WebSockets is key because authentication must happen early and be trusted for the entire session.

2

Foundation

What is Authentication?

Concept: Learn what authentication means in web applications.

Authentication is the process of checking who a user is, usually by verifying credentials like usernames and passwords or tokens. It happens before giving access to protected resources. In HTTP, this often uses cookies, headers, or tokens.

Result

You understand that authentication confirms identity before access is granted.

Knowing authentication basics helps you see why WebSocket connections also need identity checks, even though they work differently from HTTP.

3

Intermediate

Authentication During WebSocket Handshake

🤔Before reading on: do you think WebSocket authentication happens after connection opens or during the handshake? Commit to your answer.

Concept: Learn how authentication can be done during the initial WebSocket handshake using HTTP headers or query parameters.

Since the WebSocket handshake starts as an HTTP request, you can include authentication info like tokens in headers or URL query strings. The server checks this info before accepting the connection. If invalid, the server rejects the handshake, preventing the connection.

Result

You can authenticate users before the WebSocket connection is fully established.

Understanding that the handshake is an HTTP request lets you reuse familiar authentication methods to secure WebSocket connections early.

4

Intermediate

Using Tokens for WebSocket Authentication

🤔Before reading on: do you think cookies or tokens are better for WebSocket auth? Commit to your answer.

Concept: Explore why tokens like JWT are preferred for authenticating WebSocket connections over cookies.

Cookies are tied to HTTP and may not be sent automatically in WebSocket handshakes. Tokens like JWT can be sent explicitly in headers or query strings. They carry encoded user info and can be verified without server-side sessions, making them ideal for WebSocket auth.

Result

You know how to use tokens to authenticate WebSocket clients securely and efficiently.

Knowing token advantages helps you design stateless, scalable WebSocket authentication systems.

5

Intermediate

Authenticating After Connection Opens

Concept: Learn how to authenticate users by sending credentials as the first message after the WebSocket opens.

Sometimes authentication happens after the connection is established by requiring the client to send a login message with credentials or tokens. The server then verifies and either allows further communication or closes the connection.

Result

You understand an alternative to handshake authentication that can be useful in some scenarios.

Knowing this method helps when handshake authentication is not possible or when you want to separate connection setup from authentication.

6

Advanced

Handling Authentication State in WebSocket Server

🤔Before reading on: do you think WebSocket servers keep user info per connection or globally? Commit to your answer.

Concept: Understand how servers track authenticated users per WebSocket connection and manage their state.

Each WebSocket connection is unique, so servers store authentication info (like user ID) linked to that connection object. This allows the server to check permissions on every message. If authentication fails or expires, the server can close that connection.

Result

You can manage user identity securely throughout the WebSocket session.

Knowing connection-specific state management prevents security holes where unauthenticated users might send messages.

7

Expert

Security Pitfalls and Best Practices

🤔Before reading on: do you think sending tokens in URL query strings is always safe? Commit to your answer.

Concept: Learn about common security risks and how to avoid them when authenticating WebSocket connections.

Sending tokens in URLs can expose them in logs or browser history. Using secure headers or encrypted connections (wss://) is safer. Also, tokens should be short-lived and validated carefully. Implementing reconnection and token refresh strategies improves security and user experience.

Result

You can design robust, secure WebSocket authentication that avoids common vulnerabilities.

Understanding these risks and mitigations is crucial for building production-ready, secure WebSocket applications.

Under the Hood

WebSocket authentication leverages the initial HTTP handshake where the client sends an Upgrade request. Authentication data like tokens or cookies are included in this request. The server middleware intercepts this handshake, extracts and verifies credentials, and decides to accept or reject the connection. Once accepted, the connection upgrades to a persistent TCP socket where no further HTTP headers are exchanged, so authentication must be trusted from the handshake or managed via messages.

Why designed this way?

WebSockets were designed to upgrade from HTTP to allow real-time communication without repeated handshakes. Embedding authentication in the handshake reuses existing HTTP mechanisms, avoiding extra round-trips. This design balances efficiency and security, but requires careful token handling since the connection stays open long-term.

Client HTTP Request
  ┌─────────────────────────────┐
  │ GET /chat HTTP/1.1          │
  │ Host: example.com           │
  │ Upgrade: websocket          │
  │ Connection: Upgrade         │
  │ Sec-WebSocket-Key: ...      │
  │ Authorization: Bearer TOKEN │
  └─────────────────────────────┘
           │
           ▼
Server Middleware
  ┌─────────────────────────────┐
  │ Extract Authorization header │
  │ Verify token validity        │
  │ Accept or reject handshake   │
  └─────────────────────────────┘
           │
           ▼
WebSocket Connection Established
  ┌─────────────────────────────┐
  │ Persistent, full-duplex      │
  │ communication channel        │
  └─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think WebSocket connections automatically send cookies like HTTP requests? Commit to yes or no.

Common Belief: WebSocket connections automatically include cookies for authentication just like normal HTTP requests.

Reality: WebSocket handshakes do not always send cookies automatically, especially in cross-origin scenarios, so relying on cookies alone can fail.

Why it matters: Assuming cookies always work can cause silent authentication failures, letting unauthorized users connect or blocking valid users.

Quick: Is it safe to send authentication tokens in the URL query string? Commit to yes or no.

Common Belief: Sending tokens in the URL query string is safe and convenient for WebSocket authentication.

Reality: Tokens in URLs can be exposed in browser history, server logs, or referer headers, risking token theft.

Why it matters: Exposing tokens can lead to account hijacking or unauthorized access, compromising security.

Quick: Do you think once authenticated, WebSocket connections never need re-authentication? Commit to yes or no.

Common Belief: After the initial authentication, WebSocket connections remain trusted forever without checks.

Reality: Tokens can expire or be revoked; without re-authentication or token refresh, connections may stay open insecurely.

Why it matters: Ignoring token expiry can allow attackers to use stolen tokens indefinitely, risking data leaks.

Quick: Do you think authentication can be done only after the WebSocket connection is open? Commit to yes or no.

Common Belief: Authentication must always happen during the handshake and cannot be done after connection opens.

Reality: Authentication can also happen after connection by sending credentials as the first message, though handshake auth is preferred.

Why it matters: Knowing this allows flexible designs where handshake auth is impossible or inconvenient.

Expert Zone

1

Some WebSocket libraries allow middleware to run during handshake, but others require manual token parsing, affecting implementation complexity.

2

Token validation often includes checking signature, expiry, and user permissions, which can be costly; caching results per connection improves performance.

3

Handling reconnections securely requires re-authenticating or validating tokens again to avoid session fixation or hijacking.

When NOT to use

If your application does not require persistent identity or sensitive data exchange, you might skip authentication or use simpler methods like IP filtering. For very high-security needs, consider using mutual TLS or VPNs instead of token-based WebSocket authentication.

Production Patterns

In production, WebSocket authentication often uses JWT tokens passed in the 'Authorization' header during handshake, verified by middleware. Servers store user info in connection context for message authorization. Token refresh is handled by closing and reopening connections or sending special refresh messages. Secure WebSocket (wss://) is mandatory to protect tokens in transit.

Connections

HTTP Authentication

WebSocket authentication builds on HTTP authentication methods by reusing headers and tokens during the handshake.

Understanding HTTP auth helps grasp how WebSocket connections start securely before upgrading protocols.

Token-Based Security

WebSocket authentication commonly uses token-based security like JWT, which is a stateless way to prove identity.

Knowing token security principles clarifies how WebSocket servers verify users without storing session data.

Network Security Protocols

WebSocket authentication relies on secure transport protocols like TLS to protect credentials during handshake.

Understanding TLS and encryption shows why wss:// is essential to prevent token interception.

Common Pitfalls

#1 Sending authentication tokens in URL query parameters without encryption.

Wrong approach:

const ws = new WebSocket('wss://example.com/socket?token=abc123');

Correct approach:

const ws = new WebSocket('wss://example.com/socket');
ws.on('open', () => {
ws.send(JSON.stringify({ type: 'auth', token: 'abc123' }));
});

Root cause:

Misunderstanding that URLs are often logged or cached, exposing sensitive tokens.

#2 Not verifying authentication tokens during the WebSocket handshake.

Wrong approach:

server.on('connection', (socket) => {
// No token check here
socket.on('message', handleMessage);
});

Correct approach:

server.on('headers', (headers, request) => {
const token = extractToken(request);
if (!verifyToken(token)) {
request.destroy();
}
});

Root cause:

Assuming connection acceptance means authentication succeeded.

#3 Assuming cookies are sent automatically with WebSocket handshake requests.

Wrong approach:

Using cookie-based session auth without explicitly handling cookies in handshake.

Correct approach:

Extract cookies manually from handshake headers or use token-based auth instead.

Root cause:

Confusing HTTP request behavior with WebSocket handshake behavior.

Key Takeaways

WebSocket authentication secures long-lived connections by verifying identity during or immediately after the handshake.

Tokens like JWT are preferred over cookies because they work reliably in WebSocket handshakes and support stateless servers.

Authentication must be trusted for the entire connection lifetime since WebSockets do not resend credentials on each message.

Security best practices include using secure connections (wss://), avoiding token exposure in URLs, and handling token expiry.

Understanding WebSocket authentication builds on HTTP auth and token security concepts but requires special handling due to protocol differences.