Skip to main content
Las claves privadas de identidad y de firma de X Chat son la raíz de la identidad de mensajería cifrada de un usuario. Cualquiera que las posea puede desenvolver las claves de conversación entregadas a esa identidad y firmar como ese usuario para el chat. Trata el PIN / código de acceso de cifrado de la misma forma: recupera esas claves desde la copia de seguridad segura de claves. Esta página cubre reglas para cualquier tipo de app. Para la arquitectura de cliente recomendada, consulta Crear apps de UI con WASM.

​
Advertencia crítica para usuarios y desarrolladores de apps

Nunca pidas a los usuarios finales que compartan su PIN de cifrado o sus claves privadas con un servidor de terceros, un agente de soporte o una app “de ayuda”.El PIN desbloquea las claves raíz de identidad. Una parte que obtenga el PIN (o el blob de la clave privada) puede:
  • Descifrar las claves de conversación envueltas para esa identidad (y por tanto el historial de mensajes que pueda obtener como texto cifrado)
  • Seguir enviando y recibiendo como esa identidad criptográfica
  • Mantener esa capacidad incluso si el usuario después revoca OAuth para la app
Revocar OAuth detiene el acceso a la API para los tokens de esa app. No invalida las claves privadas que el usuario ya haya entregado. Prefiere arquitecturas donde el PIN solo se introduzca en criptografía en el dispositivo (WASM en el navegador o un cliente nativo usando el Chat XDK).

​
Texto de producto y de documentación que deberías mostrar

Si tu app solicita scopes de OAuth relacionados con DM (dm.read, dm.write y scopes relacionados), acompaña la pantalla de consentimiento OAuth con lenguaje claro en el producto:
  • Las claves de cifrado permanecen en el dispositivo del usuario cuando usas la ruta oficial del SDK cliente.
  • Los usuarios nunca deben teclear su PIN de X Chat en un sitio web que lo reenvíe a un backend.
  • Las integraciones legítimas usan el Chat XDK para que la recuperación con PIN y la criptografía se ejecuten localmente (para navegadores: WASM + copia de seguridad segura de claves).
  • Una app maliciosa que obtenga claves privadas puede exfiltrarlas; hoy no existe un “revocar esta clave” del lado del servidor para una clave raíz puramente en cliente: diseña de forma que los usuarios nunca necesiten entregarte claves raíz.

​
Qué cuenta como material de clave sensible

​
Elige la ruta de claves correcta según el tipo de app

Las apps cliente deberían preferir copia de seguridad segura de claves. Los servidores y bots suelen usar un blob de claves exportado. Detalles: Primeros pasos.

​
Reglas para claves privadas y PIN

​
Sí

  • Recoge el PIN solo en una UI cliente confiable que alimente al Chat XDK (unlock / setup) en el mismo dispositivo.
  • Mantén las claves en memoria solo mientras sea necesario. Tras el unlock, reutiliza la misma instancia de Chat durante la sesión; llama a lock() o free() en el logout.
  • Limpia los búferes del PIN cuando la API lo permita (por ejemplo, pasa un PIN como Uint8Array en JS para poder borrarlo tras unlock).
  • Almacena los blobs de claves de bots en un gestor de secretos (o HSM), cifra en reposo, restringe IAM y rota las credenciales del proceso con frecuencia.
  • Registra con cuidado en logs: nunca loguees PIN, claves privadas, blobs de claves, claves de conversación desenvueltas ni respuestas completas del backup seguro.
  • Defiende al cliente: XSS, extensiones maliciosas y dependencias comprometidas pueden leer las claves en memoria aunque la ruta de red esté limpia.

​
No

  • No envíes por correo, no captures ni pases por ticket un PIN o un blob de claves.
  • No pongas claves privadas ni PIN en query strings, analítica, trackers de errores o logs de CDN.
  • No envíes claves privadas de usuario final para “simplificar el backend”.
  • No confundas revocar OAuth con revocar claves. Desconectar una app no borra las claves que un usuario ya exportó o tecleó en un cliente hostil.
  • No almacenes la salida cruda de export_keys en localStorage ni en IndexedDB sin cifrar para apps de UI en producción.

​
Persistencia de sesión en el navegador

Las apps de navegador en producción deben optimizar la seguridad primero y luego la UX: Las demos internas a veces exportan claves a localStorage por comodidad. Está bien para prototipos desechables; no es un patrón de producción. Prefiere:
  1. createChat + unlock(pin) tras la recarga.
  2. Un contexto a nivel de módulo o framework que mantenga la instancia desbloqueada para la navegación en la SPA.
  3. lock() cuando la pestaña cierre sesión o el usuario bloquee la app.
Si añades un comportamiento extra de tipo “mantener desbloqueado en este dispositivo”, envuelve cualquier material persistido con Web Crypto (claves no exportables cuando sea posible), enlázalo a la sesión del usuario y aun así nunca subas ese material a tus servidores. La ruta de recuperación duradera sigue siendo el PIN del usuario y la copia de seguridad segura de claves, no una segunda copia de la clave raíz en tu infraestructura.

​
Scopes de OAuth vs claves de cifrado

Son planos de control separados:
  • OAuth autoriza llamadas a la API (listar conversaciones, publicar texto cifrado, obtener eventos).
  • Las claves privadas autorizan el acceso criptográfico al contenido de los mensajes.
Un producto completo debería:
  1. Solicitar solo los scopes de DM que necesite.
  2. Explicar por qué se requiere acceso a DM.
  3. Ejecutar la criptografía en el dispositivo para que OAuth nunca se convierta en un canal para recoger PIN.
  4. Dejar de guardar tokens en el logout; llama por separado a lock() sobre las claves del chat.

​
Lista de verificación operativa

  • Sin campos de PIN o clave privada en cuerpos de request al servidor para flujos de UI
  • Copia de seguridad segura de claves (setup / unlock) para clientes; gestor de secretos para blobs de bots
  • Instancia desbloqueada de Chat con alcance de una sola sesión de usuario; limpiada en el logout
  • Logs y APM depurados de secretos
  • Controles de CSP y XSS en cualquier página que pueda desbloquear el chat
  • Texto orientado al usuario: nunca compartas el PIN con terceros
  • Plan de incidentes: si un blob de bot se filtra, rota las claves / vuelve a registrar y considera el texto cifrado histórico como expuesto al poseedor de la clave antigua

​
Lecturas relacionadas