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