在基于浏览器的应用

Question

我们正在构建一个处理用户加入应用程序的Web应用程序，并且正在考虑围绕客户端 - 服务器与SPA类型应用程序的一些选项。从用户体验的角度来看，我们的偏好可能完全是客户端SPA，但我有API安全问题。

由于我们不是身份验证用户（他们还不是用户），因此OAuth标准意味着我们需要使用“客户端凭据”授权类型。如果服务器处理这个问题，这不是问题，但在SPA中，凭据本身位于浏览器中供任何人查看，我们的API网关无法区分浏览器中的SPA与脚本之间的合法API调用写了收获的细节。

服务器端应用程序可以隐藏客户端凭据，并且至少确保a）API调用需要活动会话（使用cookie），以及b）我们可以限制某些API调用的数量每个会话只有一个。服务器可以使用自己的私有凭证调用我们的API网关，并进行了一些检查。

另一方面，在浏览器中运行单页面应用程序关于我能想到的唯一控件是在API网关中对API调用进行速率限制，但我怀疑这会实现很少。

随机思考我的一个想法是使用“隐式”OAuth授权类型，就像它是用户身份验证过程一样。当我们重定向到“登录”页面时，它实际上不需要用户交互，而是抓取设备的指纹（例如IP地址，浏览器，语言，屏幕分辨率），然后重定向回“成功”登录。然后，客户端具有唯一的访问令牌，我们跟踪了有关最终用户的一些详细信息，以便进行审计，并进行潜在的风险评估。这需要我们的Auth服务器的定制 - 当然可能但不一定理想。

是否有人采取其他方法来保护SPA网络应用中成功且安全的API调用？或者我是否通过应用基于浏览器的控件的应用服务器停止路由API调用？

欣赏任何想法或见解......

Answer 1

如果有人关心 - 并从观点数量来判断，可能不是！ :) - 我们采取的方法如下：

尽可能：

• 我们将有一个某种类型的应用服务器负责为页面动态生成JavaScript ，而不是从Web服务器提供静态内容
• 应用服务器将内部交换具有时间限制的访问令牌的客户端凭据，并将该访问令牌嵌入发送到浏览器的JavaScript中
• 如果黑客抓取访问令牌，那么他们就可以使用它，但只能在有限的时间窗口内使用（尽管他们总是可以通过再次请求网站返回并获得新的，但这与发布到网站没有什么不同形式））
• 在API网关级别应用速率限制，以匹配来自合法网站的预期API流量，因此如果有人编写某些内容来使用API​​和收集的令牌，那么他们不仅不会长时间使用要做到这一点，他们将无法通过无限制的电话锤击网站

无法将访问令牌动态插入JavaScript：

• 我们要么牺牲SPA而要做客户端服务器，要么我们只是将客户端凭据放在JavaScript中并承认它们可能会受到损害
• 我们再次在API网关上应用速率限制
• 凭据仅被视为跟踪和速率限制目的的指示

我决定反对棘手的重定向指纹选项，因为它太复杂了我们的需求，但是如果上述方法不起作用，其他人可能会想要追求。

希望有人觉得这很有用。