互联网工程任务组 (IETF) M. Jones
请求评议：6750 Microsoft
类别：标准化进程 D. Hardt
ISSN：2070-1721 Independent
2012 年 10 月
OAuth 2.0 授权框架：承载令牌用法
摘要
本规范描述了如何在 HTTP 请求中使用承载令牌，以访问受
OAuth 2.0 保护的资源。任何持有承载令牌的一方（“承载者”）
都可以使用它来访问相关资源（无需证明其拥有加密密钥）。
为防止误用，承载令牌需要在存储和传输过程中受到保护，
避免泄露。
本文档状态
本文档是一份互联网标准化进程文档。
本文档是互联网工程任务组（IETF）的成果。它代表了 IETF
社区的共识。本文档已经过公开评审，并已由互联网工程指导
组（IESG）批准发布。有关互联网标准的更多信息，请参见
RFC 5741 第 2 节。
有关本文档当前状态、任何勘误以及如何提供反馈的信息，
可在以下地址获取：
http://www.rfc-editor.org/info/rfc6750.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones & Hardt 标准化进程 [第 1 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
目录
1. 引言 ........................................................2
1.1. 符号约定 ................................................3
1.2. 术语 ....................................................3
1.3. 概述 ....................................................3
2. 经认证的请求 ................................................4
2.1. Authorization 请求头字段 ................................5
2.2. 表单编码的主体参数 ......................................5
2.3. URI 查询参数 ............................................6
3. WWW-Authenticate 响应头字段 ..................................7
3.1. 错误代码 ................................................9
4. 访问令牌响应示例 ............................................10
5. 安全考虑事项 ................................................10
5.1. 安全威胁 ................................................10
5.2. 威胁缓解 ................................................11
5.3. 建议汇总 ................................................13
6. IANA 考虑事项 ...............................................14
6.1. OAuth 访问令牌类型注册 ..................................14
6.1.1. "Bearer" OAuth 访问令牌类型 .......................14
6.2. OAuth 扩展错误注册 ......................................14
6.2.1. "invalid_request" 错误值 .........................14
6.2.2. "invalid_token" 错误值 ...........................15
6.2.3. "insufficient_scope" 错误值 ......................15
7. 参考文献 ....................................................15
7.1. 规范性参考文献 ..........................................15
7.2. 资料性参考文献 ..........................................17
附录 A. 致谢 ...................................................18
1. 引言
OAuth 使客户端能够通过获取访问令牌来访问受保护资源，该
访问令牌在“The OAuth 2.0 Authorization Framework”[RFC6749] 中被
定义为“表示授予给客户端的访问授权的字符串”，而不是直接
使用资源所有者的凭据。
令牌由授权服务器在资源所有者批准后颁发给客户端。客户端
使用访问令牌来访问由资源服务器托管的受保护资源。本规范
描述了当 OAuth 访问令牌是承载令牌时，如何发起受保护资源
请求。
本规范定义了通过 HTTP/1.1 [RFC2616] 使用传输层安全（TLS）
[RFC5246] 来访问受保护资源时承载令牌的用法。实现和使用
本规范时，TLS 是强制要求的；其他规范可以扩展本规范，以便
与其他协议一起使用。虽然本规范设计用于与通过 OAuth 2.0
Jones & Hardt 标准化进程 [第 2 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
授权 [RFC6749] 流程产生、用于访问 OAuth 受保护资源的访问令牌
一起使用，但本规范实际上定义了一种通用 HTTP 授权方法，
可使用任何来源的承载令牌来访问由这些承载令牌保护的任何
资源。Bearer 认证方案主要意图用于通过 WWW-Authenticate
和 Authorization HTTP 头进行服务器认证，但并不排除其用于
代理认证。
1.1. 符号约定
本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、
“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和
“OPTIONAL”应按“Key words for use in RFCs to Indicate Requirement
Levels”[RFC2119] 中的描述来解释。
本文档使用 [RFC5234] 的增强巴科斯-瑙尔范式（ABNF）表示法。
另外，以下规则包含自 HTTP/1.1 [RFC2617]：auth-param 和
auth-scheme；以及来自“Uniform Resource Identifier (URI):
Generic Syntax”[RFC3986]：URI-reference。
除非另有说明，所有协议参数名称和值均区分大小写。
1.2. 术语
承载令牌
一种安全令牌，具有这样的性质：任何持有该令牌的一方
（“承载者”）都可以按任何其他持有该令牌的一方能够使用
它的方式来使用该令牌。使用承载令牌不要求承载者证明其
拥有加密密钥材料（持有证明）。
所有其他术语均按“The OAuth 2.0 Authorization Framework”
[RFC6749] 中的定义。
1.3. 概述
OAuth 提供了一种方法，使客户端能够代表资源所有者访问受
保护资源。一般情况下，在客户端能够访问受保护资源之前，
它必须先从资源所有者处获得授权许可，然后用该授权许可
交换访问令牌。访问令牌表示该授权许可授予的范围、持续
时间以及其他属性。客户端通过向资源服务器出示访问令牌来
访问受保护资源。在某些情况下，客户端可以直接向授权服务
器出示自己的凭据以获取访问令牌，而不必先从资源所有者处
获得授权许可。
Jones & Hardt 标准化进程 [第 3 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
访问令牌提供了一种抽象，用资源服务器能够理解的单个令牌
来替代不同的授权构造（例如，用户名和密码、断言）。这种
抽象使得能够颁发仅在较短时间内有效的访问令牌，同时也
消除了资源服务器理解多种认证方案的需要。
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
图 1：抽象协议流程
图 1 所示的抽象 OAuth 2.0 流程描述了客户端、资源所有者、
授权服务器和资源服务器（在 [RFC6749] 中描述）之间的交互。
本文档规定了以下两个步骤：
(E) 客户端向资源服务器请求受保护资源，并通过出示访问
令牌进行认证。
(F) 资源服务器验证访问令牌，如果有效，则为该请求提供
服务。
本文档还对步骤 (D) 中返回的访问令牌施加语义要求。
2. 经认证的请求
本节定义了在向资源服务器发出的资源请求中发送承载访问
令牌的三种方法。客户端在每个请求中 MUST NOT 使用超过一种
方法来传输令牌。
Jones & Hardt 标准化进程 [第 4 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
2.1. 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 使用带有 "Bearer" HTTP 授权方案的
"Authorization" 请求头字段，通过承载令牌发起经认证的请求。
资源服务器 MUST 支持此方法。
2.2. 表单编码的主体参数
当在 HTTP 请求实体主体中发送访问令牌时，客户端使用
"access_token" 参数将访问令牌添加到请求主体中。除非满足
以下所有条件，否则客户端 MUST NOT 使用此方法：
o HTTP 请求实体头包含 "Content-Type" 头字段，且该字段设为
"application/x-www-form-urlencoded"。
o 实体主体遵循 HTML 4.01 [W3C.REC-html401-19991224] 所定义的
"application/x-www-form-urlencoded" 内容类型的编码要求。
o HTTP 请求实体主体是单部分的。
Jones & Hardt 标准化进程 [第 5 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
o 实体主体中要编码的内容 MUST 完全由 ASCII [USASCII] 字符组成。
o 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
除非在参与的浏览器无法访问 "Authorization" 请求头字段的
应用上下文中，否则 SHOULD NOT 使用
"application/x-www-form-urlencoded" 方法。资源服务器 MAY 支持
此方法。
2.3. URI 查询参数
当在 HTTP 请求 URI 中发送访问令牌时，客户端按“Uniform
Resource Identifier (URI): Generic Syntax”[RFC3986] 定义，将
访问令牌作为 "access_token" 参数添加到请求 URI 的查询组件中。
例如，客户端使用传输层安全发起如下 HTTP 请求：
GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
Host: server.example.com
HTTP 请求 URI 查询可以包含其他特定于请求的参数；在这种
情况下，"access_token" 参数 MUST 使用 "&" 字符（ASCII 码 38）
与特定于请求的参数正确分隔。
Jones & Hardt 标准化进程 [第 6 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
例如：
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 节），
不建议使用它；此外，根据“Architecture of the World Wide Web,
Volume One”[W3C.REC-webarch-20041215]，它使用了一个保留的查询
参数名称，这违背 URI 命名空间最佳实践。
3. WWW-Authenticate 响应头字段
如果受保护资源请求未包含认证凭据，或不包含可启用对受
保护资源访问的访问令牌，则资源服务器 MUST 包含 HTTP
"WWW-Authenticate" 响应头字段；它也 MAY 在响应其他条件时
包含该字段。"WWW-Authenticate" 头字段使用 HTTP/1.1
[RFC2617] 定义的框架。
本规范定义的所有质询 MUST 使用 auth-scheme 值 "Bearer"。
该方案后面 MUST 跟随一个或多个 auth-param 值。本规范使用
或定义的 auth-param 属性如下。也 MAY 使用其他 auth-param
属性。
MAY 包含 "realm" 属性，以 HTTP/1.1 [RFC2617] 中描述的方式
指示保护范围。"realm" 属性 MUST NOT 出现多次。
"scope" 属性在 [RFC6749] 第 3.3 节中定义。"scope" 属性是
由空格分隔的、区分大小写的 scope 值列表，用于指示访问
所请求资源时访问令牌所需的作用域。"scope" 值由实现定义；
没有针对它们的集中式注册表；允许值由授权服务器定义。
"scope" 值的顺序没有意义。在某些情况下，"scope" 值将用于
Jones & Hardt 标准化进程 [第 7 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
请求具有足够访问范围的新访问令牌，以便使用受保护资源。
使用 "scope" 属性是 OPTIONAL 的。"scope" 属性 MUST NOT 出现
多次。"scope" 值意图供程序使用，并不意味着显示给终端用户。
以下给出两个 scope 值示例；它们分别取自 OpenID Connect
[OpenID.Messages] 和 Open Authentication Technology Committee
(OATC) Online Multimedia Authorization Protocol [OMAP] 的
OAuth 2.0 用例：
scope="openid profile email"
scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"
如果受保护资源请求包含访问令牌并且认证失败，资源服务器
SHOULD 包含 "error" 属性，以向客户端提供访问请求被拒绝的
原因。参数值在第 3.1 节中描述。此外，资源服务器 MAY 包含
"error_description" 属性，以向开发者提供人类可读的解释；
该解释并不意味着显示给终端用户。它也 MAY 包含 "error_uri"
属性，该属性为一个绝对 URI，标识解释该错误的人类可读网页。
"error"、"error_description" 和 "error_uri" 属性 MUST NOT 出现
多次。
"scope" 属性的值（在 [RFC6749] 附录 A.4中规定）MUST NOT 包含
%x21 / %x23-5B / %x5D-7E 集合之外的字符来表示 scope 值，
以及 %x20 作为 scope 值之间的分隔符。"error" 和
"error_description" 属性的值（在 [RFC6749] 附录 A.7 和 A.8
中规定）MUST NOT 包含 %x20-21 / %x23-5B / %x5D-7E 集合之外的
字符。"error_uri" 属性的值（在 [RFC6749] 附录 A.9中规定）
MUST 符合 URI-reference 语法，因此 MUST NOT 包含 %x21 /
%x23-5B / %x5D-7E 集合之外的字符。
例如，响应没有认证的受保护资源请求：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Jones & Hardt 标准化进程 [第 8 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
以及响应使用过期访问令牌进行认证尝试的受保护资源请求：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
error="invalid_token",
error_description="The access token expired"
3.1. 错误代码
当请求失败时，资源服务器使用适当的 HTTP 状态码（通常为
400、401、403 或 405）进行响应，并在响应中包含以下错误
代码之一：
invalid_request
请求缺少必需参数，包含不受支持的参数或参数值，重复
同一参数，使用超过一种方法包含访问令牌，或者在其他
方面格式错误。资源服务器 SHOULD 以 HTTP 400（Bad
Request）状态码响应。
invalid_token
所提供的访问令牌已过期、已撤销、格式错误，或因其他
原因无效。资源服务器 SHOULD 以 HTTP 401（Unauthorized）
状态码响应。客户端 MAY 请求新的访问令牌，并重试受
保护资源请求。
insufficient_scope
该请求需要比访问令牌所提供权限更高的权限。资源服务
器 SHOULD 以 HTTP 403（Forbidden）状态码响应，并 MAY
包含 "scope" 属性，指出访问受保护资源所需的作用域。
如果请求缺少任何认证信息（例如，客户端不知道需要认证，
或尝试使用不受支持的认证方法），则资源服务器 SHOULD NOT
包含错误代码或其他错误信息。
例如：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Jones & Hardt 标准化进程 [第 9 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
4. 访问令牌响应示例
通常，承载令牌作为 OAuth 2.0 [RFC6749] 访问令牌响应的一部分
返回给客户端。此类响应示例如下：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
5. 安全考虑事项
本节描述使用承载令牌时与令牌处理有关的相关安全威胁，并
描述如何缓解这些威胁。
5.1. 安全威胁
以下列表列出了若干针对使用某种形式令牌的协议的常见威胁。
该威胁列表基于 NIST Special Publication 800-63 [NIST800-63]。
由于本文档基于 OAuth 2.0 Authorization 规范 [RFC6749] 构建，
因此我们不讨论其中或相关文档中已描述的威胁。
令牌制造/修改：攻击者可能生成伪造令牌，或修改现有令牌的
内容（例如认证或属性声明），从而导致资源服务器向客户端
授予不适当的访问权限。例如，攻击者可能修改令牌以延长
有效期；恶意客户端可能修改断言，以访问其不应能够查看的
信息。
令牌泄露：令牌可能包含包括敏感信息在内的认证和属性声明。
Jones & Hardt 标准化进程 [第 10 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
令牌重定向：攻击者使用为一个资源服务器消费而生成的令牌，
来访问另一个错误地认为该令牌是为其生成的资源服务器。
令牌重放：攻击者尝试使用过去已经在该资源服务器上使用过的
令牌。
5.2. 威胁缓解
通过使用数字签名或消息认证码（MAC）保护令牌内容，可以
缓解大量威胁。或者，承载令牌可以包含对授权信息的引用，
而不是直接编码该信息。攻击者 MUST 无法实际猜出此类引用；
使用引用可能需要服务器和令牌颁发者之间进行额外交互，以
将该引用解析为授权信息。本规范未定义此类交互的机制。
本文档未规定令牌的编码或内容；因此，有关保证令牌完整性
保护手段的详细建议超出本文档范围。令牌完整性保护 MUST
足以防止令牌被修改。
为处理令牌重定向，授权服务器在令牌中包含预期接收方的
身份（受众）非常重要，通常为单个资源服务器（或资源服务器
列表）。还 RECOMMENDED 将令牌的使用限制在特定范围内。
授权服务器 MUST 实现 TLS。应实现哪些版本会随时间变化，并
取决于实现时的广泛部署情况和已知安全漏洞。在撰写本文时，
TLS 1.2 版 [RFC5246] 是最新版本，但其实际部署非常有限，
并且在实现工具包中可能不易获得。TLS 1.0 版 [RFC2246] 是
部署最广泛的版本，并将提供最广泛的互操作性。
为防止令牌泄露，MUST 使用提供机密性和完整性保护的密码套件，
通过 TLS [RFC5246] 应用机密性保护。这要求客户端与授权服务器
之间的通信交互，以及客户端与资源服务器之间的交互，都使用
机密性和完整性保护。由于实现和使用本规范时 TLS 是强制
要求的，因此它是防止通过通信信道泄露令牌的首选方法。对于
Jones & Hardt 标准化进程 [第 11 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
客户端被阻止观察令牌内容的那些情况，除了使用 TLS 保护外，
还 MUST 应用令牌加密。作为对令牌泄露的进一步防御，客户端
在向受保护资源发出请求时 MUST 验证 TLS 证书链，包括检查
证书吊销列表（CRL）[RFC5280]。
Cookie 通常以明文传输。因此，其中包含的任何信息都有泄露
风险。因此，承载令牌 MUST NOT 存储在可能以明文发送的
cookie 中。关于 cookie 的安全考虑事项，请参见“HTTP State
Management Mechanism”[RFC6265]。
在某些部署中，包括使用负载均衡器的部署中，到资源服务器
的 TLS 连接会在实际提供资源的服务器之前终止。这可能导致
令牌在终止 TLS 连接的前端服务器与提供资源的后端服务器
之间不受保护。在此类部署中，MUST 采用充分措施来确保令牌
在前端和后端服务器之间的机密性；令牌加密就是一种可能的
措施。
为处理令牌捕获和重放，给出以下建议：第一，令牌的生存期
MUST 受到限制；实现这一点的一种方法是在令牌的受保护部分
中放入有效时间字段。请注意，使用短寿命（1 小时或更短）的
令牌可以减少其泄露造成的影响。第二，客户端与授权服务器
之间、客户端与资源服务器之间的交换 MUST 应用机密性保护。
因此，通信路径上的窃听者无法观察令牌交换。因此，这样的
路径上对手无法重放令牌。此外，在向资源服务器出示令牌时，
客户端 MUST 按照“HTTP Over TLS”[RFC2818] 第 3.1 节验证该资源
服务器的身份。请注意，客户端在向受保护资源发出这些请求时
MUST 验证 TLS 证书链。向未经认证且未经授权的资源服务器
出示令牌，或未验证证书链，将使对手能够窃取令牌并获得对
受保护资源的未经授权访问。
Jones & Hardt 标准化进程 [第 12 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
5.3. 建议汇总
保护承载令牌：客户端实现 MUST 确保承载令牌不会泄露给非预期
方，因为这些方将能够使用它们来访问受保护资源。这是使用
承载令牌时的主要安全考虑事项，也是以下所有更具体建议的
基础。
验证 TLS 证书链：客户端在向受保护资源发出请求时 MUST 验证
TLS 证书链。未能这样做可能使 DNS 劫持攻击能够窃取令牌并
获得非预期访问权限。
始终使用 TLS (https)：客户端在使用承载令牌发出请求时 MUST
始终使用 TLS [RFC5246] (https) 或等效的传输安全。未能这样
做会使令牌暴露于多种攻击之下，从而可能使攻击者获得非
预期访问权限。
不要在 cookie 中存储承载令牌：实现 MUST NOT 将承载令牌存储
在可能以明文发送的 cookie 中（这是 cookie 的默认传输
模式）。确实将承载令牌存储在 cookie 中的实现 MUST 采取
防范跨站请求伪造的措施。
颁发短寿命承载令牌：令牌服务器 SHOULD 颁发短寿命（1 小时或
更短）的承载令牌，特别是在向运行于 Web 浏览器或其他可能
发生信息泄露环境中的客户端颁发令牌时。使用短寿命承载
令牌可以减少其泄露造成的影响。
颁发限定作用域的承载令牌：令牌服务器 SHOULD 颁发包含受众
限制的承载令牌，将其使用范围限定为预期的信赖方或一组
信赖方。
不要在页面 URL 中传递承载令牌：承载令牌 SHOULD NOT 在页面
URL 中传递（例如作为查询字符串参数）。相反，承载令牌
SHOULD 在采取了机密性措施的 HTTP 消息头或消息主体中传递。
浏览器、Web 服务器和其他软件可能无法充分保护浏览器历史、
Web 服务器日志和其他数据结构中的 URL。如果承载令牌在
页面 URL 中传递，攻击者可能能够从历史数据、日志或其他
未受保护的位置窃取它们。
Jones & Hardt 标准化进程 [第 13 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
6. IANA 考虑事项
6.1. OAuth 访问令牌类型注册
本规范在 [RFC6749] 定义的 OAuth Access Token Types 注册表中
注册以下访问令牌类型。
6.1.1. "Bearer" OAuth 访问令牌类型
类型名称：
Bearer
额外的令牌端点响应参数：
（无）
HTTP 认证方案：
Bearer
变更控制者：
IETF
规范文档：
RFC 6750
6.2. OAuth 扩展错误注册
本规范在 [RFC6749] 定义的 OAuth Extensions Error 注册表中
注册以下错误值。
6.2.1. "invalid_request" 错误值
错误名称：
invalid_request
错误使用位置：
资源访问错误响应
相关协议扩展：
Bearer 访问令牌类型
变更控制者：
IETF
规范文档：
RFC 6750
Jones & Hardt 标准化进程 [第 14 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
6.2.2. "invalid_token" 错误值
错误名称：
invalid_token
错误使用位置：
资源访问错误响应
相关协议扩展：
Bearer 访问令牌类型
变更控制者：
IETF
规范文档：
RFC 6750
6.2.3. "insufficient_scope" 错误值
错误名称：
insufficient_scope
错误使用位置：
资源访问错误响应
相关协议扩展：
Bearer 访问令牌类型
变更控制者：
IETF
规范文档：
RFC 6750
7. 参考文献
7.1. 规范性参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997 年 3 月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, 1999 年 1 月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, 1999 年 6 月。
Jones & Hardt 标准化进程 [第 15 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, 1999 年 6 月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2000 年 5 月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, 2005 年 1 月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, 2008 年 1 月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
2008 年 8 月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, 2008 年 5 月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
2011 年 4 月。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, 2012 年 10 月。
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986。
[W3C.REC-html401-19991224]
Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, 1999 年 12 月,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-webarch-20041215]
Jacobs, I. and N. Walsh, "Architecture of the World Wide
Web, Volume One", World Wide Web Consortium
Recommendation REC-webarch-20041215, 2004 年 12 月,
<http://www.w3.org/TR/2004/REC-webarch-20041215>.
Jones & Hardt 标准化进程 [第 16 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
7.2. 资料性参考文献
[HTTP-AUTH] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Work
in Progress, 2012 年 10 月。
[NIST800-63] Burr, W., Dodson, D., Newton, E., Perlner, R., Polk, T.,
Gupta, S., and E. Nabbus, "NIST Special Publication
800-63-1, INFORMATION SECURITY", 2011 年 12 月,
<http://csrc.nist.gov/publications/>.
[OMAP] Huff, J., Schlacht, D., Nadalin, A., Simmons, J.,
Rosenberg, P., Madsen, P., Ace, T., Rickelton-Abdi, C.,
and B. Boyer, "Online Multimedia Authorization Protocol:
An Industry Standard for Authorized Access to Internet
Multimedia Resources", 2012 年 4 月,
<http://www.oatc.us/Standards/Download.aspx>.
[OpenID.Messages]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
Mortimore, C., and E. Jay, "OpenID Connect Messages
1.0", 2012 年 6 月，<http://openid.net/specs/
openid-connect-messages-1_0.html>.
Jones & Hardt 标准化进程 [第 17 页]
RFC 6750 OAuth 2.0 承载令牌用法 2012 年 10 月
附录 A. 致谢
以下人员为本文档的初步版本作出了贡献：Blaine Cook (BT)、
Brian Eaton (Google)、Yaron Y. Goland (Microsoft)、Brent Goldman
(Facebook)、Raffi Krikorian (Twitter)、Luke Shepard (Facebook) 和
Allen Tom (Yahoo!)。其中的内容和概念是 OAuth 社区、Web
Resource Authorization Profiles (WRAP) 社区以及 OAuth 工作组的
成果。David Recordon 基于后来演进为 OAuth 2.0 [RFC6749] 的
规范早期草案，创建了本规范的一个初步版本。Michael B. Jones
随后使用 David 初步文档的若干部分创建了本规范的第一个版本
(00)，并编辑了所有后续版本。
OAuth 工作组有数十位非常活跃的贡献者，他们为本文档提出了
思路和措辞，包括 Michael Adams、Amanda Anganes、Andrew
Arnott、Derek Atkins、Dirk Balfanz、John Bradley、Brian
Campbell、Francisco Corella、Leah Culver、Bill de hOra、Breno
de Medeiros、Brian Ellin、Stephen Farrell、Igor Faynberg、George
Fletcher、Tim Freeman、Evan Gilbert、Yaron Y. Goland、Eran
Hammer、Thomas Hardjono、Dick Hardt、Justin Hart、Phil Hunt、John
Kemp、Chasen Le Hara、Barry Leiba、Amos Jeffries、Michael B. Jones、
Torsten Lodderstedt、Paul Madsen、Eve Maler、James Manger、Laurence
Miao、William J. Mills、Chuck Mortimore、Anthony Nadalin、Axel
Nennker、Mark Nottingham、David Recordon、Julian Reschke、Rob
Richards、Justin Richer、Peter Saint-Andre、Nat Sakimura、Rob Sayre、
Marius Scurtescu、Naitik Shah、Justin Smith、Christian Stuebner、
Jeremy Suriel、Doug Tangren、Paul Tarjan、Hannes Tschofenig、Franklin
Tse、Sean Turner、Paul Walker、Shane Weeden、Skylar Woodward 和
Zachary Zeltsan。
作者地址
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Dick Hardt
Independent
EMail: dick.hardt@gmail.com
URI: http://dickhardt.org/
Jones & Hardt 标准化进程 [第 18 页]