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