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