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