Fondo
Estoy diseñando un widget web para un nuevo SaaS para incrustarlo en un CMS protegido por contraseña. Esto permitiría al cliente agregar algo como lo siguiente a todas las páginas de su CMS para mostrar alguna información de mi sistema SaaS:
<script src="https://www.awesome-saas.com/widget.js?userToken=xyz"id="widget"/>
Cuando un usuario se registra en el sitio web de mi cliente, mi cliente llama a mi API para recuperar un UUID para el nuevo usuario en mi sistema SaaS. Este es el token del usuario. La identificación única utilizada en el CMS de mi cliente no se pasa en la llamada a la API. El cliente CMS almacena la asociación entre la identificación única del usuario y el token proporcionado por mi sistema. No se almacena información personal en mi sistema (no hay nombres, DoB, detalles de tarjetas de crédito, etc.) Este enfoque de generación de token garantiza el anonimato de los datos almacenados en mi sistema y garantiza el cumplimiento de la residencia de datos para mi plataforma.
El CMS proporciona el token del usuario a mi widget de javascript y el widget hace una solicitud a mi API que pasa el token del usuario para recuperar un fragmento JSON para representarlo en la página.
https://www.awesome-saas.com/getInfo?userToken=xyz
El fragmento JSON que se devuelve no contiene ninguna información personal en él.
Toda la comunicación entre el CMS, el navegador del usuario y mi API se realiza a través de SSL. No se comparte la sesión de usuario entre el CMS y mi sistema SaaS.
Problema
¿Cómo puedo asegurar las solicitudes a mi API que se originan en el widget javascript y hacer que sea más fácil para mi cliente integrar mi servicio con su CMS?
Algunas opciones que he considerado:
Opción 1
Pasar el token UUID a la API de mi SaaS es suficiente. Sería extremadamente difícil de adivinar e incluso si alguien lograra hacer eso, no sabrían con quién se relacionaron los datos recuperados.
Pros
- facilita la integración
- las respuestas a mi API se pueden almacenar fácilmente en caché
Contras
- podría ser una venta difícil para clientes, auditores o reguladores
- es la seguridad a través de la oscuridad que se siente mal
Vectores de ataque
- el historial del navegador comprometido revelaría el token del usuario
- adivinar la fuerza bruta podría tener suerte
Opción 2
Obtenga el CMS del cliente para cifrar todos los tokens generados y compartir su clave pública con nosotros. El token encriptado se pasa a mi API, lo descifro usando la clave pública del cliente.
Pros
- garantiza que el token se haya originado en el CMS del cliente en lugar de en un forzador brutal
- la fuerza bruta ahora tiene que probar y adivinar una versión encriptada de un número increíblemente difícil de adivinar
Contras
- no puedo guardar en caché las solicitudes de mi API porque el cifrado en el token debe verificarse cada vez que se
- más trabajo para que el cliente se integre conmigo, es decir, cambio de código
Vectores de ataque
- el historial del navegador comprometido revelaría el token de usuario cifrado