跳到主要内容

2. 已认证请求

本节定义在发往资源服务器的资源请求中发送 bearer 访问令牌的三种方法. 客户端在每个请求中 MUST NOT 使用多于一种方法传输令牌.

2.1. Authorization 请求头字段 (Authorization Request Header Field)​

当在 HTTP/1.1 [RFC2617] 定义的 "Authorization" 请求头字段中发送访问令牌时, 客户端使用 "Bearer" 认证方案传输访问令牌.

例如:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

此方案中 "Authorization" 头字段的语法遵循 [RFC2617] 第 2 节定义的 Basic 方案用法. 注意, 与 Basic 一样, 它不符合 [RFC2617] 第 1.2 节定义的通用语法, 但与正在为 HTTP 1.1 [HTTP-AUTH] 制定的通用认证框架兼容. 不过, 为反映现有部署, 它没有遵循该框架中概述的首选实践. Bearer 凭据的语法如下:

b64token    = 1*( ALPHA / DIGIT /
                  "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token

客户端 SHOULD 使用 "Authorization" 请求头字段和 "Bearer" HTTP 授权方案, 通过 bearer 令牌发起已认证请求. 资源服务器 MUST 支持此方法.

2.2. 表单编码正文参数 (Form-Encoded Body Parameter)​

当在 HTTP 请求 entity-body 中发送访问令牌时, 客户端使用 "access_token" 参数将访问令牌加入 request-body. 除非满足以下所有条件, 客户端 MUST NOT 使用此方法:

  • HTTP 请求 entity-header 包含 "Content-Type" 头字段, 且设置为 "application/x-www-form-urlencoded".

  • entity-body 遵循 HTML 4.01 [W3C.REC-html401-19991224] 定义的 "application/x-www-form-urlencoded" content-type 编码要求.

  • HTTP 请求 entity-body 是单部分.

  • entity-body 中要编码的内容 MUST 完全由 ASCII [USASCII] 字符组成.

  • HTTP 请求方法是 request-body 具有已定义语义的方法. 特别地, 这意味着 MUST NOT 使用 "GET" 方法.

entity-body MAY 包含其他特定于请求的参数. 在这种情况下, "access_token" 参数 MUST 使用 "&" 字符 (ASCII 码 38) 与这些请求特定参数正确分隔.

例如, 客户端使用传输层安全发出以下 HTTP 请求:

POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=mF_9.B5f-4.1JqM

除非在参与浏览器无法访问 "Authorization" 请求头字段的应用上下文中, 否则 SHOULD NOT 使用 "application/x-www-form-urlencoded" 方法. 资源服务器 MAY 支持此方法.

2.3. URI 查询参数 (URI Query Parameter)​

当在 HTTP 请求 URI 中发送访问令牌时, 客户端使用 "access_token" 参数, 将访问令牌加入 "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986] 定义的请求 URI query 组件.

例如, 客户端使用传输层安全发出以下 HTTP 请求:

GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
Host: server.example.com

HTTP 请求 URI query 可以包含其他特定于请求的参数. 在这种情况下, "access_token" 参数 MUST 使用 "&" 字符 (ASCII 码 38) 与这些请求特定参数正确分隔.

例如:

https://server.example.com/resource?access_token=mF_9.B5f-4.1JqM&p=q

使用 URI 查询参数方法的客户端 SHOULD 同时发送包含 "no-store" 选项的 Cache-Control 头. 服务器对此类请求的成功响应 (2XX 状态) SHOULD 包含带有 "private" 选项的 Cache-Control 头.

由于 URI 方法存在安全弱点 (见第 5 节), 包括包含访问令牌的 URL 很可能被记录, 除非无法在 "Authorization" 请求头字段或 HTTP 请求 entity-body 中传输访问令牌, 否则 SHOULD NOT 使用此方法. 资源服务器 MAY 支持此方法.

包含此方法是为了记录当前用法. 由于其安全缺陷 (见第 5 节), 并且根据 "Architecture of the World Wide Web, Volume One" [W3C.REC-webarch-20041215], 它使用了保留的查询参数名, 与 URI 命名空间最佳实践相悖, 因此不建议使用此方法.

最后于 更新