WebSockets & Realtime Systems Programming · Leçon

Authentification et autorisation

Intégrer des mécanismes d’authentification (par exemple JWT) lors de la négociation initiale et gérer les autorisations des utilisateurs pour les messages WebSocket.

Leçon 2 sur 411 étapes

Authentification et autorisation est une leçon WebSockets & Realtime Systems Programming gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage WebSockets & Realtime Systems Programming, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours WebSockets & Realtime Systems Programming comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

Securing WebSocket Interactions

WebSockets enable powerful real-time communication. But just like any web interaction, we need to know who is connecting and what they are allowed to do.

This is where authentication and authorization come in. They are crucial for building secure and reliable applications.

Auth Challenges for WebSockets

Unlike traditional HTTP requests, which are stateless and often carry authentication headers with each request, WebSockets establish a persistent, stateful connection.

This means we authenticate once during the initial connection handshake, and then the server must remember the client's identity for the duration of the connection.

Authentication During Handshake

The perfect moment to authenticate a client is during the WebSocket handshake. This is the initial HTTP request that upgrades to a WebSocket connection.

  • The client sends an HTTP GET request with a Upgrade: websocket header.
  • The server can inspect this request for authentication credentials before deciding to upgrade.
  • If credentials are valid, the connection is established; otherwise, it's rejected.

Passing Credentials: Query Params

One way to pass credentials is via query parameters in the WebSocket URL. For example: ws://server.com/chat?token=your_jwt.

  • Pros: Simple to implement.
  • Cons: Can expose sensitive tokens in server logs or browser history. Generally less secure and not recommended for production.

Passing Credentials: HTTP Headers

A more secure and recommended approach is to pass authentication tokens within HTTP headers during the handshake.

While the standard WebSocket API doesn't directly support custom headers, some libraries or proxy configurations allow this. Often, custom headers like Authorization: Bearer your_jwt are used, or tokens are embedded in the Sec-WebSocket-Protocol header.

What is a JSON Web Token (JWT)?

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. It's often used for authentication.

  • It's digitally signed, ensuring its authenticity.
  • It contains user information (like user ID, roles) in a payload.
  • The server verifies the JWT signature to confirm the user's identity.

Server-Side JWT Handshake (Node.js)

Here's a simplified Node.js example using the ws library showing how a server might verify a JWT from a query parameter during the handshake. In a real app, you'd use a robust JWT library.

const WebSocket = require('ws');
const url = require('url');

const wss = new WebSocket.Server({ noServer: true });

wss.on('connection', function connection(ws, request) {
  const userId = request.userId; // Set during handshake verification
  console.log(`Client ${userId} connected`);

  ws.on('message', function incoming(message) {
    console.log(`Received from ${userId}: ${message}`);
  });

  ws.on('close', () => console.log(`Client ${userId} disconnected`));
});

// This is where you would integrate with an HTTP server
// For simplicity, we'll simulate the handshake here.

// Simulate an HTTP server upgrade listener
// In a real app, this would be an http.Server.on('upgrade')
function handleUpgrade(request, socket, head) {
  const pathname = url.parse(request.url).pathname;

  if (pathname === '/ws') {
    const token = new URLSearchParams(url.parse(request.url).query).get('token');
    
    // --- Simulate JWT verification ---
    if (token === 'valid_jwt_123') {
      request.userId = 'user_1'; // Attach user info to request
      wss.handleUpgrade(request, socket, head, function done(ws) {
        wss.emit('connection', ws, request);
      });
    } else {
      console.log('Invalid JWT. Connection rejected.');
      socket.destroy();
    }
  } else {
    socket.destroy();
  }
}

// Example usage (not a full http server, just for demonstration)
const mockRequest = {
  url: '/ws?token=valid_jwt_123',
  headers: { 'upgrade': 'websocket', 'connection': 'upgrade' }
};
const mockSocket = { 
  destroy: () => console.log('Socket destroyed (connection rejected)') 
};
const mockHead = Buffer.alloc(0);

console.log('Attempting connection with valid token...');
handleUpgrade(mockRequest, mockSocket, mockHead);

// Attempt connection with invalid token
const mockInvalidRequest = {
  url: '/ws?token=invalid_jwt',
  headers: { 'upgrade': 'websocket', 'connection': 'upgrade' }
};
const mockInvalidSocket = { 
  destroy: () => console.log('Socket destroyed (connection rejected)') 
};
console.log('\nAttempting connection with invalid token...');
handleUpgrade(mockInvalidRequest, mockInvalidSocket, mockHead);

Authorization: Who Can Do What?

Once a user is authenticated (we know who they are), authorization determines what actions they are permitted to perform.

This often involves checking user roles or permissions associated with their authenticated identity. For example, a 'guest' user might only be able to read messages, while an 'admin' can also delete them.

Message-Level Authorization (Node.js)

After a WebSocket connection is established and the user is authenticated, the server can enforce authorization rules on incoming messages. This example shows a simple check based on a user's role.

const WebSocket = require('ws');

// Simulate a WebSocket server for demonstration
const wss = new WebSocket.Server({ port: 8080 });

// In a real application, user info (like roles) would be
// stored in the ws object after successful authentication.
const connectedClients = new Map(); // Map ws -> { userId, role }

wss.on('connection', function connection(ws) {
  // Simulate authenticated user and their role
  const userId = `user_${Math.floor(Math.random() * 100)}`;
  const role = (userId === 'user_10') ? 'admin' : 'member';
  connectedClients.set(ws, { userId, role });

  console.log(`Client ${userId} (${role}) connected.`);
  ws.send(`Welcome, ${userId}! Your role is ${role}.`);

  ws.on('message', function incoming(message) {
    const clientInfo = connectedClients.get(ws);
    const msg = message.toString();

    console.log(`Received from ${clientInfo.userId}: ${msg}`);

    // --- Authorization Check ---
    if (msg.startsWith('/delete') && clientInfo.role !== 'admin') {
      ws.send('Error: You are not authorized to delete messages.');
      console.log(`${clientInfo.userId} (member) tried to delete.`);
    } else if (msg.startsWith('/delete') && clientInfo.role === 'admin') {
      ws.send('Message deleted successfully!');
      console.log(`${clientInfo.userId} (admin) deleted a message.`);
      // In a real app, delete logic would go here
    } else {
      // Broadcast message to others or process normally
      wss.clients.forEach(function each(client) {
        if (client !== ws && client.readyState === WebSocket.OPEN) {
          client.send(`${clientInfo.userId}: ${msg}`);
        }
      });
      ws.send(`You said: ${msg}`);
    }
  });

  ws.on('close', () => {
    const clientInfo = connectedClients.get(ws);
    console.log(`Client ${clientInfo.userId} disconnected.`);
    connectedClients.delete(ws);
  });
});

console.log('WebSocket server started on port 8080. Try connecting with a WebSocket client!');
console.log('Simulated user_10 is an admin, others are members.');

Auth & Auth Quick Check

When is the most appropriate and secure time to authenticate a client in a WebSocket connection?

Recap: Secure Connections

We've explored how to secure WebSocket connections by implementing authentication and authorization.

  • Authentication happens primarily during the handshake, often using JWTs passed in headers.
  • Authorization determines user permissions, controlling what actions they can take over the established connection.
  • These mechanisms are vital for protecting your real-time applications from unauthorized access and actions.
Gratuit pour commencer

Apprends WebSockets & Realtime Systems Programming avec un tuteur IA — gratuit

Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.

Cours
12
Leçons
47

Questions Fréquemment Posées

La leçon « Authentification et autorisation » est-elle gratuite ?

Oui — le texte complet de « Authentification et autorisation » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours WebSockets & Realtime Systems Programming, passe à CoddyKit PRO. Le cours WebSockets & Realtime Systems Programming comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Authentification et autorisation » ?

Intégrer des mécanismes d’authentification (par exemple JWT) lors de la négociation initiale et gérer les autorisations des utilisateurs pour les messages WebSocket. Tu pratiques WebSockets & Realtime Systems Programming avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer WebSockets & Realtime Systems Programming ?

Aucune expérience préalable n'est requise. WebSockets & Realtime Systems Programming sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Authentification et autorisation » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon WebSockets & Realtime Systems Programming ?

Oui. Chaque leçon WebSockets & Realtime Systems Programming inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. WebSocket sécurisé (WSS) et TLS
  2. Authentification et autorisation
  3. Prévention des attaques courantes contre les WebSockets
  4. Limitation du débit et prévention des abus
← Retour à WebSockets & Realtime Systems Programming