Sécurité en temps réel

Vos règles de session décident qui peut s'abonner.

Il n'y a aucun modèle de permissions à configurer dans Bird. Une souscription privée ou de présence est approuvée par un endpoint que vous écrivez, en utilisant la session dont vous disposez déjà, et signée avec un secret que seuls vos serveurs détiennent. Bird vérifie la signature ; vous décidez de la politique.

auth.ts

200 · signed

// Your endpoint. The only place the app secret lives.
app.post("/bird/auth", async (req, res) => {
  const { connection_id, channel_name } = req.body;
  const user = await session(req);

  if (!mayJoin(user, channel_name)) return res.sendStatus(403);

  // Signs <connection_id>:<channel_name>[:<member_data>] with the app
  // secret, and adds shared_secret on an encrypted channel.
  res.json(
    await bird.realtime.authorizeChannel({
      connectionId: connection_id,
      channelName: channel_name,
      memberData: JSON.stringify({
        member_id: user.id,
        member_info: { name: user.name },
      }),
    }),
  );
});

auth.ts

200 · signed

// Your endpoint. The only place the app secret lives.
app.post("/bird/auth", async (req, res) => {
  const { connection_id, channel_name } = req.body;
  const user = await session(req);

  if (!mayJoin(user, channel_name)) return res.sendStatus(403);

  // Signs <connection_id>:<channel_name>[:<member_data>] with the app
  // secret, and adds shared_secret on an encrypted channel.
  res.json(
    await bird.realtime.authorizeChannel({
      connectionId: connection_id,
      channelName: channel_name,
      memberData: JSON.stringify({
        member_id: user.id,
        member_info: { name: user.name },
      }),
    }),
  );
});

Une clé est publique. L'autre non.

Tout découle de cette séparation.

Chaque application sur l<hub>API Bird Realtime</hub> possède une clé et un secret. La clé est destinée à être intégrée dans le code client ; le secret authentifie les appels de votre serveur et signe les souscriptions, et il nest affiché qu'une seule fois, à la création. Quiconque le détient peut publier sur votre application et usurper une identité de présence : traitez-le comme un mot de passe de base de données. La rotation est additive plutôt que perturbatrice : créez une seconde clé, déployez-la, puis révoquez l'ancienne.

Quatre contrôles, quatre questions

Qui peut s'abonner, qui peut maintenir une connexion, qui peut lire une charge utile, et qui est encore autorisé.

01
Souscriptions signées.
Le client envoie son identifiant de connexion et le nom du canal à votre endpoint. Vous vérifiez l'appelant, refusez avec un 403 s'il ne peut pas rejoindre, ou renvoyez une signature HMAC-SHA256 sur l'identifiant de connexion et le nom du canal, préfixée par la clé de l'application. Comme l'identifiant de connexion fait partie de la signature, une approbation couvre une seule connexion et ne peut pas être rejouée sur une autre. Un canal de présence signe également l'identité du membre, et celle-ci doit être exactement la chaîne que vous renvoyez : resérialiser le même objet peut réordonner les clés et invalider la signature.
02
Connexions autorisées.
La clé de l'application est publique, donc quiconque peut charger votre page peut ouvrir un socket avec. Activez les connexions autorisées et chaque nouvelle connexion dispose de 30 secondes pour prouver qu'un détenteur du secret s'est porté garant, via une souscription privée ou une authentification. Toute connexion qui ne le fait pas est fermée avec le code 4009, et les connexions non autorisées ne comptent jamais dans votre quota. S'abonner à un canal public ne prouve rien et n'autorise pas une connexion.
03
Chiffrement de bout en bout.
Un canal private-encrypted- est scellé par votre serveur avant que la requête ne quitte votre processus, avec une clé maître de 32 octets qui n'apparaît jamais dans une requête de l'API Realtime. Chaque canal dérive sa propre clé, donc autoriser un client sur un canal chiffré ne lui permet pas d'en lire un autre. Bird ne peut pas récupérer une clé perdue, et la rotation protège les charges utiles futures plutôt que passées.
04
Révoquer l'accès immédiatement.
Un utilisateur déconnecté, un mot de passe modifié, un compte banni : déconnectez le membre et chaque connexion associée à cette identité se ferme, sur tous les appareils. Les clients traitent cette fermeture comme définitive au lieu de réessayer, et vos propres endpoints cessent de signer pour eux, donc ils ne peuvent pas revenir.

Canaux chiffrés

Des charges utiles que Bird ne peut pas lire, sur une infrastructure que Bird exploite.

Lire le guide de chiffrement

Le SDK serveur détecte le préfixe du canal, dérive la clé de ce canal à partir de votre clé maître et scelle la charge utile localement. Le serveur edge transmet le texte chiffré et votre endpoint d'autorisation remet la clé dérivée uniquement aux clients qu'il approuve. Deux limites à prendre en compte dans la conception : les noms de canaux et d'événements circulent en clair, choisissez donc des noms qui ne révèlent pas ce que vous protégez, et le chiffrement ne peut pas être combiné avec la présence ou les événements client. La mise en cache est possible : un canal private-encrypted-cache- stocke son événement en cache sous forme scellée.

encrypted.ts

sealed locally

const bird = new BirdClient({
  apiKey: process.env.BIRD_API_KEY!,
  realtime: {
    key: process.env.BIRD_REALTIME_KEY,
    secret: process.env.BIRD_REALTIME_SECRET,
    // 32 random bytes, yours alone. Never sent to Bird.
    encryptionMasterKey: process.env.BIRD_REALTIME_MASTER_KEY,
  },
});

// Sealed in your process. The edge forwards ciphertext.
await bird.realtime.publish(APP_ID, {
  event: "order.updated",
  channels: ["private-encrypted-orders"],
  data: { order_id: "ord_123", status: "shipped" },
});

Ce que l'autorisation ne fait pas.

Exiger des connexions autorisées contrôle qui peut maintenir un socket ouvert. Cela ne change pas qui peut lire un canal : un canal public reste lisible par toute connexion autorisée, donc les événements qui appartiennent à un client doivent être sur un canal privé dont le nom est vérifié par votre endpoint. Et parce que vos endpoints font autorité, un endpoint permissif distribue l'accès aussi librement qu'une clé compromise le ferait. La même rigueur s'applique aux événements client, que le serveur edge ne valide pas : utilisez-les pour des signaux, et faites transiter tout ce qui fait autorité par votre serveur.

Où résident les données.

Une application choisit sa région à la création et la conserve à vie, vous choisissez donc celle la plus proche de vos utilisateurs, et la région d'une application peut différer de la région d'origine de votre espace de travail. Les applications sont aussi la frontière d'isolation : deux applications ne voient jamais les canaux l'une de l'autre, c'est ce qui fait d'une application par environnement la bonne approche pour garder le trafic de staging hors de la production.

Approfondissez dans la documentation.

Autoriser les canaux décrit le contrat de requête et de réponse ainsi que la chaîne exacte à signer. Exiger des connexions autorisées couvre la fenêtre de 30 secondes et le code 4009, les canaux chiffrés couvrent la génération et la rotation des clés, et la terminaison des connexions membres décrit le flux d'authentification et de déconnexion.