为了了解更多关于OAuth的信息，我正在尝试编写一个OAuth 2.0提供程序和一个使用者。
我有点用Doorkeeper宝石作为我的提供者的参考，但我想写我自己的。
我的问题是关于规范第1.3节中关于持有者代币的最后一个项目。
（F） 资源服务器验证访问令牌，服务于请求。
在这种情况下，The resource server validates the access token是否意味着它：
- 将访问令牌与其本地存储的访问令牌副本及其过期时间进行检查
- 向提供者服务器发出请求，提供者服务器返回有效/无效的响应
- 完全做其他事情
规范没有回答这个问题，因为它是一个对协议的工作没有影响的实现细节。尽管如此，这是一个可以对安全产生影响的好问题。
首先，您必须意识到，在某些实现中，资源服务器和授权服务器只是一个实体的两个角色。
正如OAuth 2.0规范（RFC 6749）所说：
授权服务器和资源服务器之间的交互超出了本规范的范围。授权服务器可以是与资源服务器相同的服务器或单独的实体。
它们可能都出现在一个网站上。也许它们是两个不同的网站，但它们都连接到同一个数据库。然后，资源服务器可以像授权服务器一样在数据库中查找令牌。
如果资源服务器不能读取授权服务器的数据库，那么它必须与授权服务器对话（即使可以，也可能不直接读取数据库）。
如何准确地建立和保护通信取决于您，但HTTPS REST请求非常有意义。许多实施有不同的机制。有关示例，请参阅分布式环境中的OAuth-2.0资源服务器令牌验证。
UPDATE：资源服务器验证令牌的标准方法现在是OAuth 2.0 token Introspection（RFC 7662）。
显然，当第一次向资源服务器提供访问令牌时，资源服务器并不知道它，必须访问授权服务器来检查其有效性。现在有趣的问题是：资源服务器是否可以缓存此响应，或者必须对每个请求进行调用？
这是由资源服务器做出的设计决策，并且可能受到许多不同因素的影响。例如：
- 如果授权服务器响应非常快，则资源服务器可能不需要缓存响应。事实上，设计糟糕的缓存可能比不缓存慢
- 设计和实现具有良好缓存策略的缓存的需要对于在资源服务器中实现良好缓存可能是禁止的
- 根据资源服务器的性质和规模，将RAM或磁盘上的存储分配给高速缓存的成本对于在资源服务器中实现良好的高速缓存可能是令人望而却步的。当访问令牌的数量非常高，并且需要大量存储才能获得合理的缓存命中率时，情况尤其如此
- 资源服务器是否准备好接受访问令牌，即使它已在授权服务器中被吊销
最后一点值得进一步解释。授权服务器通常具有几种撤销令牌的机制。如果资源所有者通过UI撤销授权，则授权服务器必须使通过该授权获得的所有令牌（访问令牌和刷新令牌）无效。资源服务器还可以实现令牌撤销端点（通常用于使用隐式授权的公共客户端中的"注销"机制）。
资源服务器是否准备好承担接受令牌的风险，即使在令牌被吊销之后也是如此？如果是，持续多久？如果是，那么它可以缓存令牌，否则就不能。乍一看，您当然会说资源服务器不应该使用缓存的令牌验证响应。但在某些情况下，性能优势可能会超过风险。这显然还取决于资源服务器存储的资源的性质，以及与之相关的真正风险。
同样，这是我们无法为您做出的设计决定。从安全角度来看，不应将验证响应缓存在资源服务器中。