11. 实现注意事项 (Implementation Considerations)
11.1. 在特定部署中使用 authorization_details (Using authorization_details in a Certain Deployment)
使用本规范的生态系统将定义所使用的 type 值和授权详情类型, 以及为每个此类类型定义哪些扩展字段. 此类定义 SHOULD 为每个 type 值包含一个 JSON Schema (或其他适当的形式化表示), 以便 AS 和客户端进行验证.
授权服务器 SHOULD 发布 authorization_details_types_supported 元数据参数, 并声明其部署所支持的 type 值.
在决定某个部署或用例应使用 scope 还是 authorization_details 时, 以下考虑因素可能有所帮助:
- 对于每个 scope 值都传达唯一含义的用例, 可以使用
scope. - 如果所传达的特权可以通过进一步的授权详情实现粒度化, 则应使用
authorization_details.
开发者不应使用这两种授权数据格式来指定同一种授权数据, 以限制复杂性并避免混淆.
11.2. 最小产品实现 (Minimal Product Implementation)
只希望实现 RAR 最小功能的系统可以通过实现功能子集来实现:
- 客户端 MAY 仅支持一个特定
type值, 并且仅支持该特定type的通用数据字段 (第 2.1 节). - AS MAY 仅支持一个特定
type值, 并且仅支持该特定type的通用数据字段 (第 2.1 节). - 资源服务器 (Resource Server, RS) MAY 仅根据 RS 处的资源指示符检查
locations元素, 并 MAY 忽略其他authorization_details内容.
11.3. 授权请求的大小 (Size of Authorization Requests)
在使用本规范的部署中, 由于传达了额外详情, 授权请求的大小很可能会增加. 部署应确保系统中分配了足够的缓冲空间, 以便能够处理预期的大小增长. 授权请求 URI (例如 HTTP 重定向绑定中的 URI) 可能会因授权请求中编码的内容而变大. 系统实现者应配置其系统, 使其能够处理预期的大小增长, 而不会在客户端、AS 或任何中间基础设施组件 (如代理和缓存) 处导致错误.
如第 12 节所示, 使用 [RFC9101] 和 [RFC9126] 提供请求完整性和机密性保护, 也有助于将 URL 路径组件的大小保持在限度内.