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

Question

我有一个公开公共API的网站。我想使用OAuth 2保护此公共API。为了最大程度地减少要维护的代码路径，我想重构我的网站以使用OAuth 2保护的公共API端点。

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

1. 我的客户必须有效地涵盖所有范围，因为网站涵盖了所有可能的操作。 API只是一个子集（尽管我希望对此进行更改）。第二个问题是令牌的安全性和缓存。该令牌可以使用一个小时。
2. 如果用户刷新页面，我是否要获取另一个令牌？如果我存储它在本地cookie或localStorage中，是否存在安全性某种脆弱？

假设我为我的UI的每个页面注册了一个不同的OAuth客户端。这样可以使＃2中的令牌如果被盗，其作用域将受到限制，但会变得非常乏味。

[替代方法是不使用我网站上的公共API，并且保护取决于CORS。恶意攻击者无法访问这些端点，因为它们仅被允许来自用户所在的域（以及类似nonnce的事物）。

Answer 1

您想要的声音基于直接调用API的基于浏览器UI的模型，这无疑是最有吸引力的体系结构。

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

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

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

以上令牌存储是经过认证的OIDC Client Library的默认行为，并且被广泛使用。

存在跨站点脚本编写的风险，即浏览器选项卡中的恶意内容可以获取令牌并调用API-但无论如何，您都应对此加以保护。

[较早的解决方案，例如使用auth cookie，往往会面临自身（甚至更大）的风险，例如跨站点请求伪造，其中任何浏览器选项卡中的任何恶意内容均会将cookie发送到您的API。

评估是否使用令牌的HTML5存储不仅仅涉及技术机制，它还涉及在可用性和令牌可以做什么方面的可接受的折衷。我在UI token storage上的博客文章对此进行了深入探讨。

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