Seguridad en tiempo real

Las reglas de su sesión deciden quién puede suscribirse.

No hay un modelo de permisos que configurar en Bird. Una suscripción privada o de presencia la aprueba un endpoint que usted escribe, usando la sesión que ya tiene, y firmada con un secreto que solo sus servidores poseen. Bird verifica la firma; usted decide la política.

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 clave es pública. La otra no.

Todo se deriva de esa separación.

Cada aplicación en la Bird Realtime API tiene una clave y un secreto. La clave está pensada para incluirse en el código del cliente; el secreto autentica las llamadas de su servidor y firma las suscripciones, y se muestra una sola vez, al crearse. Cualquiera que lo posea puede publicar en su aplicación y falsificar una identidad de presencia, así que trátelo como una contraseña de base de datos. La rotación es aditiva, no disruptiva: cree una segunda clave, despliéguela y luego revoque la anterior.

Cuatro controles, cuatro preguntas

Quién puede suscribirse, quién puede mantener una conexión, quién puede leer un payload y quién sigue autorizado.

01
Suscripciones firmadas.
El cliente envía su id de conexión y el nombre del canal a su endpoint. Usted verifica al solicitante, rechaza con un 403 si no puede unirse, o devuelve una firma HMAC-SHA256 sobre el id de conexión y el nombre del canal, precedida por la clave de la aplicación. Dado que el id de conexión está en la firma, una aprobación cubre una sola conexión y no puede reutilizarse en otra. Un canal de presencia también firma la identidad del miembro, y debe ser exactamente la cadena que usted devuelve: re-serializar el mismo objeto puede reordenar las claves e invalidar la firma.
02
Conexiones autorizadas.
La clave de la aplicación es pública, así que cualquiera que pueda cargar su página puede abrir un socket con ella. Active las conexiones autorizadas y cada nueva conexión tendrá 30 segundos para demostrar que algo que posee el secreto la avaló, mediante una suscripción privada o un inicio de sesión. Cualquier conexión que no lo haga se cierra con el código 4009, y las conexiones no autorizadas nunca cuentan contra su cuota. Suscribirse a un canal público no demuestra nada y no autoriza una conexión.
03
Cifrado de extremo a extremo.
Un canal private-encrypted- es sellado por su servidor antes de que la solicitud salga de su proceso, con una clave maestra de 32 bytes que nunca aparece en una solicitud de Realtime API. Cada canal deriva su propia clave, de modo que autorizar a un cliente en un canal cifrado no le permite leer otro. Bird no puede recuperar una clave perdida, y la rotación protege los payloads futuros, no los pasados.
04
Revocar el acceso de inmediato.
Un usuario que cerró sesión, una contraseña cambiada, una cuenta suspendida: desconecte al miembro y cada conexión asociada a esa identidad se cierra, en todos los dispositivos. Los clientes tratan ese cierre como definitivo en lugar de reintentar, y sus propios endpoints dejan de firmar por ellos, así que no pueden volver.

Canales cifrados

Payloads que Bird no puede leer, en infraestructura que Bird gestiona.

Lea la guía de cifrado

El SDK del servidor detecta el prefijo del canal, deriva la clave de ese canal a partir de su clave maestra y sella el payload localmente. El edge reenvía el texto cifrado y su endpoint de autorización entrega la clave derivada solo a los clientes que aprueba. Dos límites a considerar en el diseño: los nombres de canal y evento viajan en texto claro, así que elija nombres que no revelen lo que está protegiendo, y el cifrado no se puede combinar con presencia ni con eventos del cliente. El almacenamiento en caché es posible: un canal private-encrypted-cache- almacena su evento en caché sellado.

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

Lo que la autorización no hace.

Requerir conexiones autorizadas controla quién puede mantener un socket abierto. No cambia quién puede leer un canal: un canal público sigue siendo legible por cada conexión autorizada, así que los eventos que pertenecen a un cliente deben ir en un canal privado cuyo nombre su endpoint verifica. Y dado que sus endpoints son la autoridad, un endpoint permisivo otorga acceso con la misma libertad que una clave filtrada. La misma honestidad aplica a los eventos del cliente, que el edge no valida: úselos para señales y enrute cualquier dato autoritativo a través de su servidor.

Dónde residen los datos.

Una aplicación elige su región al crearla y la conserva de por vida, así que elija la más cercana a sus usuarios; la región de una aplicación puede diferir de la región principal de su workspace. Las aplicaciones también son el límite de aislamiento: dos aplicaciones nunca ven los canales de la otra, lo que hace que una aplicación por entorno sea la forma correcta de mantener el tráfico de staging fuera de producción.

Profundice en la documentación.

Autorización de canales contiene el contrato de solicitud y respuesta y la cadena exacta a firmar. Requerir conexiones autorizadas cubre la ventana de 30 segundos y el código 4009, canales cifrados cubre la generación y rotación de claves, y finalizar conexiones de miembros es el flujo de inicio de sesión y desconexión.