Skip to main content

2. Authenticated Requests (认证请求)

本节定义了在向资源服务器发起资源请求时发送持有者访问令牌 (Bearer Access Token) 的三种方法。客户端禁止 (MUST NOT) 在每个请求中使用多种方法传输令牌。

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

当在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授权方案来进行持有者令牌的认证请求。资源服务器必须 (MUST) 支持此方法。

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

当在HTTP请求实体主体 (Entity-Body) 中发送访问令牌时,客户端使用"access_token"参数将访问令牌添加到请求主体中。客户端禁止 (MUST NOT) 使用此方法,除非满足以下所有条件:

  • HTTP请求实体头 (Entity-Header) 包含设置为"application/x-www-form-urlencoded"的"Content-Type"头字段。

  • 实体主体遵循HTML 4.01 [W3C.REC-html401-19991224] 定义的"application/x-www-form-urlencoded"内容类型的编码要求。

  • HTTP请求实体主体是单部分的 (Single-Part)。

  • 要在实体主体中编码的内容必须 (MUST) 完全由ASCII [USASCII] 字符组成。

  • HTTP请求方法是具有已定义请求主体语义的方法。特别地,这意味着禁止 (MUST NOT) 使用"GET"方法。

实体主体可以 (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

"application/x-www-form-urlencoded"方法不应该 (SHOULD NOT) 使用,除非在参与的浏览器无法访问"Authorization"请求头字段的应用程序上下文中。资源服务器可以 (MAY) 支持此方法。

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

当在HTTP请求URI中发送访问令牌时,客户端使用"access_token"参数将访问令牌添加到请求URI查询组件,如"统一资源标识符 (URI): 通用语法" [RFC3986] 所定义。

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

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

HTTP请求URI查询可以包含其他特定于请求的参数,在这种情况下,"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请求实体主体中传输访问令牌,否则不应该 (SHOULD NOT) 使用此方法。资源服务器可以 (MAY) 支持此方法。

包含此方法是为了记录当前使用情况;由于其安全缺陷(参见第5节)以及它使用保留查询参数名称(这与URI命名空间最佳实践相悖,根据"万维网架构,第一卷" [W3C.REC-webarch-20041215]),不推荐使用此方法。

📝 三种方法对比总结​

方法使用场景推荐程度资源服务器支持要求
Authorization头标准HTTP请求✅ 推荐 (SHOULD)✅ 必须 (MUST)
表单编码Body浏览器无法访问Authorization头⚠️ 受限使用⚙️ 可选 (MAY)
URI查询参数无法使用其他两种方法时❌ 不推荐 (SHOULD NOT)⚙️ 可选 (MAY)

安全建议​

  • ✅ 优先使用Authorization头 - 最安全的方式
  • ⚠️ 谨慎使用表单编码 - 仅在必要时使用
  • ❌ 避免URI查询参数 - 会被记录在服务器日志、浏览器历史等
Last updated on