OAuth 使用者是否在每个请求上使用 OAuth 提供者验证不记名令牌

Question

为了了解有关 OAuth 的更多信息，我正在尝试编写一个 OAuth 2.0 提供者和消费者。

我有点使用Doorkeeper Gem作为我的提供商的参考，但我想编写自己的。

我的问题是关于规范第 1.3 节中关于不记名代币的最后一个项目符号。

(F) 资源服务器验证访问令牌，如果有效，则为请求提供服务。

在这种情况下，确实The resource server validates the access token意味着：

Answer 1

该规范没有回答这个问题，因为它是一个实现细节，对协议的工作没有影响。尽管如此，这是一个可能对安全产生影响的好问题。

首先，您必须认识到，在某些实现中，资源服务器和授权服务器只是一个实体的两个角色。

正如 OAuth 2.0 规范 ( RFC 6749 ) 所说：

授权服务器和资源服务器之间的交互超出了本规范的范围。授权服务器可以是与资源服务器相同的服务器或者是单独的实体。

它们可能都出现在同一个网站中。也许它们是两个不同的网站，但它们确实都连接到同一数据库。然后，资源服务器可以像授权服务器一样在数据库中查找令牌。

如果资源服务器无法读取授权服务器的数据库，则它必须与授权服务器通信（即使可以，最好不要直接读取数据库）。

具体如何建立和保护该通信取决于您，但 HTTPS REST 请求非常有意义。许多实现都有不同的机制。有关示例，请参阅分布式环境中的 OAuth-2.0 资源服务器令牌验证。

更新：资源服务器验证令牌的标准方法现在是 OAuth 2.0 令牌内省（RFC 7662）。

显然，当第一次向资源服务器提供访问令牌时，资源服务器并不知道它，并且必须访问授权服务器以检查其有效性。现在有趣的问题是：资源服务器可以缓存这个响应，还是必须对每个请求进行调用？

这是由资源服务器做出的设计决策，并且它可能受到许多不同因素的影响。例如：

如果授权服务器响应非常快，则资源服务器可能不需要缓存响应。事实上，设计不当的缓存可能比不缓存还要慢。
设计和实现具有良好缓存策略的缓存的需要可能会阻碍在资源服务器中实现良好的缓存。
根据资源服务器的性质和规模，将RAM或磁盘上的存储分配给高速缓存的成本对于在资源服务器中实现良好的高速缓存可能是过高的。当访问令牌的数量非常多并且需要大量存储才能获得合理的缓存命中率时尤其如此。
资源服务器是否准备好接受访问令牌，即使它已在授权服务器中被撤销？

最后一点值得进一步解释。授权服务器通常具有多种撤销令牌的机制。如果资源所有者通过 UI 撤销授权，则授权服务器必须使通过该授权获得的所有令牌（访问令牌和刷新令牌）失效。资源服务器还可以实现令牌撤销端点（通常用于使用隐式授权的公共客户端中的“注销”机制）。

资源服务器是否准备好承担接受令牌的风险，即使令牌已被撤销？如果是这样，持续多久？如果是，则可以缓存令牌，否则不能。乍一看，您当然会说资源服务器不应该使用缓存的令牌验证响应。但在某些情况下，性能优势可能大于风险。显然，这还取决于资源服务器存储的资源的性质以及与之相关的实际风险。

再次强调，这是我们无法为您做出的设计决定。从安全角度来看，您不应在资源服务器中缓存验证响应。