ruby-on-rails - OAuth 消费者是否在每个请求上使用 OAuth 提供者验证不记名 token

Question

要了解有关 OAuth 的更多信息，我正在尝试编写 OAuth 2.0 提供者和使用者。
我有点使用 Doorkeeper Gem作为我的提供者的引用，但我想自己写。
我的问题是关于 Section 1.3 中的最后一个项目符号关于不记名 token 的规范。

(F) The resource server validates the access token, and if valid,serves the request.

在这种情况下， The resource server validates the access token意味着它:

根据访问 token 的本地存储副本及其到期时间检查访问 token

向提供程序服务器发出请求，该服务器返回有效/无效的响应？

完全做其他事情

Answer 1

规范没有回答这个问题，因为它是一个对协议(protocol)工作没有影响的实现细节。尽管如此，这是一个可能对安全产生影响的好问题。
首先，您必须意识到，在某些实现中，资源服务器和授权服务器只是一个实体的两个角色。
正如 OAuth 2.0 规范 ( RFC 6749 ) 所说:

The interaction between the authorization server and resource serveris beyond the scope of this specification. The authorization servermay be the same server as the resource server or a separate entity.

它们可能都出现在一个网站中。也许它们是两个不同的网站，但它们都连接到同一个数据库。然后资源服务器可以在数据库中查找 token ，就像授权服务器一样。
如果资源服务器无法读取授权服务器的数据库，则它必须与授权服务器对话(即使可以，最好不要直接读取数据库)。
您如何准确地建立和保护该通信取决于您，但 HTTPS REST 请求很有意义。许多实现有不同的机制。例如，参见 OAuth-2.0 resource servers token validation in distributed environment .
显然，当访问 token 第一次提交给资源服务器时，资源服务器并不知道，必须访问授权服务器来检查有效性。现在有趣的问题是:资源服务器可以缓存这个响应，还是必须对每个请求都进行调用？
这是由资源服务器做出的设计决定，它可能受到许多不同因素的影响。例如:

如果授权服务器响应非常快，则资源服务器可能不需要缓存响应。事实上，设计不当的缓存可能比不缓存要慢。

需要设计和实现具有良好缓存策略的缓存可能会阻碍在资源服务器中实现良好的缓存。

根据资源服务器的性质和规模，为缓存分配 RAM 或磁盘存储的成本可能无法在资源服务器中实现良好的缓存。当访问 token 的数量非常多并且需要大量存储才能获得合理的缓存命中率时，尤其如此。

资源服务器是否准备好接受访问 token ，即使它已在授权服务器中被撤销？

最后一点值得进一步解释。授权服务器通常有多种机制来撤销 token 。如果资源所有者通过 UI 撤销授权，则授权服务器必须使通过该授权获得的所有 token (访问 token 和刷新 token )无效。资源服务器还可以实现 token 撤销端点(通常用于使用隐式授权的公共(public)客户端中的“注销”机制)。
资源服务器是否准备好承担接受 token 的风险，即使它已被撤销？如果是这样，持续多长时间？如果是，那么它可以缓存 token ，否则不能。乍一看，您当然会说资源服务器不应该使用缓存的 token 验证响应。但在某些情况下，性能优势可能会超过风险。显然，这还取决于资源服务器存储的资源的性质，以及与之相关的实际风险。
同样，这是我们无法为您做出的设计决定。从安全角度来看，您不应在资源服务器中缓存验证响应。