身份验证和资源服务器之间的OAuth v2通信

Question

我在理解OAUTH-v2如何工作方面遇到一些麻烦。

的OAuth version 2 spec读取：

访问受保护的资源

客户机访问由呈现所述接入
令牌到资源服务器保护 资源。资源服务器必须验证
访问令牌并确保它没有 已过期，并且其范围覆盖
请求的资源。所使用的资源服务器
方法 验证访问令牌（以及 任何错误响应）是超出了本说明书的 范围，但 通常涉及资源 服务器之间的交互或 协调和授权
服务器。

如何资源服务器和授权服务器工作在实践中之间的这种互动？

• 怎样的资源服务器 确定访问令牌收到 是有效的？
• 资源服务器如何从令牌中提取允许的 作用域以查看是否应将访问权限授予特定资源？范围是在访问令牌中编码的，还是资源服务器首先必须联系授权服务器？
• 资源服务器和授权服务器之间的信任是如何建立的？

访问令牌属性和用于访问 方法保护 资源超出了 规范的范围和 同伴规范的定义。

有人可以给出令牌属性的例子吗？

Answer 1

该规范超出范围的原因是在两个实体之间完成这种连接的各种方法。主要问题是您的部署有多复杂。

例如，您是否有一台服务器管理认证和访问，以及一组离散服务，每台服务器都有自己的服务器来提供API调用？或者，您是否只有一个包含一个Web服务器的盒子，可同时处理认证/授权和API调用？

在单个盒子的情况下，由于发放令牌的实体与验证它们的验证者相同，所以不需要太多。您可以实现令牌以使用数据库表键并在每个请求中查找数据库（或内存高速缓存）中的记录，也可以将范围，用户标识和其他信息直接编码到令牌中，并使用对称或非对称方式对其进行加密算法。

处理分布式环境时事情会变得更复杂一些，但不是太多。您仍然在授权服务器上发出令牌，但资源服务器需要验证这些令牌的方法。它可以通过向资源服务器提供一个内部API来请求授权服务器“解析”令牌（在本地环境中可以很快），或者这两者可以建立公钥/私钥对或对称秘密并使用它将资源服务器需要的所有内容加密到令牌中。

自包含的令牌更长，但每个请求的性能都更好。然而，他们带来了一个价格 - 当他们仍然有效时（不过期），你无法真正撤销它们。出于这个原因，自包含令牌应该是非常短暂的（任何可以接受的方式都是让它在被撤销之后保持打开状态 - 例如许多网站使用一个小时），使用刷新令牌一年或更长时间可以获得新的令牌。

Answer 2

资源授权服务器API的一个示例是Google Developers Website。
虽然它没有指定访问令牌的格式，但是这个回应看起来非常普遍有用。