要了解有关 OAuth 的更多信息，我正在尝试编写 OAuth 2.0 提供者和消费者。
我有点使用Doorkeeper Gem 作为我的提供者的参考，但我想自己写。
我的问题是关于不记名令牌规范中Section 1.3 中的最后一个项目符号。
(F) 资源服务器验证访问令牌，如果有效， 处理请求。
在这种情况下，The resource server validates the access token 是否意味着：
【问题讨论】：
标签： ruby-on-rails oauth-2.0 authorization
规范没有回答这个问题，因为它是一个对协议的工作没有影响的实现细节。不过，这是一个可以影响安全性的好问题。
首先，你必须意识到，在某些实现中，资源服务器和授权服务器只是一个单一实体的两个角色。
正如 OAuth 2.0 规范 (RFC 6749) 所说：
授权服务器和资源服务器的交互 超出了本规范的范围。授权服务器 可以是与资源服务器相同的服务器，也可以是单独的实体。
它们可能都出现在一个网站中。也许它们是两个不同的网站，但它们都连接到同一个数据库。然后资源服务器可以像授权服务器一样在数据库中查找令牌。
如果资源服务器无法读取授权服务器的数据库，则它必须与授权服务器通信（即使可以，最好不要直接读取数据库）。
具体如何建立和保护通信取决于您，但 HTTPS REST 请求很有意义。许多实现具有不同的机制。例如，请参阅OAuth-2.0 resource servers token validation in distributed environment。
显然，当访问令牌第一次被提交给资源服务器时，资源服务器并不知道它，并且必须访问授权服务器以检查其有效性。现在有趣的问题是：资源服务器是否可以缓存这个响应，还是必须对每个请求进行调用？
这是由资源服务器做出的设计决定，它可能受到许多不同因素的影响。例如：
最后一点值得进一步解释。授权服务器通常有几种机制来撤销令牌。如果资源所有者通过 UI 撤销授权，授权服务器必须使通过该授权获得的所有令牌（访问令牌和刷新令牌）无效。资源服务器还可以实现令牌撤销端点（通常用于使用隐式授权的公共客户端中的“注销”机制）。
资源服务器是否准备好承担接受令牌的风险，即使它已被撤销？如果是这样，持续多长时间？如果是，那么它可以缓存令牌，否则它不能。乍一看，您当然会说资源服务器不应该使用缓存的令牌验证响应。但在某些情况下，可能存在超过风险的性能优势。这显然还取决于资源服务器存储的资源的性质，以及与之相关的真正风险。
同样，这是我们无法为您做出的设计决定。从安全角度来看，您不应在资源服务器中缓存验证响应。
【讨论】：