背景
我正在为新的 SaaS 设计一个 Web 小部件，用于嵌入受密码保护的 CMS。这将允许客户向其 CMS 中的所有页面添加类似以下内容，以显示来自我的 SaaS 系统的一些信息：
<script src="https://www.awesome-saas.com/widget.js?userToken=xyz" id="widget"/>
当用户在我的客户网站上注册时，我的客户调用我的 API 来检索我的 SaaS 系统中新用户的 UUID。这是用户令牌。我客户的 CMS 中使用的唯一 ID 未在 API 调用中传递。客户 CMS 存储用户的唯一 ID 和我的系统提供的令牌之间的关联。我的系统中没有存储任何个人信息（没有姓名、DoB、信用卡详细信息等）。这种令牌生成方法可确保存储在我的系统中的数据的匿名性，并确保我的平台的数据驻留合规性。
CMS 向我的 javascript 小部件提供用户令牌，并且该小部件向我的 API 发出请求，传递用户的令牌以检索 JSON 片段以在页面上呈现。
https://www.awesome-saas.com/getInfo?userToken=xyz
返回的 JSON 片段中不包含任何个人信息。
CMS、用户浏览器和我的 API 之间的所有通信都是通过 SSL 完成的。CMS 和我的 SaaS 系统之间没有共享用户会话。
问题
如何保护来自 javascript 小部件的对我的 API 的请求，同时让我的客户尽可能轻松地将我的服务与他们的 CMS 集成？
我考虑过的一些选项：
选项1
只需将 UUID 令牌传递给我的 SaaS 的 API 就足够了。这将是非常难以猜测的，即使有人设法做到了，他们也不知道检索到的数据与谁有关。
优点
- 使集成变得容易
- 对我的 API 的响应可以很容易地被缓存
缺点
- 对客户、审计师或监管机构来说可能是一个硬推销
- 感觉是错误的默默无闻的安全
攻击向量
- 受损的浏览器历史记录将显示用户令牌
- 蛮力猜测可能会很幸运
选项 2
让客户 CMS 加密所有生成的令牌并与我们共享他们的公钥。加密的令牌被传递给我的 API，我使用客户的公钥对其进行解密。
优点
- 确保令牌来自客户 CMS 而不是暴力破解者
- 暴力破解者现在必须尝试猜测一个非常难以猜测的数字的加密版本
缺点
- 无法缓存对我的 API 的请求，因为每次都需要检查令牌上的加密
- 客户需要做更多的工作来与我集成，即代码更改
攻击向量
- 受损的浏览器历史记录将显示加密的用户令牌