1. 简介 (Introduction)

"OAuth 2.0 Authorization Framework" [RFC6749] 定义了 scope 参数, 允许 OAuth 客户端指定访问令牌 (access token) 所请求的范围, 即受限能力. 该机制足以实现静态场景和粗粒度授权请求, 例如 "授予我对资源所有者个人资料的读取访问权限". 但是, 它不足以表达细粒度授权需求, 例如 "请允许我向 Merchant A 转账 45 欧元" 或 "请授予我对目录 A 的读取访问权限以及对文件 X 的写入访问权限".

本规范引入了一个新参数 authorization_details, 允许客户端利用 JSON [RFC8259] 数据结构的表达能力来指定其细粒度授权需求.

例如, 针对贷记转账的授权请求 (在若干开放银行计划中称为 "payment initiation") 可以使用如下 JSON 对象表示:

{
  "type": "payment_initiation",
  "locations": [
    "https://example.com/payments"
  ],
  "instructedAmount": {
    "currency": "EUR",
    "amount": "123.50"
  },
  "creditorName": "Merchant A",
  "creditorAccount": {
    "bic": "ABCIDEFFXXX",
    "iban": "DE02100100109307118603"
  },
  "remittanceInformationUnstructured": "Ref Number Merchant"
}

该对象包含预期支付的详细信息, 例如金额、币种和债权人, 这些信息用于告知用户并取得其同意. 授权服务器 (authorization server, AS) 和相应的资源服务器 (resource server, RS) (提供支付发起 API) 将共同执行该同意.

关于开放银行和电子签名领域新用例所带来挑战的全面讨论, 请参见 [Transaction-Auth].

除了支持自定义授权请求之外, 本规范还引入了一组可跨不同 API 使用的通用数据类型字段.

1.1. 约定和术语 (Conventions and Terminology)

当且仅当本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 以此处所示的全大写形式出现时, 它们应按 BCP 14 [RFC2119] [RFC8174] 中的描述解释.

本规范使用 "OAuth 2.0 Authorization Framework" [RFC6749] 中定义的术语 "access token"、"refresh token"、"authorization server" (AS)、"resource server" (RS)、"authorization endpoint"、"authorization request"、"authorization response"、"token endpoint"、"grant type"、"access token request"、"access token response" 和 "client".

1.1. 约定和术语 (Conventions and Terminology)​

1.1. 约定和术语 (Conventions and Terminology)