公共面向REST的身份验证机制

Question

我正在设计一项新服务,使"客户"能够为他们执行的特定搜索注册并支付每次使用费.将使用RESTFul和SOAP接口公开此服务.通常,Web服务将与客户的网站集成,然后暴露给"公共",任何人都可以使用客户的网站,并利用我的Web服务功能(客户将支付但完全控制调节)请求所以他们不会收取太多费用).

我想设计优化集成的服务,使其尽可能简单.Web服务API将发生变化,因此创建内部代理以在某些情况下向公众公开Web服务对客户来说太过贬低.因此,我认为这个问题是创建一个平衡身份验证,安全性和集成的Web服务.

理想

1. 不使用OAuth
2. 避免强迫客户创建内部代理,以重新公开我已经使用的相同Web服务API.
3. 安全(令牌用户名/传递任何和ssl)
4. 在客户网站中嵌入一个javascript库 - 这将是一个客户端Javascript库,使集成步骤更容易.
5. Javascript库需要足够安全,以便公众无法简单地获取凭据并自行重新使用它
6. 如果可能的话,不要太苛刻,因此如果Firefox 87出现(将在几分钟内发布)并决定fubar它,则不必重新构建Web服务.

这似乎需要一些3方式身份验证过程才能工作,即验证特定客户端(在公共场合),Web服务(客户)和Web服务.

有没有人实现类似的东西,他们是如何解决这种情况的？

我也理解在可以做什么和违反跨域安全性之间存在平衡,因此整个Web服务可能会被另一个仅返回JSONP数据的GET接口暴露.

/**附录**/

我已经发现了一个可以完成我正在照顾的Web服务.但是,我不完全了解实施细节.所以也许有人也可以详细说明我的想法.

我发现的Web服务似乎在服务端托管了Javascript.然后,客户将其网站与服务端集成,方法是将Javascript包含在脚本标记中,但提供密钥即可

不知何故,如果我将脚本添加到我的网站,它不起作用.所以,在某个地方,令牌必须注册到特定的客户域,而'client-lib.js'实际上是一个servlet或类似的东西,它可以某种方式检测到来自'public'的用户实际上来自'客户'域名.

我的想法是对的吗？是否有某种http标头可以这种方式使用？这样安全吗？

干杯

Answer 1

首先 - 让我为您提供我昨天回答的另一个 SO 问题的链接- 因为它为类似的问题集提供了相当广泛的答案。

我假设您将向进行搜索的网站的所有者收费，而不太关心进行搜索的个人用户是谁。如果这是不正确的，请澄清，我将相应地更新我的答案。

显然，在任何这种情况下，您需要做的首要事情就是确保您知道每个请求对应的是哪个客户端。而且 - 正如您所说，您还想确保保护自己免受跨站点攻击和窃取用户密钥的人的侵害。

您可能会考虑以下内容：

1. 在您这边创建一个私钥- 只有您的服务知道。
2. 每当新的消费者网站与您创建帐户时，请创建一个只有您和他们知道的新共享密钥。我建议通过使用您的私钥作为密码来创建此密钥，并加密某种标识符，以便您识别该特定用户。
3. 作为注册过程的一部分，让消费者站点告诉您他们将在哪个 URI 上使用您的脚本。

现在，你们进行跟踪和身份验证的方式变得相当简单。

您提到提供一个 JS 库，不需要每次 FF 更新时都更新。我建议使用 jQuery 或另一个类似支持的跨浏览器 JS 基础库构建该库 - 并让它包装您的 AJAX。

但是，当客户端站点请求您的脚本时，请让他们为您提供类似以下内容：

http://www.yourdomain.com/scripts/library.js?key={shared key}

在您这边，当您收到此请求时，请检查以下内容：

1. 当您使用您的私钥解密他们的共享密钥时，您不应该得到乱码。如果您这样做 - 这是因为他们的密钥已以某种方式更改 - 并且无效。这应该会导致错误。401: Unauthorized
2. 一旦您解密密钥并知道这是哪个客户端站点（因为这就是密钥包含的内容），请检查以确保请求来自客户端注册的同一 URI。现在，这可以保护您免遭某人窃取密钥并将其注入其他网站的情况。
3. 只要上面匹配，就让他们下载文件。

现在 - 当您提供 JS 文件时，您可以通过将密钥注入该文件的方式来实现 - 因此它可以访问它们的共享密钥。在每个 AJAX 请求中包含该密钥，以便您可以再次识别该请求来自哪个客户端。在 RESTful 环境中，实际上不应该存在会话 - 因此您需要对每个帖子进行这种级别的身份验证。我建议将其作为 cookie 包含在内。

在您的服务器端 - 只需在每个后续请求中重复检查其密钥 - 瞧 - 您已经为自己构建了一些相当严格的安全性，而没有太多开销。

也就是说，如果您预计会有大量流量，您可能希望在未来回到这一点并探索更深入的安全流程，因为滚动您自己的安全矩阵可能会留下意想不到的漏洞。然而，这是一个良好的开始，会让您起步。

如果您需要，请随时提出任何问题，我会尽力相应地更新我的答案。