1. Introduction (简介)

OAuth 2.0 [RFC6749] 中的授权请求采用查询参数序列化, 通常经 Web 浏览器等用户代理发送。

例如, 参数 response_type, client_id, state 与 redirect_uri 编码在请求的 URI 中:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

虽然易于实现, URI 编码无法使用应用层安全来提供机密性与完整性保护。虽然 TLS 用于在客户端与用户代理之间以及用户代理与授权服务器之间提供通信安全, 但 TLS 会话在用户代理处终止。此外, TLS 会话可能在某些中间设备 (如负载均衡器) 处被提前终止。

因此, [RFC6749] 的授权请求存在以下不足:

(a) 经用户代理的通信没有完整性保护, 因而参数可能被篡改 (完整性保护失败);

(b) 通信来源未经身份认证 (来源认证失败);

由于这些固有弱点, 已识别出多种针对协议的攻击, 例如重定向 URI 重写。

使用应用层安全可缓解这些问题。

使用应用层安全还允许由可信第三方准备请求, 使客户端应用无法请求超出先前约定范围的权限。

此外, 按引用传递请求可减少链路上的开销。

选择 JWT [RFC7519] 编码是因为:

(1) 与 JSON 关系密切, 而 JSON 用作 OAuth 的响应格式;

(2) 文本形式对开发者友好;

(3) 相对 XML 更为紧凑;

(4) 作为提议标准的发展状态, 以及配套的签名与加密方法 [RFC7515] [RFC7516];

(5) 相对 XML Signature 与 Encryption, JWS 与 JWE 更易使用。

为 OAuth 2.0 [RFC6749] 流程引入附加授权请求参数 request 与 request_uri。request 参数是一个 JSON Web Token (JWT) [RFC7519], 其 JWT Claims Set (JWT 声明集合) 承载经 JSON 编码的 OAuth 2.0 授权请求参数。注意, 与 RFC 7519 不同, Claims Set 中的元素为经编码的 OAuth 请求参数 [IANA.OAuth.Parameters], 仅辅以少量 IANA 管理的 JSON Web Token 声明 [IANA.JWT.Claims], 尤其是 iss 与 aud。request 参数中的 JWT 使用 JWS 进行完整性保护与来源认证。

JWT [RFC7519] 也可按引用传至授权端点, 此时使用参数 request_uri 代替 request。

与查询参数相比, 使用 JWT [RFC7519] 作为请求编码具有以下优势:

(a) 完整性保护. 可对请求签名以校验其完整性.

(b) 来源认证. 可对请求签名以认证签名者.

(d) 收集最小化. 可由可信第三方对请求签名, 证明授权请求符合某策略. 例如, 可由可信第三方预先审查请求, 确认所请求的个人数据严格限于执行终端用户所要求流程所必需; 再由该第三方签名. 授权服务器随后校验签名并向终端用户展示符合性状态, 用户在授权时对请求的正当性更有把握. 某些情形下, 在此类条件下甚至可省略授权对话.

按引用传递请求在若干情形下有用, 例如:

需要减小传输请求体积时. 使用应用层安全会增加请求体积, 在使用公钥密码学时尤为明显.
客户端不希望执行应用层密码学时. 授权服务器可提供端点, 通过与客户端的直接通信接受授权请求, 从而认证客户端且信道受 TLS 保护.

OpenID Connect [OpenID.Core] 已在使用该能力.

见 1.1. Requirements Language (规范性用语).

1. Introduction (简介)​

1. Introduction (简介)