3. 实现说明 (Implementation Note)

3. 实现说明 (Implementation Note)

OAuth 2.0 允许在 access tokens 的风格方面具有部署灵活性. access tokens 可以是 self-contained 的, 使 resource server 在对请求访问 protected resource 的 client 作出 authorization decision 时, 无需与签发这些 tokens 的 authorization server 进一步交互. 然而, 系统设计也可以使用作为 handles 的 access tokens, 这些 handles 引用存储在 authorization server 的 authorization data. 因此, 每当 client 提供 access token 时, resource server 都需要向相应 authorization server 发出 request, 以检索 access token 的内容.

虽然这些并非唯一选项, 但它们说明了对 revocation 的影响. 在后一种情况下, 当 resource server 转发收到的 access token 时, authorization server 能够撤销先前发给 client 的 access token. 在前一种情况下, 如果需要立即 access token revocation, 可以使用 authorization server 与 resource server 之间某种 (目前尚未标准化的) backend interaction. 另一种设计替代方案是签发 short-lived access tokens, 它们可以随时使用相应 refresh tokens 刷新. 这允许 authorization server 对 access tokens 使用期间被撤销的时间施加限制.

选择哪种 token revocation 方法将取决于整体系统设计以及 application service provider 的 risk analysis. 就所需 state 和 communication overhead 而言, revocation 的成本最终取决于期望的 security properties.