0Pricing
NestJS Enterprise Backend APIs · Lektion

Socket-Verbindungen authentifizieren und absichern

Wenden Sie Guards und Token-Verifizierung auf Handshake- und Nachrichtenereignisse an, um sicheren Echtzeitzugriff zu gewährleisten

Socket-Verbindungen authentifizieren und absichern ist eine kostenlose NestJS Enterprise Backend APIs-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des NestJS Enterprise Backend APIs-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der NestJS Enterprise Backend APIs-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

Why Sockets Need Their Own Auth Story

HTTP routes in NestJS are protected by middleware and guards that read the Authorization header on every request. WebSockets are different: the client opens one long-lived connection during the handshake, then exchanges many messages over it.

  • You authenticate once at connection time, not per message.
  • The socket stays open for minutes or hours, so a token that expires mid-session is a real concern.
  • Standard HTTP guards do not automatically run on WebSocket events.

This lesson shows how to verify a token during the handshake, attach the user to the socket, and guard individual message events for secure realtime access.

Where the Token Lives in a Handshake

A browser WebSocket cannot set custom headers, so clients pass the token in one of three places during the Socket.IO handshake:

  • handshake.auth.token — the modern, preferred slot (set via the client auth option).
  • handshake.headers.authorization — works when a native header is available.
  • handshake.query.token — a fallback, but tokens land in server/proxy logs, so avoid it.

A small helper centralizes extraction so every guard and lifecycle hook reads the token the same way.

import { Socket } from 'socket.io';

export function extractToken(client: Socket): string | null {
  const auth = client.handshake.auth?.token;
  if (typeof auth === 'string') return auth;

  const header = client.handshake.headers?.authorization;
  if (typeof header === 'string' && header.startsWith('Bearer ')) {
    return header.slice(7);
  }

  return null;
}

Verifying on Connection with handleConnection

The cleanest place to authenticate is the gateway's handleConnection lifecycle hook. It runs the moment a client connects. If the token is missing or invalid, call client.disconnect() so the socket never participates in any room or event.

On success, attach the decoded user to client.data — a per-socket bag that survives for the connection's lifetime and is readable in every later event handler.

import { OnGatewayConnection, WebSocketGateway } from '@nestjs/websockets';
import { JwtService } from '@nestjs/jwt';
import { Socket } from 'socket.io';
import { extractToken } from './extract-token';

@WebSocketGateway({ cors: true })
export class ChatGateway implements OnGatewayConnection {
  constructor(private readonly jwt: JwtService) {}

  async handleConnection(client: Socket) {
    try {
      const token = extractToken(client);
      if (!token) throw new Error('No token');
      const payload = await this.jwt.verifyAsync(token);
      client.data.user = { id: payload.sub, role: payload.role };
    } catch {
      client.disconnect(true);
    }
  }
}

Modeling the Authenticated User

Storing client.data.user as an untyped object invites typos later. Define a small interface and a typed helper so every handler reads user.id and user.role with full IntelliSense and compile-time safety.

This is the same JWT payload pattern you use for HTTP routes, keeping authorization logic consistent across both transports.

export interface SocketUser {
  id: string;
  role: 'admin' | 'member' | 'guest';
}

export interface JwtPayload {
  sub: string;
  role: SocketUser['role'];
  exp: number;
}

export function toSocketUser(payload: JwtPayload): SocketUser {
  return { id: payload.sub, role: payload.role };
}

// Demo: a decoded token becomes a typed user
const payload: JwtPayload = { sub: 'u_42', role: 'member', exp: 1893456000 };
const user = toSocketUser(payload);
console.log(`${user.id} connected as ${user.role}`);

Guarding Individual Message Events

Connection-time auth proves who the user is, but some events also need authorization checks — for example, only admins can broadcast a system message. NestJS guards work on WebSocket events too; you just read the socket from the execution context.

Inside a guard, switch the context to ws, grab the client, and inspect client.data.user that handleConnection populated.

import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
import { WsException } from '@nestjs/websockets';
import { Socket } from 'socket.io';

@Injectable()
export class WsAuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const client = context.switchToWs().getClient<Socket>();
    const user = client.data.user;
    if (!user) {
      throw new WsException('Unauthorized');
    }
    return true;
  }
}

Role-Based Guards with Metadata

To restrict an event to certain roles, combine a custom decorator (storing required roles as metadata) with a guard that reads it via Reflector. This mirrors the HTTP @Roles() pattern, so your team learns one mental model.

The guard rejects the event with a WsException when the connected user lacks the required role — the message handler never runs.

import { SetMetadata } from '@nestjs/common';
export const WsRoles = (...roles: string[]) => SetMetadata('ws_roles', roles);

import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
import { Reflector } from '@nestjs/core';
import { WsException } from '@nestjs/websockets';
import { Socket } from 'socket.io';

@Injectable()
export class WsRolesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  canActivate(context: ExecutionContext): boolean {
    const required = this.reflector.get<string[]>('ws_roles', context.getHandler());
    if (!required?.length) return true;
    const user = context.switchToWs().getClient<Socket>().data.user;
    if (!user || !required.includes(user.role)) {
      throw new WsException('Forbidden');
    }
    return true;
  }
}

Applying Guards to Subscribe Handlers

Attach guards to message handlers with @UseGuards(), exactly like controller routes. Stack the base auth guard with the roles guard, and decorate the handler with the required roles.

Guards run in declaration order, so put the cheaper authentication check first and the role check second.

import { SubscribeMessage, WebSocketGateway, MessageBody } from '@nestjs/websockets';
import { UseGuards } from '@nestjs/common';
import { WsAuthGuard } from './ws-auth.guard';
import { WsRolesGuard } from './ws-roles.guard';
import { WsRoles } from './ws-roles.decorator';

@WebSocketGateway()
export class AdminGateway {
  @UseGuards(WsAuthGuard, WsRolesGuard)
  @WsRoles('admin')
  @SubscribeMessage('broadcast')
  handleBroadcast(@MessageBody() text: string) {
    return { event: 'broadcast', data: text };
  }
}

Why Guards Alone Miss the Handshake

A subtle gotcha: by default a WebSocket guard runs on message events, not on the initial connection. If you rely only on @UseGuards and skip handleConnection, an unauthenticated client can still open a socket and sit idle in your server.

  • Use handleConnection to reject unauthenticated sockets at the door.
  • Use event guards for fine-grained, per-action authorization.

The two layers complement each other: one controls entry, the other controls actions.

Surfacing Errors Cleanly to Clients

When a guard throws WsException, NestJS emits an exception event to that client instead of crashing the connection. Add a WsExceptionFilter to shape the payload so the frontend gets a predictable error object it can show to the user.

import { ArgumentsHost, Catch } from '@nestjs/common';
import { BaseWsExceptionFilter, WsException } from '@nestjs/websockets';
import { Socket } from 'socket.io';

@Catch(WsException)
export class WsErrorFilter extends BaseWsExceptionFilter {
  catch(exception: WsException, host: ArgumentsHost) {
    const client = host.switchToWs().getClient<Socket>();
    client.emit('error', {
      message: exception.getError(),
      timestamp: new Date().toISOString(),
    });
  }
}

Handling Token Expiry on a Live Socket

A connection authenticated an hour ago may now hold an expired token. Two common strategies:

  • Re-verify per sensitive event — store the raw token on client.data.token and call verifyAsync again inside the guard for high-value actions.
  • Periodic revalidation — a server interval checks each socket's token exp and disconnects expired ones.

This small pure function shows the expiry check at the heart of either approach.

interface TokenInfo {
  exp: number; // unix seconds
}

function isExpired(token: TokenInfo, nowSeconds: number): boolean {
  return token.exp <= nowSeconds;
}

const now = 1_700_000_000;
console.log(isExpired({ exp: 1_699_999_000 }, now)); // true  -> disconnect
console.log(isExpired({ exp: 1_700_500_000 }, now)); // false -> keep open

Wiring It Together in the Module

Guards that inject services like Reflector or JwtService must be resolvable by Nest's DI. Because the gateway and its guards live in the same module, register JwtModule and provide the gateway; the guards are instantiated by Nest when referenced in @UseGuards.

You can also register the auth guard globally for sockets with APP_GUARD if every event should be authenticated by default.

import { Module } from '@nestjs/common';
import { JwtModule } from '@nestjs/jwt';
import { APP_GUARD } from '@nestjs/core';
import { ChatGateway } from './chat.gateway';
import { WsAuthGuard } from './ws-auth.guard';

@Module({
  imports: [
    JwtModule.register({ secret: process.env.JWT_SECRET }),
  ],
  providers: [
    ChatGateway,
    { provide: APP_GUARD, useClass: WsAuthGuard },
  ],
})
export class RealtimeModule {}

Quick Check: Connection vs Event Auth

You want to (1) block unauthenticated clients from ever opening a socket and (2) allow only admin users to emit a broadcast event. Which combination correctly achieves both?

Recap: Securing Realtime Connections

You now have a complete, layered approach to securing NestJS WebSocket gateways:

  • Extract the token consistently from handshake.auth, headers, or query.
  • Authenticate at the door in handleConnection, disconnecting invalid clients and attaching the user to client.data.
  • Authorize per event with guards that switch to the ws context, including role checks via Reflector and a @WsRoles decorator.
  • Report errors through a WsException filter, and handle expiry with re-verification or periodic checks.

Connection auth controls entry; event guards control actions — together they keep your realtime system secure.

Häufig gestellte Fragen

Ist die Lektion „Socket-Verbindungen authentifizieren und absichern“ kostenlos?

Ja — der vollständige Text von „Socket-Verbindungen authentifizieren und absichern“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des NestJS Enterprise Backend APIs-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der NestJS Enterprise Backend APIs-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Socket-Verbindungen authentifizieren und absichern“?

Wenden Sie Guards und Token-Verifizierung auf Handshake- und Nachrichtenereignisse an, um sicheren Echtzeitzugriff zu gewährleisten Du übst NestJS Enterprise Backend APIs mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um NestJS Enterprise Backend APIs zu starten?

Keine Vorkenntnisse erforderlich. NestJS Enterprise Backend APIs auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Socket-Verbindungen authentifizieren und absichern“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser NestJS Enterprise Backend APIs-Lektion Code schreiben und ausführen?

Ja. Jede NestJS Enterprise Backend APIs-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. WebSocket-Gateways mit dem Socket.IO-Adapter
  2. Socket-Verbindungen authentifizieren und absichern
  3. Server-Sent Events für unidirektionales Push
  4. Echtzeit mit einem Redis-Pub/Sub-Adapter skalieren
← Zurück zu NestJS Enterprise Backend APIs