Sicurezza realtime

Le regole della vostra sessione decidono chi può sottoscrivere.

Inizia ora Leggi la guida all'autorizzazione

Non c'è alcun modello di permessi da configurare in Bird. Una sottoscrizione privata o di presenza viene approvata da un endpoint che scrivete voi, usando la sessione che già avete, e firmata con un segreto che solo i vostri server possiedono. Bird verifica la firma; voi decidete la policy.

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 },
      }),
    }),
  );
});

Una chiave è pubblica. L'altra no.

Tutto deriva da questa separazione.

Ogni app sulla Bird Realtime API ha una chiave e un segreto. La chiave è pensata per essere inclusa nel codice client; il segreto autentica le chiamate del vostro server e firma le sottoscrizioni, e viene mostrato una sola volta, alla creazione. Chiunque lo possieda può pubblicare sulla vostra app e falsificare un'identità di presenza, quindi trattatelo come una password del database. La rotazione è additiva, non distruttiva: create una seconda chiave, distribuitela, poi revocate quella vecchia.

Quattro controlli, quattro domande

Chi può sottoscrivere, chi può mantenere una connessione, chi può leggere un payload e chi è ancora autorizzato.

01
Sottoscrizioni firmate.
Il client invia l'id di connessione e il nome del canale al vostro endpoint. Voi verificate il chiamante, rifiutate con un 403 se non può partecipare, oppure restituite una firma HMAC-SHA256 su id di connessione e nome del canale, prefissata con la chiave dell'app. Poiché l'id di connessione è nella firma, un'approvazione copre una sola connessione e non può essere riprodotta su un'altra. Un canale di presenza firma anche l'identità del membro, che deve essere esattamente la stringa che restituite: ri-serializzare lo stesso oggetto può riordinare le chiavi e invalidare la firma.
02
Connessioni autorizzate.
La chiave dell'app è pubblica, quindi chiunque possa caricare la vostra pagina può aprire un socket con essa. Attivate le connessioni autorizzate e ogni nuova connessione ha 30 secondi per dimostrare che qualcosa in possesso del segreto l'ha garantita, tramite una sottoscrizione privata o un accesso. Qualsiasi connessione che non lo fa viene chiusa con il codice 4009, e le connessioni non autorizzate non contano mai nella vostra quota. Sottoscrivere un canale pubblico non dimostra nulla e non autorizza una connessione.
03
Crittografia end-to-end.
Un canale private-encrypted- viene sigillato dal vostro server prima che la richiesta lasci il vostro processo, con una chiave master a 32 byte che non compare mai in una richiesta alla Realtime API. Ogni canale deriva la propria chiave, quindi autorizzare un client per un canale crittografato non gli consente di leggerne un altro. Bird non può recuperare una chiave persa, e la rotazione protegge i payload futuri, non quelli passati.
04
Revoca immediata dell'accesso.
Un utente disconnesso, una password cambiata, un account bannato: disconnettete il membro e ogni connessione associata a quell'identità si chiude, su ogni dispositivo. I client trattano quella chiusura come definitiva senza riprovare, e i vostri endpoint smettono di firmare per loro, quindi non possono tornare.

Canali crittografati

Payload che Bird non può leggere, su un'infrastruttura gestita da Bird.

Leggi la guida alla crittografia

L'SDK server riconosce il prefisso del canale, deriva la chiave di quel canale dalla vostra chiave master e sigilla il payload localmente. L'edge inoltra il testo cifrato e il vostro endpoint di autorizzazione consegna la chiave derivata solo ai client che approva. Due limiti da tenere in considerazione: i nomi dei canali e degli eventi viaggiano in chiaro, quindi scegliete nomi che non rivelino ciò che state proteggendo, e la crittografia non può essere combinata con la presenza o con gli eventi client. La cache è supportata: un canale private-encrypted-cache- memorizza il suo evento in cache sigillato.

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" },
});

Cosa l'autorizzazione non fa.

Richiedere connessioni autorizzate controlla chi può tenere aperto un socket. Non cambia chi può leggere un canale: un canale pubblico resta leggibile da ogni connessione autorizzata, quindi gli eventi che appartengono a un cliente vanno su un canale privato il cui nome viene verificato dal vostro endpoint. E poiché i vostri endpoint sono l'autorità, un endpoint permissivo concede accesso con la stessa libertà di una chiave trapelata. La stessa onestà si applica agli eventi client, che l'edge non valida: usateli per segnali e instradate tutto ciò che è autorevole attraverso il vostro server.

Dove risiedono i dati.

Un'app sceglie la propria regione al momento della creazione e la mantiene per sempre, così scegliete quella più vicina ai vostri utenti, e la regione di un'app può differire dalla regione principale del vostro workspace. Le app sono anche il confine di isolamento: due app non vedono mai i canali dell'altra, ed è per questo che un'app per ambiente è il modo giusto per tenere il traffico di staging fuori dalla produzione.

Approfondisci nella documentazione.

Autorizzazione dei canali contiene il contratto di richiesta e risposta e la stringa esatta da firmare. Richiedere connessioni autorizzate copre la finestra di 30 secondi e il codice 4009, canali crittografati copre la generazione e la rotazione delle chiavi, e terminare le connessioni dei membri descrive il flusso di accesso e disconnessione.