Modelo de seguridad

API keys

• Las keys usan el formato ak_live_… (alta entropía, con checksum) para que los secret scanners las reconozcan si alguna vez se filtran.
• Solo almacenamos un hash SHA-256 — la key se muestra en texto plano exactamente una vez, al emitirla.
• La rotación soporta una ventana de gracia: la key vieja sigue funcionando mientras despliegas la nueva. La revocación es instantánea y fail-closed.
• Tu key vive solo en tu backend. Si aparece en código de frontend, rótala de inmediato.

Tokens de sesión

• Efímeros (15 minutos) y limitados a un cliente con un set fijo de permisos.
• Se entregan al iframe vía postMessage con verificación estricta de origen — nunca en URLs, nunca en cookies. Sin dependencias de third-party cookies.
• Revocar la API key, suspender el partner o desvincular el cliente mata los tokens vivos: cada request re-verifica, fail-closed.

Aislamiento entre clientes

La regla que hace estructuralmente imposible el acceso cruzado: el workspace destino se elige solo al emitir el token — del lado del servidor, validado contra el mapeo de clientes de tu partner — y la API del widget lo lee solo del token firmado. Ningún input del navegador selecciona un workspace. Un cliente no puede ver los datos de otro, y un partner no puede ver los clientes de otro partner.

La frontera del iframe

• El modal corre en embed.auphere.com, un origen separado — el JavaScript de tu página no puede leerlo ni manipularlo, y él no puede tocar tu página.
• Solo los orígenes registrados en tu API key pueden embeber el widget; el resto se bloquea a nivel de CSP (frame-ancestors).
• Las credenciales de WhatsApp obtenidas durante el signup se guardan cifradas y nunca transitan por tu frontend.

Controles de abuso

• Límites de tasa por partner en la emisión de tokens y en las APIs del widget.
• Topes de audiencia por envío en los broadcasts.
• Un audit log append-only de la actividad del partner.