所以，我相信我理解像 OAuth 这样的授权标准背后的逻辑。OAuth 令牌包含有关用户的信息（姓名、角色等），我可以使用这些信息来保护我的应用程序。
关于上一句的最后一部分，我有一个问题。假设我有一个包含 1000 篇文章的网络应用程序，我如何检查特定用户（基于他/她的 OAuth 令牌）是否有权访问某篇文章？我看到几个选项：
- 我将用户可以看到的所有文章 ID 存储在 OAuth 令牌中（例如 ID1、ID2、ID3 等）；
- 相反，我也可以存储哪些用户可以访问文章（例如文章 1 可以被用户 1、2、3 阅读）。这就像一个 ACL；
- 对于每篇文章，我存储哪些角色可以访问该文章（例如文章 1 可以按角色阅读：读者）。这就像 RBAC；
- 根本不要保护您的内容，就像Facebook 似乎所做的那样（尽管他们确实保护了它，但他们只是在为您提供资源的直接 URL 之前检查您的朋友列表）。
澄清一下：我不是在寻找解释您可以将声明放入令牌本身的答案，这样您就不必点击数据库来检索您的声明（无状态）。我正在寻找应用程序后端如何使用这些声明来决定是否授予对某个内容项的访问权限的方法。
- 选项 1 似乎是不好的做法，因为对于大型提供商而言，代币将变得无限大。
- 如果大型提供商使用选项 2 或 3，他们将有大量的数据库命中（检查该用户是否可以访问该文章），这对性能不利。这种性能提升是 Facebook 和 Twitter 使用无状态授权而不是有状态授权的原因之一。我会假设内容级别的这种性能损失是使用选项 2 或 3 的障碍。
- 那么，使用 4 是唯一可行的选择吗？
我看到的最后一个选项是使用选项 3，并结合大量缓存。由于内容权限不像用户权限那样短暂，所以这是我会选择的选项。但大型供应商（谷歌、Twitter、Dropbox 等）就是这样做的吗？它是如何实际实施的？
更新
有人告诉我关于Spring 的权限矩阵，你可以把它放在内存中，但我不确定这是否是要走的路。