摘要

  • RFC 9728 允许受保护资源发布交互所需的元数据；该文档是发现输入，而不是访问许可。
  • 只有 resource 与预期资源标识完全一致时，元数据才可使用。令牌签发、资源端验证与操作效果仍是独立事实。

“资源已经告诉我们该找哪个授权服务器”很容易被缩写成“已经获权”。实际得到的只是一个 JSON 文档和可能的下一步。被点名的服务器未必会向这个客户端签发令牌；签发的令牌未必面向这个资源；资源服务器也未必接受它；即使接受，业务动作还可能被当前前置条件拒绝。

RFC 9728 把第一步限定得很清楚。资源在由自身标识派生的 .well-known 地址公布元数据，可列出授权服务器、scope 与 bearer 提示方式。这让发现可互操作，却没有把资源、授权服务器和业务流程的决定权合并到一个文档中。

最关键的控制是精确匹配。普通发现时，强制字段 resource 必须与用于派生元数据 URL 的资源标识完全相同。若该 URL 来自 WWW-Authenticate，它必须与客户端向资源服务器实际请求的 URL 完全相同；不相同就不得使用返回数据。相同域名、相似路径或相近产品名称都不够。

这在多路径、多租户主机上尤其重要。well-known 后缀被插入到资源路径之前，使同一主机的不同资源能发布不同的描述。RFC 9728 明确这不是关于整台主机的一般信息。若把它理解为全站权限表，团队会在申请令牌之前就把策略边界扩大了。

已公布的列表也不是完整的权利清单。authorization_servers 可以不列出某些支持的服务器，scopes_supported 也可以不列出某些 scope。签名元数据只加强“谁为这组发现信息背书”，不会认证客户端、证明同意、验证令牌或确认业务执行。RFC 8414、RFC 8707 和 RFC 6750 分别保留了不同验证面。

Sources