Cómo mantenemos tus apps privadas y separadas

Cada solicitud pasa primero por el inicio de sesión

Todo el tráfico de apps en *.teamonly.app va a un único Worker de despacho antes que a cualquier otra cosa. Este identifica la organización y la app a partir del hostname, revisa que haya una sesión válida, y solo entonces envía la solicitud a la app. Sin sesión, el visitante recibe la pantalla de inicio de sesión. El código del cliente nunca corre para él.

Hay tres formas de iniciar sesión: OpenID Connect de Google, OpenID Connect de Microsoft (Entra ID) o un código de un solo uso enviado a una dirección de correo de la empresa. Con Google y Microsoft, el token de ID se verifica en nuestro servidor, incluidos la firma, la audiencia, el vencimiento y el dominio del correo. El valor hd de Google se revisa en el token verificado, no se toma como cierto desde la solicitud. Con Microsoft, solo se aceptan cuentas de trabajo o de estudios, y el emisor del token tiene que coincidir con su propio tenant.

Códigos por correo

En lugar de Google o Microsoft, un compañero puede pedir un código de 6 dígitos en su dirección de trabajo. Así usan TeamOnly, sin configurar nada, las empresas cuyo correo no está en Google Workspace ni en Microsoft 365. El código demuestra que controla un buzón en uno de los dominios de tu empresa, lo mismo que demuestra un inicio de sesión con Google o Microsoft. Funciona con cualquier proveedor de correo. Las direcciones personales como Gmail u Outlook.com se rechazan en las apps de empresa.

• Un código vence a los 10 minutos.
• Con cinco intentos fallidos el código deja de funcionar. La persona tiene que pedir uno nuevo.
• Un código solo funciona en el navegador que lo pidió. Un código leído por encima del hombro de alguien, o reenviado, no sirve en otro navegador.
• Las solicitudes tienen un límite por dirección de correo y por dirección IP, para que nadie pueda usar el formulario para inundar una bandeja de entrada.
• El formulario está protegido por Cloudflare Turnstile, que revisa que quien pide sea una persona y no un script.
• El formulario da la misma respuesta tanto si una dirección puede iniciar sesión como si no, así que no revela quién tiene acceso.
• Los códigos se envían desde signin@teamonly.app, con SPF, DKIM y DMARC configurados para que los proveedores de correo puedan comprobar que de verdad vienen de nosotros.
• Los códigos se guardan solo como hash, y el acceso se revisa de nuevo cuando se ingresa el código, por si cambió mientras tanto.

Una identidad en la que tu app puede confiar

El Worker de despacho quita cualquier encabezado de identidad de la solicitud entrante y luego fija él mismo el correo y el nombre verificados, junto con los roles de esa persona en esa app. El SDK se los entrega a tu app como ctx.user.

incoming request to expenses.acme.teamonly.app✖x-teamonly-user: ceo@acme.com    removed, not from us✔x-teamonly-user: dana@acme.com   added from verified sign-in

Base de datos y almacenamiento de archivos separados por app

Cada app recibe su propia base de datos D1, creada en la primera publicación, y su propio prefijo de almacenamiento R2 para archivos. Esos son los únicos bindings de datos conectados a la app. Las apps corren como scripts separados en un dispatch namespace de Workers for Platforms y no pueden llegar a los bindings de otras.

Lo probamos a propósito: una app que intenta leer los datos, las cookies o los secretos de otra. Esas pruebas se hicieron contra la plataforma en producción, y las repetimos cada vez que cambian las partes que mantienen separadas las apps.

Secretos guardados fuera de tu código

Los secretos se configuran con npx teamonly secrets set y se guardan como secretos de Worker cifrados, conectados a esa única app. No están en tu repositorio, ni en el paquete, ni son visibles para otras apps. El archivo de skill le dice a tu IA que nunca ponga claves en el código.

Cookies limitadas a la dirección de una app

Las cookies de sesión se fijan para el hostname exacto de la app, como expenses.acme.teamonly.app, con Secure, HttpOnly y SameSite. Nunca se fijan en teamonly.app ni en el subdominio de la organización, así que una app no puede leer la sesión de otra.

teamonly.app todavía no está en la Public Suffix List, así que los navegadores cuentan cada dirección de app como parte de un mismo sitio cuando deciden qué es same-site. Por eso cada cookie de sesión está fijada a la dirección exacta de su app. Esta página lo va a decir si eso cambia.

El código de los clientes se trata como no confiable

Suponemos que cualquier app puede tener errores o código malicioso, porque parte la escribió una IA y cualquiera se puede equivocar. Por eso la autenticación vive fuera de la app, cada app recibe solo sus propios recursos, y nada que envíe una app puede cambiar quién inició sesión. También por eso una app solo puede enviar correos a personas de tu empresa, hasta 100 destinatarios por hora y 500 al día.

Dónde corre

Todo corre en Cloudflare: Workers y Workers for Platforms para el código, D1 para las bases de datos, R2 para los archivos y KV para las sesiones. No tenemos servidores propios. Elegir la región de datos está incluido en el plan Business, y lo configuramos contigo cuando te unes.

Lo que configuramos contigo, y lo que nunca hacemos

En el plan Business configuramos Okta u otro proveedor de SSO con tu equipo de TI. Los registros de auditoría y tu región de datos se configuran contigo de la misma forma. Están incluidos en el plan, no son interruptores que activas tú.

• Configurado contigo
  Okta, OneLogin y otros SSO (plan Business)
• Configurado contigo
  Registros de auditoría (plan Business)
• Configurado contigo
  Región de datos a elegir (plan Business)
• Nunca
  Apps públicas, sin autenticación

Hoy no tenemos certificación SOC 2 ni ISO.

Reportar un problema de seguridad

Escribe a hello@teamonly.dev con “Security” en el asunto. Una persona lee cada mensaje, y te respondemos para confirmar que lo recibimos. Por favor danos una oportunidad razonable de corregir el problema antes de hacerlo público.