Skip to main content

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节)。
  • 资源服务器(RS)可以(MAY)仅根据RS的资源指示符检查locations元素,并可以(MAY)忽略其他authorization_details内容。

11.3. 授权请求的大小 (Size of Authorization Requests)​

在使用此规范的部署中,由于传达了额外的详细信息,授权请求的大小可能会增加。部署应确保在其系统中分配了足够的缓冲空间,以便能够处理预期的大小增加。授权请求URI(例如,在HTTP重定向绑定中)可能会因授权请求中编码的内容而变大。系统实现者应配置其系统,使其能够处理预期的大小增加,而不会在客户端、AS或任何中间基础设施组件(如代理和缓存)上导致错误。

如第12节所示,使用[RFC9101]和[RFC9126]的请求完整性和机密性保护也有助于将URL路径组件的大小保持在界限内。

Last updated on