摘要

  • GNAP 的 continuation access token 与客户端密钥绑定，只能继续一项授权请求，不能拿去调用受保护资源。
  • 请求处于待决状态时，RFC 9635 不允许签发 API token，也不允许释放主体信息。用户完成交互后，授权服务器仍须重新判断整个请求。

“用户已完成授权页面”很容易在仪表盘上被压缩成一个绿色结果。它可能只表示浏览器回到了客户端，也可能表示客户端拿到了继续 URI，或者某个签名证明了它控制一把密钥。这些事实都重要，却没有一个直接回答：这个客户端此刻是否能对这个资源做这次 API 调用？

RFC 9635 把 GNAP 设计成不混淆这条链。客户端先向授权服务器提交授权请求。若仍需资源所有者同意或终端用户交互，请求进入 pending。此时服务器可以返回继续所需的信息，却不能发出 API 访问令牌，也不能把主体信息交给客户端。它仍在协商访问，而不是已经取得访问。

继续凭据的用途被刻意收窄。它必须绑定客户端实例的密钥，不能是 bearer token，并且必须连同该密钥的证明一起呈交给 continuation URI。授权服务器核验签名，也核验签名与预期密钥的对应关系。这样做证明的是谁可以接着处理同一段授权对话；它没有把这段对话变成资源服务器上的执行许可。

规范把隔离写成双向规则。普通 access token 不得在 continuation endpoint 使用；反过来，continuation access token 也不得用于向资源服务器发起已授权请求，即便资源服务器与授权服务器部署在同一处。两个值看起来都像令牌，不会让它们拥有同一个核验者、同一个 URI 或同一个可产生的效果。

交互完成也不会自动给出结论。交互之后，授权服务器让请求回到处理状态，并重新评估全部上下文；无论资源所有者此前是同意还是拒绝，都如此。只有得到批准的请求才可能返回 API token 或主体信息。请求一旦 finalised，就不能再签发新令牌、返回主体信息或重新开始交互；以后需要访问，必须开启新的请求。

令牌管理又是第三个平面。一个 API token 可以带有独立的管理 URI 和管理凭据，用于轮换或撤销。轮换保留原令牌的权利与属性，并不扩大它们。要取得不同权利，客户端须通过继续更新重新协商，或另开一项请求。管理连续性不是授权扩张。

资源服务器仍有自己的核验边界。GNAP API token 必须按规定附带证明呈交；资源服务器可以对无令牌或无效令牌的请求发出挑战。但即使通过这一步，也不能证明业务目的仍然合适、当前运行条件已经满足，或所请求的效果真的发生。

因此，可靠的证据链应分别保存：请求标识与所求访问、待决状态、继续 URI 与密钥证明、交互结果、授权服务器重新评估、已发 API token 的范围、资源服务器核验、请求接收与独立观察到的结果。把整条链统称为“已授权”，恰好抹掉了协议有意保留的界线。

来源