4. 安全考量

由于实现 OAuth 2.0 系统有许多不同且有效的方式, 授权服务器判断令牌当前是否 "active" 的方式也有许多种. 但是, 使用令牌内省的资源服务器依赖授权服务器来确定令牌状态, 因此授权服务器必须针对令牌状态执行所有适用检查. 例如, 这些测试包括:

如果令牌可能过期, 授权服务器必须确定该令牌是否已经过期.
如果令牌可以在可用之前签发, 授权服务器必须确定该令牌的有效期是否已经开始.
如果令牌在签发后可以被撤销, 授权服务器必须确定此类撤销是否已经发生.
如果令牌已签名, 授权服务器必须验证签名.
如果令牌只能在某些资源服务器上使用, 授权服务器必须确定该令牌是否可用于发起内省调用的资源服务器.

如果授权服务器未执行任何适用检查, 资源服务器可能会基于该响应作出错误的安全决策. 请注意, 并非所有这些检查都适用于所有 OAuth 2.0 部署, 授权服务器负责确定哪些检查 (以及任何其他检查) 适用.

如果内省端点未受保护且未限流, 攻击者可能利用它轮询一系列可能的令牌值, 以探测有效令牌. 为防止这种情况, 授权服务器必须要求需要访问内省端点的受保护资源进行认证, 并应要求受保护资源被明确授权调用内省端点. 此类认证凭据的具体细节超出本规范范围, 但通常这些凭据可以采用 token endpoint 使用的任何有效客户端认证机制, OAuth 2.0 访问令牌, 或其他 HTTP 授权或认证机制. 同一软件如果同时作为客户端和受保护资源运行, 可以在 token endpoint 和 introspection endpoint 之间复用相同凭据, 但这样做可能混淆软件中客户端部分和受保护资源部分的活动; 授权服务器可以要求每种模式使用单独凭据.

由于内省端点将 OAuth 2.0 令牌作为参数接收, 并以用于作出授权决策的信息进行响应, 服务器必须支持 Transport Layer Security (TLS) 1.2 [RFC5246], 并可以支持满足其安全要求的其他传输层机制. 使用 TLS 时, 客户端或受保护资源必须按 [RFC6125] 指定执行 TLS/SSL 服务器证书检查. 实现安全考量可见 Recommendations for Secure Use of TLS and DTLS [BCP195].

为防止访问令牌值通过查询参数泄露到服务器端日志中, 提供令牌内省的授权服务器可以禁止在内省端点使用 HTTP GET, 并改为要求在内省端点使用 HTTP POST 方法.

为避免泄露授权服务器内部状态, 非活动令牌的内省响应不应包含必需 "active" claim (其值设为 "false") 之外的任何附加 claims.

由于受保护资源可以缓存内省端点响应, 使用本协议的 OAuth 2.0 系统设计者必须考虑缓存此类安全信息固有的性能和安全权衡. 较不激进且超时时间较短的缓存会为受保护资源提供更新的信息 (因为它需要更频繁查询内省端点), 代价是增加网络流量和内省端点负载. 较激进且持续时间较长的缓存会最小化网络流量和内省端点负载, 但存在令牌信息过期的风险. 例如, 当受保护资源依赖缓存响应值作出授权决策时, 令牌可能已经被撤销. 这会形成一个时间窗口, 在此期间被撤销的令牌仍可能用于受保护资源. 因此, 需要结合被访问受保护资源的关注点和敏感性, 以及令牌在中间期间被撤销或失效的可能性, 仔细考虑可接受的缓存有效时长. 高敏感环境可以选择在受保护资源上完全禁用缓存, 以彻底消除陈旧缓存信息风险, 同样代价是增加网络流量和服务器负载. 如果响应包含 "exp" 参数 (过期时间), 则响应禁止被缓存到超过其中指示的时间.

提供令牌内省的授权服务器必须能够理解在此调用期间呈现给它的令牌值. 实现这一点的确切方式属于实现细节, 超出本规范范围. 对于非结构化令牌, 这可以表现为简单的服务器端数据库查询, 查询包含令牌上下文信息的数据存储. 对于结构化令牌, 这可以表现为服务器解析令牌, 验证其签名或其他保护机制, 并将令牌中包含的信息返回给受保护资源 (使受保护资源像客户端一样无需了解令牌内容). 请注意, 对于携带内省过程中所需加密信息的令牌, 授权服务器必须能够解密并验证令牌以访问该信息. 还要注意, 如果授权服务器既不存储有关令牌的信息, 也无法通过解析令牌本身访问令牌信息, 则它很可能无法提供内省服务.