Realtime-Sicherheit
Ihre Session-Regeln bestimmen, wer abonnieren darf.
In Bird gibt es kein Berechtigungsmodell zu konfigurieren. Eine private oder Presence-Subscription wird von einem Endpoint genehmigt, den Sie selbst schreiben – mit der Session, die Sie bereits haben, und signiert mit einem Secret, das nur Ihre Server kennen. Bird verifiziert die Signatur; Sie bestimmen die Richtlinie.
// 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 },
}),
}),
);
});
Täglich vertraut von Teams, die erstklassige Software entwickeln
Weitere Kundenberichte lesenEin Schlüssel ist öffentlich. Der andere nicht.
Alles folgt aus dieser Trennung.
Jede App auf dem Bird Realtime API hat einen Key und ein Secret. Der Key ist dafür gedacht, im Client-Code ausgeliefert zu werden; das Secret authentifiziert die Aufrufe Ihres Servers und signiert Subscriptions – es wird einmalig bei der Erstellung angezeigt. Jeder, der es besitzt, kann in Ihrer App veröffentlichen und eine Presence-Identität fälschen – behandeln Sie es wie ein Datenbankpasswort. Rotation ist additiv statt disruptiv: Erstellen Sie einen zweiten Key, deployen Sie ihn und widerrufen Sie dann den alten.
Vier Kontrollen, vier Fragen
Wer darf abonnieren, wer darf eine Verbindung halten, wer kann einen Payload lesen, und wer ist noch zugelassen.
- 01
Signierte Subscriptions.
Der Client sendet seine Connection-ID und den Channel-Namen an Ihren Endpoint. Sie prüfen den Aufrufer, lehnen mit einem 403 ab, wenn er nicht beitreten darf, oder geben eine HMAC-SHA256-Signatur über Connection-ID und Channel-Name zurück, mit dem App-Key als Präfix. Da die Connection-ID in der Signatur enthalten ist, gilt eine Freigabe für eine Verbindung und kann nicht auf eine andere übertragen werden. Ein Presence-Channel signiert auch die Member-Identität, und sie muss exakt der String sein, den Sie zurückgeben: Erneutes Serialisieren desselben Objekts kann die Schlüsselreihenfolge ändern und die Signatur ungültig machen.
- 02
Autorisierte Verbindungen.
Der App-Key ist öffentlich, sodass jeder, der Ihre Seite laden kann, damit einen Socket öffnen kann. Aktivieren Sie autorisierte Verbindungen, und jede neue Verbindung hat 30 Sekunden, um nachzuweisen, dass etwas mit dem Secret für sie bürgt – über eine private Subscription oder einen Sign-in. Alles andere wird mit Code 4009 geschlossen, und unautorisierte Verbindungen zählen nie gegen Ihr Kontingent. Das Abonnieren eines öffentlichen Channels beweist nichts und autorisiert keine Verbindung.
- 03
Ende-zu-Ende-Verschlüsselung.
Ein private-encrypted-Channel wird von Ihrem Server versiegelt, bevor die Anfrage Ihren Prozess verlässt – mit einem 32-Byte-Masterschlüssel, der nie in einer Realtime-API-Anfrage auftaucht. Jeder Channel leitet seinen eigenen Schlüssel ab, sodass die Autorisierung eines Clients für einen verschlüsselten Channel nicht den Zugriff auf einen anderen ermöglicht. Bird kann einen verlorenen Schlüssel nicht wiederherstellen, und Rotation schützt zukünftige Payloads, nicht vergangene.
- 04
Zugriff sofort widerrufen.
Ein abgemeldeter Nutzer, ein geändertes Passwort, ein gesperrtes Konto: Trennen Sie den Member, und jede Verbindung dieser Identität wird geschlossen, auf jedem Gerät. Die Clients behandeln das Schließen als endgültig statt erneut zu versuchen, und Ihre eigenen Endpoints signieren nicht mehr für sie – sie können nicht zurückkommen.
Verschlüsselte Channels
Payloads, die Bird nicht lesen kann, auf Infrastruktur, die Bird betreibt.
Das Server-SDK erkennt das Channel-Präfix, leitet den Schlüssel dieses Channels aus Ihrem Masterschlüssel ab und versiegelt den Payload lokal. Die Edge leitet Ciphertext weiter, und Ihr Autorisierungs-Endpoint gibt den abgeleiteten Schlüssel nur an Clients weiter, die er genehmigt. Zwei Einschränkungen im Design: Channel- und Event-Namen werden im Klartext übertragen – wählen Sie also Namen, die nicht verraten, was Sie schützen. Verschlüsselung kann nicht mit Presence oder Client Events kombiniert werden. Caching ist möglich: Ein private-encrypted-cache-Channel speichert sein gecachtes Event versiegelt.
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" },
});
Was Autorisierung nicht leistet.
Autorisierte Verbindungen zu verlangen steuert, wer einen Socket offen halten darf. Es ändert nicht, wer einen Channel lesen kann: Ein öffentlicher Channel bleibt für jede autorisierte Verbindung lesbar, sodass Events, die einem Kunden gehören, in einen privaten Channel gehören, dessen Namen Ihr Endpoint prüft. Und weil Ihre Endpoints die Autorität sind, vergibt ein zu freizügiger Endpoint Zugriff so bereitwillig wie ein geleakter Schlüssel. Dasselbe gilt für Client Events, die die Edge nicht validiert: Nutzen Sie sie für Signale und leiten Sie alles Autoritative über Ihren Server.
Wo die Daten liegen.
Eine App wählt ihre Region bei der Erstellung und behält sie dauerhaft, sodass Sie die Region wählen, die Ihren Nutzern am nächsten liegt – die Region einer App kann von der Heimatregion Ihres Workspace abweichen. Apps sind auch die Isolationsgrenze: Zwei Apps sehen nie die Channels der jeweils anderen. Deshalb ist eine App pro Umgebung der richtige Weg, Staging-Traffic aus der Produktion herauszuhalten.
Vertiefen Sie sich in die Dokumentation.
Channels autorisieren beschreibt den Request-/Response-Vertrag und den exakten zu signierenden String. Autorisierte Verbindungen verlangen behandelt das 30-Sekunden-Fenster und Code 4009, verschlüsselte Channels behandelt Schlüsselgenerierung und -rotation, und Member-Verbindungen beenden beschreibt den Sign-in- und Disconnect-Ablauf.
In die Praxis umsetzen.
Weiter mit der Dokumentation, Anleitungen und Beispielen zu diesem Thema. Die Ressourcen sind auf Englisch.
Der Rest von Realtime
Eine App, ein Schlüsselpaar. Entdecken Sie die weiteren Funktionen.
Den Schlüssel ausliefern. Das Secret behalten.
Signierte Subscriptions, autorisierte Verbindungen und verschlüsselte Channels sind Teil jeder Realtime-App – in jedem Tarif.