在我的网站上使用我自己的公共 API

Question

我有一个公开公共 API 的网站。我想使用 OAuth 2 保护这个公共 API。为了尽量减少要维护的代码路径的数量，我想重构我的网站以使用受 OAuth 2 保护的公共 API 端点。

我打算这样做的方法是在我的服务器中注册一个 OAuth 2 客户端作为“我的网站”，然后让它获取一个短期令牌。我发现这种方法存在 2 个问题：

1. 我的客户必须有效地拥有每个范围，因为 网站包含所有可能的操作。 API 只是一个子集 这个（虽然我希望改变这一点）。第二个问题是 令牌的安全性和缓存。该令牌将存在一个小时。
2. 如果用户刷新页面，我是否要获取另一个令牌？如果我存储 它在本地的 cookie 或 localStorage 中，是否有安全性 某种脆弱？

假设我为 UI 的每个页面注册了一个不同的 OAuth 客户端。这将使得 #2 中的令牌在被盗时范围有限，但它变得非常乏味。

另一种方法是不在我的网站上使用公共 API，保护依赖于 CORS。恶意攻击者无法访问这些端点，因为它们只被允许来自用户所在的域（以及诸如 nonce 之类的东西）。

Answer 1

听起来你想要一个基于浏览器 UI 直接调用 API 的模型，这在架构上无疑是最具吸引力的。

这可能是单页应用架构的第一步，它倾向于提供最简单、最干净的解决方案。

有关最新标准，请参阅 Open Id Connect for browser apps。

• 在 SPA 中，UI 是无 cookie 的，通常将短期访问令牌存储在 HTML5 会话存储中，这意味着用户可以刷新页面 ok
• 确实，登录后会检索所有范围，但如果您保持范围简单并根据用户权限在 API 中进行授权，则可以缓解这种情况

上述令牌存储是认证OIDC Client Library的默认行为并被广泛使用。

存在跨站点脚本风险，您的浏览器选项卡中的恶意内容可以获取令牌并调用 API - 但无论如何您都应该防范这种情况。

使用 auth cookie 等较旧的解决方案往往具有其自身（和更大）的风险，例如跨站点请求伪造，任何浏览器选项卡中的任何恶意内容都可以将 cookie 发送到您的 API。

评估是否使用 HTML5 存储令牌不仅仅是技术机制 - 它是关于可用性和令牌可以做什么的可接受权衡。我在UI token storage 上的博文深入探讨了这一点。

如果有帮助，我的博客也有很多关于 SPA 的帖子和代码示例，以备不时之需。