身份验证和资源服务器之间的 OAuth v2 通信
我在理解 OAUTH-v2 的工作原理时遇到了一些麻烦。
OAuth version 2 spec 内容如下：
访问受保护的资源 客户端通过向资源服务器提供访问令牌来访问受保护的资源。资源服务器必须验证访问令牌并确保它没有过期并且其范围涵盖了请求的资源。资源服务器用于验证访问令牌（以及任何错误响应）的方法超出了本规范的范围，但通常涉及资源服务器和授权服务器之间的交互或协调。
资源服务器和授权服务器之间的这种交互在实践中是如何工作的？
资源服务器如何确定它收到的访问令牌是有效的？
资源服务器如何从令牌中提取允许的范围以查看是否应授予对特定资源的访问权限？ Scope 是在访问令牌中编码的，还是资源服务器首先必须联系授权服务器？
资源服务器和授权服务器之间的信任是如何建立的？
访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，由配套规范定义。
有人可以举例说明令牌属性吗？
这超出规范范围的原因是实现两个实体之间的这种连接的方法范围很广。主要问题是您的部署有多复杂。
例如，您是否有一个服务器管理身份验证和访问，以及一组独立的服务，每个服务都有自己的服务器来服务 API 调用？或者，您是否只有一个带有一个 Web 服务器的盒子，它同时处理身份验证/授权和 API 调用？
在单个盒子的情况下，不需要太多，因为发行令牌的实体与验证它们的实体相同。您可以实现令牌以使用数据库表键并在每次请求时在数据库（或内存缓存）中查找记录，或者您可以将范围、用户 ID 和其他信息直接编码到令牌中并使用对称或非对称加密它算法。
处理分布式环境时，事情会变得有点复杂，但不是很多。您仍然在授权服务器上发布令牌，但资源服务器需要一种方法来验证这些令牌。它可以通过向资源服务器提供一个内部 API 来请求授权服务器“解析”令牌（在本地环境中可以很快）来实现，或者两者可以建立公钥/私钥对或对称密钥并使用它将资源服务器需要的所有内容加密到令牌中。
自包含令牌更长，但每个请求提供更好的性能。但是，它们是有代价的——当它们仍然有效（未过期）时，你不能真正撤销它们。出于这个原因，自包含令牌应该是非常短暂的（无论您是否可以接受在被撤销后保持访问开放 - 例如许多网站使用一个小时），并且刷新令牌可以使用一年或更长时间以获得新令牌。
资源到授权服务器 API 的一个示例是 Google Developers Website 中的那个。
虽然它没有指定访问令牌的格式，但响应似乎非常普遍有用。
