关于Open Banking授权服务器处理含NULL SCOPE的GET /token或/register请求的技术问询及相关风险与场景探讨

2. 授权服务器应拒绝还是接受这类请求？ #

根据Open Banking核心规范（比如OBIE的OAuth 2.0 Profile），scope并非强制必填项，但处理逻辑得结合端点场景来看：

• 对于/register端点：注册的核心是验证客户端身份（靠TLS证书和软件声明），不是即时分配权限。如果请求没带scope或用了null scope，服务器可以接受，但必须基于客户端证书里的组织权限（比如ASPSP授权的服务类型）自动分配最小必要的默认范围，绝对不能开放全权限。要是服务器没法通过证书确定合理的默认范围，才应该拒绝请求。

• 对于/token端点：如果是客户端凭证流（M2M场景），null scope的处理要看服务器的权限模型。如果客户端证书已经绑定了特定访问权限，服务器可以接受null scope并颁发对应权限的令牌；但如果服务器的权限模型必须依赖显式的scope参数来限制访问，那就要拒绝无效scope的请求。

需要注意，部分区域的Open Banking实施（比如英国OB）对特定场景有更严格要求，比如客户发起的授权必须带明确scope，而M2M场景可以灵活处理。

3. 安全风险担忧与M2M场景的合理性 #

你的担忧是否过度？

这完全取决于服务器权限验证的成熟度：

• 如果你的服务器没实现基于证书的权限绑定，允许null scope就可能默认给客户端无限制访问权限，这种情况下你的担忧完全合理——确实存在滥用风险（比如恶意客户端拿到超出权限的令牌）。
• 如果服务器已经能通过客户端证书精准识别允许的权限范围，并且会自动给null scope请求分配匹配的最小权限，那这种担忧就是过度的。规范允许scope非必填，正是基于「证书已作为主要权限载体」的前提。

无需使用Scope的M2M合理场景

当然存在，举几个常见例子：

• 客户端自身数据访问：比如ASPSP内部的监控服务，只需要访问自身系统状态数据，不需要额外scope区分权限，证书足够证明身份和权限。
• 预绑定权限的机器服务：比如第三方服务商的对账系统，其证书已经被ASPSP预先授权了特定账户报表访问权限，请求令牌时不用指定scope，服务器直接基于证书发对应权限的令牌。
• 最小权限默认场景：当客户端只需要最基础的服务访问（比如获取API版本信息），null scope可以触发服务器分配预设的最小权限令牌，避免冗余的scope配置。

内容的提问来源于stack exchange，提问作者Martin Sansone - MiOEE