Oauth2-RFC6750翻译¶

转自: https://github.com/jeansfish/RFC6750.zh-cn

互联网工程任务组（IETF，Internet Engineering Task Force）
RFC：6750
淘汰：[5849][RFC5849]
类别：标准化过程
ISSN：2070-1721

M. Jones
Microsoft
D. Hardt
独立
2012年10月

OAuth 2.0授权框架：不记名令牌用法¶

摘要¶

本规范描述了如何在HTTP请求中使用不记名令牌访问受OAuth 2.0保护的资源。持有不记名令牌（“bearer”）的任何一方可以用它获得相关联的资源的访问权限（无需证明持有加密密钥）。为防止误操作，不记名令牌在存储和传输时需要被保护防止泄露。

本备忘录状态¶

这是一个互联网标准化过程文档。

本文档是互联网工程任务组（IETF）的作品。它代表了IETF社区的共识。它已接受公开审查并被互联网工程指导小组（IESG）批准公布。互联网标准的更多信息可在RFC5741的第2节找到。

可于http://www.rfc-editor.org/info/rfc6750获取有关本文档的当前状态、勘误表以及如何提供反馈的信息。

版权声明¶

本文档受BCP78和IETF信托有关IETF文档的法律条款 (http://trustee.ietf.org/license-info)的约束，自本文档发布之日起生效。请仔细查阅这些文件，因为它们描述了与本文档有关的权利和限制。从本文档中提取的代码组件必须按信托法律条款4.e节所述包含简化BSD许可证文本；并且按简化BSD许可证中所述不附带质量保证。

1 简介¶

OAuth使客户能够通过获取访问令牌，而不是直接使用资源所有者的凭据来访问受保护资源，访问令牌在“OAuth2.0授权框架”RFC6749中定义为“颁发给客户端的代表访问权限授权的字符串”。

访问令牌由授权服务器在资源所有者同意的情况下颁发给客户端。客户端使用访问令牌访问资源服务器托管的受保护资源。本规范描述了当OAuth访问令牌是不记名令牌时如何发起对受保护资源的请求。

本规范定义了采用传输层安全（TLS）RFC5246在HTTP/1.1上使用不记名令牌访问受保护资源。本规范强制实施和使用TLS；其他规范可以扩展本规范以使用其他协议。本规范尽管为使用来源于OAuth2.0授权RFC6749流程的访问令牌访问受OAuth保护的资源而设计，但实际上定义了一种通用的HTTP授权方法，可以用来自任何来源的不记名访问令牌访问那些不记名令牌保护的任何资源。不记名身份验证方案主要计划采用WWW-Authenticate和Authorization的HTTP头部作为服务器身份验证，但不排除其作为代理的身份验证使用。

1.1. 符号约定
1.2. 术语
1.3. 概述

1.1 符号约定¶

本文档中的关键词“必须”、“不能”、“必需的”、“要”、“不要”、“应该”、“不应该”、“推荐的”、“可以”以及“可选的”按RFC2119“用于在RFC中指示要求级别的关键字”所述的解释。

本规范使用RFC5234的扩展巴科斯-诺尔范式(ABNF)。此外，以下规则也包含在内：来自HTTP/1.1RFC2617的auth-param和auth-scheme和来自“统一资源标识符（URI）：通用语法”RFC3986的URI引用。

除非另有说明，所有协议参数的名称和值是大小写敏感的。

1.2 术语¶

不记名令牌

具有如下属性的安全令牌：持有该令牌（“bearer”）的任何一方可以以任何方式同持有它的任何其他一方可以的一样使用该令牌。使用不记名令牌不要求持有者证明其拥有加密密钥材料（所有权证明）。

所有其他术语如“OAuth 2.0授权框架”RFC6749中的定义。

1.3 概述¶

OAuth为客户端提供了一种代表资源所有者访问受保护资源的方法。在一般情况下，在客户端可以访问受保护的资源之前，它必须首先获得来自资源所有者的授权许可，然后用授权许可交换访问令牌。访问令牌代表了许可的范围、时效和授权许可批准的其他属性。客户端通过提交访问令牌给资源服务器访问受保护的资源。在某些情况下，客户端可以直接提交它自己的凭证给授权服务器以获得访问令牌，而不要必须先获得来自资源所有者的授权许可。

访问令牌提供了一种抽象，替换不同的授权结构（例如，用户名和密码，断言）以资源服务器理解的单个令牌。这种抽象使得能够颁发短时间段有效的访问令牌，也消除了资源服务器理解许多身份验证方案的需要。

     +--------+                               +---------------+
     |        |--(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 已验证身份的请求¶

本节定义了三种在资源请求中发送不记名令牌资源给资源服务器的方法。客户端不能在每次请求中使用超过一个方法传输令牌。

2.1. 授权请求头部字段
2.2. 表单编码的主体参数
2.3. URI查询参数

2.1 授权请求头部字段¶

当在由HTTP/1.1RFC2617定义的“Authorization”请求头部字段中发送访问令牌时，客户端使用“Bearer”身份验证方案来传输访问令牌。

例如：

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

此方案的“Authorization”头部字段的语法遵循[RFC2617]第2节定义的基本方案的用法。注意，如Basic一样，它不符合[RFC2617]1.2节中定义的一般语法，但与正在为HTTP1.1[HTTP-AUTH]{target="_blank"}开发的通用身份验证框架兼容，尽管它为反映现有部署不遵循其中描述的最佳实践。不记名凭证的语法如下：

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

客户端应该使用带有“Bearer”HTTP授权方案的“Authorization”请求头部字段发起带有不记名令牌的身份验证请求。资源服务器必须支持此方法。

2.2 表单编码的主体参数¶

当在HTTP请求实体主体中发送访问令牌时，客户端采用“access_token”参数向请求主体中添加访问令牌。客户端不能使用此方法，除非符合下列所有条件：

HTTP请求的实体头部含有设置为“application/x-www-form-urlencoded”的“Content-Type”头部字段。
实体主体遵循HTML4.01[W3C.REC-html401-19991224]{target="_blank"}定义的“application/x-www-form-urlencoded”内容类型的编码要求。
HTTP请求实体主体是单一的部分。
在实体主体中编码的内容必须完全由ASCII[USASCII]{target="_blank"}字符组成。
HTTP请求方法是请求主体定义为其定义的语法。尤其是，这意味着“GET”方法不能被使用。

实体主体可以含有其他的请求特定的参数，在这种情况下，“access_token”参数必须使用“&”字符（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”方法不应该被使用，除非在参与的浏览器没有对“Authorization”请求头部字段的访问权限的应用程序上下文中。资源服务器可以支持这种方法。

2.3 URI查询参数¶

当在HTTP请求URI中发送访问令牌时，客户端采用“access_token”参数，向“统一资源标示符（URI）：通用语法”RFC3986定义的请求URI查询部分添加访问令牌。

例如，客户端采用传输层安全发起如下的HTTP请求：

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

HTTP请求URI查询可以含有其他的请求特定的参数，在这种情况下，“access_token”参数必须使用“&”字符（ASCII码38）正确的与请求特定的参数分隔开。

例如：

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

使用URI查询参数方法的客户端也应该发送含有“no-store”选项的Cache-Control头。针对这些请求的服务器成功（2XX状态）响应应该含有带有“private”选项的Cache-Control头。

由于与URI方法（参见第5节）相关的安全弱点，包括含有访问令牌的URI会被记录的高度可能性，它不应该被使用，除非不能在“Authorization”请求头部字段或HTTP请求实体主体中传输访问令牌。资源服务器可以支持这种方法。

该方法包含在当前使用的文档中；但它的使用是不被推荐的，因为它的安全缺陷（参见第5节），也因为它使用了保留的查询参数名称，按照“万维网架构，卷一”[W3C.REC-webarch-20041215]，这是违反URI命名空间最佳实践的。

3 WWW-Authenticate响应头部字段¶

如果受保护资源的请求不含有身份验证凭据或不包含能够访问受保护资源的访问令牌，资源服务器必须包含HTTP“WWW-Authenticate”响应头部字段；对于其他条件也可以在响应中包含它。“WWW-Authenticate”头部字段使用由HTTP/1.1RFC2617定义的框架。

本规范定义的所有要求必须使用认证方案值“Bearer”。此方案必须被一个或多个认证参数值遵循。本规范使用或定义的认证参数属性如下。其他认证参数属性也可以被使用。

“realm”属性可以被包含来指示以HTTP/1.1 RFC2617所述的方式保护的范围。“realm”属性不能出现一次以上。

“scope”属性在[RFC6749]3.3节中定义。“scope”属性是一个空格分隔的大小写敏感的范围值的列表，指示访问令牌访问请求的资源所需的范围。“scope”值是实现定义的；它们没有集中的注册表；允许的值由授权服务器定义。“scope”值的顺序是无关紧要的。在某些情况下，当请求具有充分范围使用受保护资源的新的访问令牌时“scope”值会被使用。“scope”属性的使用是可选的。“scope”属性不能出现一次以上。“scope”值计划供程序使用，并不打算显示给最终用户。

以下是两个scope值的例子；它们从OpenID Connect[OpenID.Messages]{target="_blank"}和开放身份验证技术委员会（OATC）在线多媒体授权协议[OMAP]{target="_blank"}OAuth2.0用例得到，分别是：

    scope="openid profile email"
    scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"

如果受保护资源的请求包含访问令牌但身份验证失败，资源服务器应包含“error”属性为客户端提供访问请求被拒绝的原因。参数值在3.1节中描述。另外，资源服务器可以包含“error_description”属性，为开发者提供人类可读的解释但不意味着显示给最终用户。它也可以含有具有绝对URI的“error_uri”属性，标识一个解释该错误的人类可读的网页。“error”、“error_description”、“error_uri”属性不能出现超过一次。

“scope”属性的值（[RFC6749]附录A.4指定）不能包含%x21/%x23-5B /%x5D-7E集合之外的字符来表示范围值且以%/x20在范围值之间分隔。“error”和“error_description”属性的值（RFC6749附录A.7和A.8指定）不能包含%x20-21/%x23-5B/%x5D集合之外的字符。“error_uri”属性的值（[RFC6749]附录A.9指定）必须符合URI引用的语法，因此不能包含%x21/%x23-5B/%x5D-7E集合之外的字符。

例如，在没有进行身份验证的受保护资源请求的响应中：

    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: Bearer realm="example"

以及在使用过期的访问令牌尝试身份验证的受保护资源请求的响应中：

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: Bearer realm="example",
                       error="invalid_token",
                       error_description="The access token expired"

3.1. 错误代码

3.1 错误代码¶

当请求失败时，资源服务器使用相应的HTTP状态代码（通常，400、401、403或405）响应并在响应中包含下列错误代码之一：

invalid_request 请求缺少必要的参数，包含不支持的参数或参数值，重复相同的参数，使用一种以上的方法包含访问令牌，或者其他错误。资源服务器应该响应HTTP 400（错误请求）状态代码。
invalid_token 所提供的访问令牌已过期，被撤销，不符合格式或因其他原因而无效。资源应该响应HTTP 401（未授权）状态代码。客户端可以请求新的访问令牌并重试受保护资源的请求。
insufficient_scope 请求需要比访问令牌所提供的更高的权限。资源服务器应该响应HTTP 403（禁止）状态码并且可以包含具有访问受保护资源所需的范围的“scope”属性。

如果该请求缺少任何身份验证信息（例如，客户端不知道需要身份验证或者试图使用不支持的身份验证方法），资源服务器不应该包含错误代码或其它错误信息。

例如：

    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: Bearer realm="example"

4 访问令牌响应示例¶

通常，不记名令牌作为OAuth 2.0RFC6749访问令牌响应的一部分被返回给客户端。一个这样的响应的例子是：

    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. 安全威胁
5.2. 威胁缓解
5.3. 建议一览

5.1 安全威胁¶

以下列表显示了针对采用了某些形式的令牌的协议的几种常见威胁。这个威胁列表是基于NIST特别发布800-63[NIST800-63]{target="_blank"}的。由于本文档在OAuth 2.0授权规范RFC6749上建立，我们排除了在那里或相关的文档中已描述的威胁的讨论。

令牌伪造/修改：攻击者可能生成一个假的令牌或修改现有令牌的令牌内容（如身份验证信息或属性声明），造成资源服务器许可不正确的访问权限给客户端。例如，攻击者可能修改令牌延长有效期限；恶意客户端可能修改断言以获取他们不应该能够查看的信息的访问权限。

令牌泄露：令牌可能包含身份验证信息和含有敏感信息的属性声明。

令牌重定向：攻击者使用由A资源服务器生成的用于消费的令牌来访问B资源服务器，并且该B资源服务器错误地认为该令牌是适用的。

令牌重放：攻击者试图使用在过去已经在资源服务器上使用的令牌。

5.2 威胁缓解¶

大范围的威胁可以通过采用数字签名或消息认证码（MAC）保护令牌内容来缓解。另外，不记名令牌可以包含授权信息的引用，而不是直接编码该信息。对于攻击者这些引用不可能被猜测；使用引用可能需要服务器和令牌颁发者之间额外的交互来解析对授权信息的引用。这种交互的机制未由本规范定义。

本文档不指定令牌的编码或内容；因此，关于确保令牌完整性保护的措施的详细推荐在本文档范围之外。令牌完整性保护必须充分防止令牌被修改。

为处理令牌重定向，授权服务器在令牌中包含预期的接收者（听众）——通常是单个资源服务器（或资源服务器列表）——是很重要的。限制令牌在特定范围中使用也是推荐的。

授权服务器必须实施TLS。应当实施哪个（些）版本随着时间变化，且会依赖于实现时的普遍部署和已知的安全弱点。在本规范撰写时，TLS 1.2版RFC5246是最新的版本，但它具有非常有限的实际部署并且可能在实现工具箱中还未准备好可用。TLS 1.0版RFC2246是部署最广泛的版本并会提供最广泛的互操作性。

为了保护令牌避免泄露，采用具有提供机密性和完整性保护套件的TLS RFC5246机密性保护必须被应用。这要求在客户端和授权服务器之间的通信交互，以及运用机密性和完整性保护的客户端和资源服务器之间的交互。由于TLS由本规范强制实施和使用，它是防止在通信信道上令牌泄露的首选方法。对于那些客户端被阻止观察令牌内容的情况，除TLS保护的使用之外令牌加密必须被应用。作为针对令牌泄露的进一步防御，当发起对受保护资源的请求时客户端必须验证TLS证书链，包括检查证书吊销列表（CRL）RFC5280。

Cookies通常是明文传输的。因此，任何包含在它们中的信息都有泄露的风险。因此，不记名令牌不能存储在可能以明文传送的cookies中。关于cookies的安全考量参阅“HTTP状态管理机制”RFC6265。

在一些部署中，包括那些采用负载均衡部署，到资源服务器的TLS连接在提供资源的实际服务器前终止。这可能导致令牌在TLS连接终止处的前端服务器和提供资源的后端服务器之间未受保护。在这种部署中，足够的措施必须被使用以确保在前端和后端服务器之间的令牌机密性；令牌加密是一种这样的可能手段。

为处理令牌捕获和重放，做出了如下推荐：首先，令牌的生命周期必须被限制；一种达到这一目标的方法是通过放置有效时间字段在令牌的受保护的部分内。请注意，采用短暂（一小时或更少）的令牌减少它们被泄露之后的影响。其次，客户端和授权服务器之间以及客户端和资源服务器之间的交互的机密性保护必须被应用。作为结果，沿着通信路径没有窃听者能够观察到令牌交换。因此，这样的路径上对手无法重放令牌。此外，当提交令牌给资源服务器时，客户端必须按照“TLS上的HTTP”[RFC2818]3.1节验证资源服务器的身份。注意当发起对受保护资源的这些请求时客户端必须验证TLS证书链。提交令牌给未经过身份验证或未授权的资源服务器或者验证证书链失败会允许对手窃取令牌并获得对受保护资源的未授权的访问权限。

5.3 建议一览¶

保护不记名令牌：

客户端实现必须确保不记名令牌不被泄露给计划外的一方，因为他们会能够使用它们来获得对受保护资源的访问权限。这是在使用不记名令牌时的首要安全考量，并且是下列所有更多具体的推荐的基础。

验证TLS证书链：

当发起对受保护资源的请求时，客户端必须验证TLS证书链。不这样做可以使得DNS劫持攻击能够窃取令牌并获得计划外的访问权限。

总是使用TLS（https）：

当使用不记名令牌发起请求时客户端必须总是使用TLS RFC5246（https）或同等的传输安全。不这样做会暴露令牌给大量的能给攻击者计划外的访问权限的攻击。

不要在cookies中存储不记名令牌：

实现不能在可能被以明文发送（这是cookies的默认传输模式）的cookies中存储不记名令牌。在cookies中存储不记名令牌的实现必须采取应对跨站请求伪造的防范措施。

发行短暂的不记名令牌：

令牌服务器应该颁发短暂的（一小时或更少）不记名令牌，尤其是当颁发令牌给在web浏览器或其他可能发生信息泄露的环境中运行的客户端时。使用短暂的不记名令牌可以减少它们被泄露后的影响。

发行有范围的不记名令牌：

令牌服务器应该颁发含有受众限制的不记名令牌，确定其使用的范围为计划的依赖方或依赖方集合。

不要在网页URL中传送不记名令牌：

不记名令牌不应该在网页的URL中传送（例如，作为查询字符串参数）。相反，不记名令牌应该在HTTP消息头部或采取保密性措施的消息主体中传送。浏览器，Web服务器和其他软件可能无法在浏览器历史记录、Web服务器日志和其他数据结构中充分保证URL安全。如果不记名令牌在页面URL中传送，攻击者可能能够从历史数据、日志或者其他不安全的地方窃取它们。

6 IANA考量¶

6.1 OAuth访问令牌类型注册¶

本规范在于RFC6749中定义的OAuth访问令牌类型注册表中注册下述访问令牌类型。

6.1.1. “Bearer”OAuth访问令牌类型

6.1.1 “Bearer”OAuth访问令牌类型¶

Type name：

Bearer - Additional Token Endpoint Response Parameters:

(none) - HTTP Authentication Scheme(s):

Bearer - Change controller：

IETF - Specification document(s):

RFC 6750

6.2 OAuth扩展错误注册¶

本规范在于RFC6749中定义的OAuth扩展错误注册表中注册下述错误值。

6.2.1. “invalid_request”错误值
6.2.2. “invalid_token”错误值
6.2.3. “insufficient_scope”错误值

6.2.1 “invalid_request”错误值¶

Error name:

invalid_request

Error usage location:

Resource access error response

Related protocol extension:

Bearer access token type

Change controller:

IETF

Specification document(s):

RFC 6750

6.2.2 “invalid_token”错误值¶

Error name:

invalid_token

Error usage location:

Resource access error response

Related protocol extension:

Bearer access token type

Change controller:

IETF

Specification document(s):

RFC 6750

6.2.3 “insufficient_scope”错误值¶

Error name:

insufficient_scope

Error usage location:

Resource access error response

Related protocol extension:

Bearer access token type

Change controller:

IETF

Specification document(s):

RFC 6750

7 参考文献¶

7.1 规范性引用文献¶

RFC2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC2246 Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2616]{target="_blank"} Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
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, June 1999.
RFC2818 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
RFC3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
RFC5234 Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
RFC5246 Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
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, May 2008.
RFC6265 Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
RFC6749 Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
[USASCII]{target="_blank"} American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[W3C.REC-html401-19991224]{target="_blank"} Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, http://www.w3.org/TR/1999/REC-html401-19991224.
[W3C.REC-webarch-20041215]{target="_blank"} Jacobs, I. and N. Walsh, "Architecture of the World Wide Web, Volume One", World Wide Web Consortium Recommendation REC-webarch-20041215, December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215.

7.2 参考性引用文献¶

[HTTP-AUTH]{target="_blank"} Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", Work in Progress, October 2012.
[NIST800-63]{target="_blank"} Burr, W., Dodson, D., Newton, E., Perlner, R., Polk, T., Gupta, S., and E. Nabbus, "NIST Special Publication 800-63-1, INFORMATION SECURITY", December 2011, http://csrc.nist.gov/publications/.
[OMAP]{target="_blank"} 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", April 2012, http://www.oatc.us/Standards/Download.aspx.
[OpenID.Messages]{target="_blank"} Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", June 2012, http://openid.net/specs/openid-connect-messages-1_0.html.

附录A 致谢¶

以下人士贡献了本文档的初步版本：Blaine Cook(BT), Brian Eaton(Google), Yaron Y. Goland(Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), Luke Shepard(Facebook), and Allen Tom(Yahoo!)。其中的内容和概念是OAuth社区，网络资源授权文档（WRAP）社区和OAuth的工作组的作品。David Recordon在包含进OAuth2.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, and Zachary Zeltsan.

作者地址

Michael B. Jones 微软

电子邮件：mbj@microsoft.com URI：http://self-issued.info/

Dick Hardt 独立

电子邮件：dick.hardt @ gmail.com URI：http://dickhardt.org/

最后更新: 2023年2月23日
创建日期: 2023年2月23日