身份验证和资源服务器之间的 OAuth v2 通信

这超出规范范围的原因是实现两个实体之间的这种连接的方法范围很广。主要问题是您的部署有多复杂。

例如，您是否有一个服务器管理身份验证和访问，以及一组独立的服务，每个服务都有自己的服务器来服务 API 调用？或者，您是否只有一个带有一个 Web 服务器的盒子，它同时处理身份验证/授权和 API 调用？

在单个盒子的情况下，不需要太多，因为发行令牌的实体与验证它们的实体相同。您可以实现令牌以使用数据库表键并在每次请求时在数据库（或内存缓存）中查找记录，或者您可以将范围、用户 ID 和其他信息直接编码到令牌中并使用对称或非对称加密它算法。

处理分布式环境时，事情会变得有点复杂，但不是很多。您仍然在授权服务器上发布令牌，但资源服务器需要一种方法来验证这些令牌。它可以通过向资源服务器提供一个内部 API 来请求授权服务器“解析”令牌（在本地环境中可以很快）来实现，或者两者可以建立公钥/私钥对或对称密钥并使用它将资源服务器需要的所有内容加密到令牌中。

自包含令牌更长，但每个请求提供更好的性能。但是，它们是有代价的——当它们仍然有效（未过期）时，你不能真正撤销它们。出于这个原因，自包含令牌应该是非常短暂的（无论您是否可以接受在被撤销后保持访问开放 - 例如许多网站使用一个小时），并且刷新令牌可以使用一年或更长时间以获得新令牌。

资源到授权服务器 API 的一个示例是 Google Developers Website 中的那个。
虽然它没有指定访问令牌的格式，但响应似乎非常普遍有用。