在基于浏览器的应用程序中使用 OAuth "client credentials"
Use of OAuth "client credentials" in browser-based app
我们正在构建一个处理用户加入应用程序的 Web 应用程序，并且正在考虑围绕客户端-服务器与 SPA 类型应用程序的一些选项。从用户体验的角度来看，我们的偏好可能是完全客户端 SPA，但我有 API 安全问题。
因为我们不是身份验证用户（他们还不是用户），OAuth 标准暗示我们需要使用 "client credentials" 授权类型。如果服务器处理这个问题，这不是问题，但在 SPA 中，凭据本身位于浏览器中供任何人查看，并且我们的 API 网关无法区分来自我们的合法 API 调用浏览器中的 SPA 与某人使用收集的详细信息编写的脚本。
服务器端应用程序 可以隐藏客户端凭据并至少确保 a) API 调用需要活动会话（使用 cookie），以及 b)我们可以将某些 API 调用的数量限制为每个会话一次。服务器可以调用我们的 API 网关，并使用它自己的私人凭据进行一些检查。
另一方面，对于 单页应用程序 运行 在浏览器中我能想到的唯一控件是对 [=35= 进行速率限制] 在 API 网关中调用，但我怀疑这将收效甚微。
随机想法： 我的一个想法是使用 "implicit" OAuth 授权类型，就好像它是用户身份验证过程一样。当我们重定向到 "login" 页面时，它实际上不需要用户交互，而是获取设备的指纹（例如 IP 地址、浏览器、语言、屏幕分辨率），然后作为 "successful" 登录重定向回来。然后客户端有一个唯一的访问令牌，我们已经跟踪了一些关于最终用户的详细信息以用于审计目的和潜在的风险评估。这需要定制我们的 Auth Server - 当然可能但不一定理想。
人们是否采取了任何其他方法来保护成功且安全的 SPA Web 应用程序中的 API 调用？或者我是否坚持通过应用基于浏览器的控件的应用程序服务器路由 API 调用？
感谢任何想法或见解...
如果有人关心 - 从观看次数来看，可能不会！ :) - 我们采用的方法如下：
尽可能：
- 我们将有某种应用程序服务器负责为页面动态生成JavaScript，而不是从网络服务器提供静态内容
- 应用程序服务器将在内部交换 具有时间限制的访问令牌的客户端凭据，并将该访问令牌嵌入到发送给浏览器
- 如果黑客获取了访问令牌，那么他们就可以使用它，但只能在有限的时间内使用它 window（尽管他们总是可以通过再次请求该站点返回并获得一个新的访问令牌，但事实并非如此不同于发布到网络表单）
- 在 API 网关 级别应用 速率限制以匹配来自合法站点的预期 API 流量，因此如果有人编写脚本以使用 API 和收获的令牌，那么他们不仅没有时间去做，他们将无法通过无限调用来锤击该站点
无法将访问令牌动态插入 JavaScript:
- 我们要么牺牲 SPA 并执行 client-server，要么我们只是将客户端凭据放在 JavaScript 中，并承认它们可能会被泄露
- 我们再次在 API 网关应用速率限制
- 凭据仅被视为用于跟踪和速率限制目的的指示
我决定不使用棘手的 redirection-with-fingerprinting 选项，因为它对我们的需求来说太复杂了，但如果上述方法不起作用，其他人可能会想尝试。
希望有人觉得这有用。
我们正在构建一个处理用户加入应用程序的 Web 应用程序，并且正在考虑围绕客户端-服务器与 SPA 类型应用程序的一些选项。从用户体验的角度来看，我们的偏好可能是完全客户端 SPA，但我有 API 安全问题。
因为我们不是身份验证用户（他们还不是用户），OAuth 标准暗示我们需要使用 "client credentials" 授权类型。如果服务器处理这个问题，这不是问题，但在 SPA 中，凭据本身位于浏览器中供任何人查看，并且我们的 API 网关无法区分来自我们的合法 API 调用浏览器中的 SPA 与某人使用收集的详细信息编写的脚本。
服务器端应用程序 可以隐藏客户端凭据并至少确保 a) API 调用需要活动会话（使用 cookie），以及 b)我们可以将某些 API 调用的数量限制为每个会话一次。服务器可以调用我们的 API 网关，并使用它自己的私人凭据进行一些检查。
另一方面，对于 单页应用程序 运行 在浏览器中我能想到的唯一控件是对 [=35= 进行速率限制] 在 API 网关中调用，但我怀疑这将收效甚微。
随机想法： 我的一个想法是使用 "implicit" OAuth 授权类型，就好像它是用户身份验证过程一样。当我们重定向到 "login" 页面时，它实际上不需要用户交互，而是获取设备的指纹（例如 IP 地址、浏览器、语言、屏幕分辨率），然后作为 "successful" 登录重定向回来。然后客户端有一个唯一的访问令牌，我们已经跟踪了一些关于最终用户的详细信息以用于审计目的和潜在的风险评估。这需要定制我们的 Auth Server - 当然可能但不一定理想。
人们是否采取了任何其他方法来保护成功且安全的 SPA Web 应用程序中的 API 调用？或者我是否坚持通过应用基于浏览器的控件的应用程序服务器路由 API 调用？
感谢任何想法或见解...
如果有人关心 - 从观看次数来看，可能不会！ :) - 我们采用的方法如下：
尽可能：
- 我们将有某种应用程序服务器负责为页面动态生成JavaScript，而不是从网络服务器提供静态内容
- 应用程序服务器将在内部交换 具有时间限制的访问令牌的客户端凭据，并将该访问令牌嵌入到发送给浏览器
- 如果黑客获取了访问令牌，那么他们就可以使用它，但只能在有限的时间内使用它 window（尽管他们总是可以通过再次请求该站点返回并获得一个新的访问令牌，但事实并非如此不同于发布到网络表单）
- 在 API 网关 级别应用 速率限制以匹配来自合法站点的预期 API 流量，因此如果有人编写脚本以使用 API 和收获的令牌，那么他们不仅没有时间去做，他们将无法通过无限调用来锤击该站点
无法将访问令牌动态插入 JavaScript:
- 我们要么牺牲 SPA 并执行 client-server，要么我们只是将客户端凭据放在 JavaScript 中，并承认它们可能会被泄露
- 我们再次在 API 网关应用速率限制
- 凭据仅被视为用于跟踪和速率限制目的的指示
我决定不使用棘手的 redirection-with-fingerprinting 选项，因为它对我们的需求来说太复杂了，但如果上述方法不起作用，其他人可能会想尝试。
希望有人觉得这有用。