我正在研究通过 HTTP 公开的 API，这些 API 将被合作伙伴公司使用并部署到他们的众多客户中。
在某些情况下，客户端将基于浏览器。这是我的主要关注点，但我可能会在客户端是 Windows 应用程序的情况下应用相同的模式。我觉得当客户端是 Windows 应用程序而不是基于浏览器的应用程序时，在客户端上保护私钥的范围更大。因此，发生的通信是从合作伙伴应用程序呈现的浏览器页面到我们托管 API 的服务器。
底线是我们不能提示最终用户输入凭据，并且必须依赖将随每个请求传递的存储的密码/密钥/令牌。我担心的是我想阻止合作伙伴公司将此令牌烘焙到客户端代码中。以下是该场景的高级描述。
- 合作伙伴在我们这里建立一个帐户（手动过程），执行必要的开发工作以在他们的产品中使用 API，然后将其推广给他们的客户。
- 然后，客户运行产品并通过向导在我们这里建立帐户。此时我们可以提示他们输入用户名和密码，但以后对 API 的所有请求都不应提示实际的最终用户输入凭据。
- 然后，他们执行无数业务流程，在许多不同用户环境下的许多工作站上调用我们的 API。我们不关心个人用户信息。
出于这个问题的目的，我将跳过第 1 步并专注于第 2 步和第 3 步。
我目前正在努力保护这个 API，并提出了以下设计：
- HTTPS 无处不在（所有请求都使用 SSL/TLS）
- 所有 POST 请求都使用 CSRF 令牌
- 在第 2 步中，当客户创建帐户时，我们会向他们提供客户身份验证代码。合作伙伴应对其应用程序进行编码，以将此身份验证代码存储在服务器上。
- 在将来调用我们的 API 之前，它们会在我们的 javascript 库上调用一个 Init 函数并提供一个回调，例如“GetAuthToken”。
- 每次调用我们的 API 时，我们都会检查是否有 Auth Token（在服务器上），如果没有，我们会返回错误并调用回调。
- 实施回调时，合作伙伴应使用 HTTPS 调用其服务器以检索令牌。这个请求将受到他们的正常身份验证，因此假设如果用户在他们的系统中经过身份验证，那么他们可以检索 Auth Token。
- 我们收到 Auth Token，调用我们的服务器来验证它，然后设置一个包含该令牌的 HTTPOnly cookie。
- 当 cookie 过期时，我们再次调用 GetAuthToken 回调。
- 使用 postMessage 管理跨域问题
- 我们可以使 Auth Token 可撤销
我们在这里有一种联合安全形式，如果用户通过合作伙伴的身份验证，那么我们假设他们可以访问我们的 API。我能想到的避免将私钥/身份验证令牌烘焙到客户端代码中的唯一方法是这种回调机制。
我是不是太复杂了？还有其他更简单的方法吗？我意识到，如果任何一个站点都对 XSS 开放或受到恶意软件的破坏，所有的赌注都没有了，但至少通过不将私钥呈现为 javascript 或标记，用户无法右键单击查看源代码并告诉所有人私钥。
编辑：找到这个问题。最佳答案描述了与我所描述的内容类似的内容，尽管提到了我不想强迫合作伙伴实施的 WIF（他们甚至可能没有运行 Windows）。不过，仍然希望对我的方法提供反馈...