OAuth 2.0 RFC 框架中文

Internet Engineering Task Force (IETF) D. Hardt, Ed.
Request for Comments: 6749 Microsoft
Obsoletes: 5849 October 2012
Category: Standards Track
ISSN: 2070-1721

OAuth 2.0授权框架

文摘

OAuth 2.0授权框架允许第三方
应用程序获得有限的访问HTTP服务,要么
代表一个资源所有者通过编排一个批准的交互
资源所有者之间的HTTP服务,或通过允许
第三方应用程序获得代表自己的访问。这
规范取代和废止了OAuth 1.0协议描述
在RFC 5849。

这份备忘录的地位

这是一个互联网标准跟踪文档。

本文档是因特网工程任务组的一个产品
(IETF)。它代表了IETF社会的共识。它有
收到公众审查和批准出版的
互联网工程指导组(IESG)。进一步的信息
因特网标准可在RFC 5741的第2部分。

本文档的当前状态的信息,任何勘误表,
以及如何在可能获得提供反馈
http://www.rfc-editor.org/info/rfc6749。

本文以BCP 78和IETF信托的法律
IETF文档相关的条款
(http://trustee.ietf.org/license-info)之日起生效
本文的发表。请检查这些文件
小心,因为他们描述你的权利和限制
这个文档。从这个文档必须提取的代码组件
包括简化BSD许可文本如第四节所述。 e的
信托法律规定和不提供保修
描述的简化的BSD许可。

(第1页)

表的内容

1。介绍.................................................... 4
1.1。角色...................................................... 6
1.2。协议流.............................................. 7
1.3。授权授予........................................ 8
1.3.1。授权代码.................................. 8
1.3.2。隐式............................................ 8
1.3.3。资源所有者密码凭据................. 9
1.3.4。客户端凭证.................................. 9
1.4。访问令牌.............................................. 10
1.5。刷新令牌............................................. 10
1.6。 TLS版本............................................... 12
1.7。 HTTP重定向......................................... 12
1.8。互操作性.......................................... 12
1.9。符号约定.................................... 13
2。客户端注册............................................ 13
2.1。客户机类型.............................................. 14
2.2。客户端标识符......................................... 15
2.3。客户端身份验证..................................... 16
2.3.1。客户密码.................................... 16
2.3.2。其他身份验证方法....................... 17
2.4。未注册客户...................................... 17
3所示。协议端点............................................. 18
3.1。授权端点.................................... 18
3.1.1。响应类型...................................... 19
3.1.2。重定向端点............................... 19
3.2。令牌端点............................................ 21
3.2.1之上。客户端身份验证.............................. 22
3.3。访问令牌范围........................................ 23
4所示。获得授权........................................ 23
4.1。授权代码授予.................................. 24
以下4.4.1。授权请求.............................. 25
4.1.2。授权响应............................. 26
4.1.3。访问令牌请求............................... 29
4.1.4。访问令牌响应.............................. 30
4.2。隐式授予............................................ 31
4.2.1。准备授权请求.............................. 33
4.2.2。访问令牌响应.............................. 35
4.3。资源所有者密码凭据格兰特................. 37
4.3.1。授权请求和响应................. 39
4.3.2。访问令牌请求............................... 39
4.3.3。访问令牌响应.............................. 40
4.4。客户端证书授予.................................. 40
4.1.1。授权请求和响应................. 41
10/24/11。访问令牌请求............................... 41
4.4.3。访问令牌响应.............................. 42
4.5。扩展授予.......................................... 42

(第2页)

5。发行一个访问令牌........................................ 43
5.1。成功的响应....................................... 43
5.2。错误响应............................................ 45
6。刷新一个访问令牌..................................... 47岁
7所示。访问受保护资源.................................. 48
7.1。访问令牌类型........................................ 49
7.2。错误响应............................................ 49
8。可扩展性.................................................. 50
8.1。定义访问令牌类型............................... 50
8.2。定义新的端点参数.......................... 50
8.3。定义新的授权授予类型.................... 51
8.4。定义新的授权端点响应类型........ 51
8.5。定义额外的错误代码........................... 51
9。本机应用程序............................................ 52
10。安全考虑....................................... 53
10.1。客户端身份验证.................................... 53
10.2。客户端模拟..................................... 54
10.3。访问令牌............................................ 55
10.4。刷新令牌........................................... 55
10.5。授权码...................................... 56
10.6。授权代码重定向URI操纵.......... 56
10.7。资源所有者密码凭证...................... 57
10.8。请求保密.................................. 58
10.9。确保端点真实性........................... 58岁
10.10。 Credentials-Guessing攻击............................ 58
10.11。网络钓鱼攻击........................................ 58
10.12。跨站点请求伪造.............................. 59
10.13。 “点击劫持”............................................ 60
10.14。代码注入和输入验证..................... 60
10.15。开放的转向器........................................ 60
10.16。访问令牌来冒充资源的滥用
在61年隐流..................................所有者
11。 IANA考虑........................................... 62
11.1。 OAuth访问令牌类型注册........................ 62
11.1.1。注册模板............................. 62
11.2。 OAuth参数注册................................ 63
11.2.1。注册模板............................. 63
11.2.2。初始注册表内容......................... 64
11.3。 OAuth授权端点响应类型注册..... 66
11.3.1。注册模板............................. 66
11.3.2。初始注册表内容......................... 67
11.4。 OAuth扩展注册表错误.......................... 67
11.4.1。注册模板............................. 68
12。引用.................................................... 68
12.1。引用标准..................................... 68
12.2。信息参考................................... 70

(第3页)

附录a .增强Backus-Naur形式(ABNF)语法.............. 71
. 1。 “client_id”语法........................................ 71
由信用证。 “client_secret”语法.................................... 71
出具。 “response_type”语法.................................... 71
各。 “范围”语法............................................ 72
本。 “状态”语法............................................ 72
要求寄出。 “redirect_uri”语法..................................... 72
A.7。 “错误”语法............................................ 72
如系。 “error_description”语法................................ 72
A.9。 “error_uri”语法........................................ 72
A.10。 “grant_type”语法....................................... 73
A.11。 “代码”语法............................................. 73
A.12。 “access_token”语法..................................... 73
A.13。 “token_type”语法....................................... 73
A.14。 “expires_in”语法....................................... 73
所以。 “用户名”语法......................................... 73
A.16。 “密码”语法......................................... 73
A.17。 “refresh_token”语法.................................... 74
A.18。端点参数语法................................. 74
附录b .使用应用程序/ x-www-form-urlencoded媒体类型…74
附录c .确认...................................... 75

1。介绍

在传统的客户机-服务器身份验证模型中,客户端
请求一个资源(受保护资源)限制出入
服务器使用的资源所有者与服务器进行身份验证
凭证。为了提供第三方应用访问权
受限制的资源,资源所有者凭证与股票
第三方。这就产生了一些问题和局限性:

第三方应用程序都需要存储资源
主人的凭证以备将来之用,通常是一个密码
以明文。

o服务器必须支持密码身份验证,尽管
固有的安全漏洞的密码。

第三方应用程序获得阿过于广泛的访问资源
主人的受保护资源,让资源所有者没有任何
限制时间或访问能力有限的子集
资源。

o资源所有者不能撤销访问一个单独的第三方
没有撤销访问所有第三方,必须这样做
改变第三方的密码。

(第4页)

o妥协妥协的任何第三方应用程序的结果
终端用户的密码和所有的数据保护
密码。

通过引入一个授权层OAuth解决这些问题
和分离的角色从资源的客户端
所有者。 OAuth的客户机请求对资源的访问控制
通过主办的资源所有者和资源服务器,和
发布了一组不同的证书比资源
所有者。

而不是使用资源所有者凭证访问受保护的
资源,客户将获得一个访问令牌,一个字符串表示
具体范围,一生中,和其他属性的访问。访问令牌
发给第三方客户授权服务器的
资源所有者的许可。客户端使用访问令牌
主持资源服务器访问受保护的资源。

例如,一个用户(资源所有者)可以批准印刷
服务(客户端)访问她的保护存储在一张照片——照片
资源共享服务(服务器),没有她的用户名和共享
密码与印刷服务。相反,她验证
直接与服务器可信的照片分享服务
(授权服务器)印刷服务代表团——的问题
特定的凭证(访问令牌)。

这个规范是专为使用HTTP([RFC2616])。的
使用OAuth对HTTP的范围以外的任何协议。

OAuth 1.0协议([RFC5849]),作为一个信息发布
文档,是一个小的结果特别社区的努力。这
标准跟踪规范基于OAuth 1.0部署
经验,以及额外的用例和可扩展性
需求来自更广泛的IETF社区。 OAuth 2.0
协议是对OAuth 1.0不向后兼容的。两个版本
可能网络上共存,实现可以选择吗
同时支持。然而,它是该规范的目的
新的实现都支持OAuth 2.0规定
文档和使用OAuth 1.0支持现有的
部署。 OAuth 2.0协议股票很少实现
OAuth 1.0协议的细节。实现人员熟悉
OAuth 1.0应该方法这个文档没有任何假设
它的结构和细节。

(第5页)

1.1。角色

OAuth定义了四个角色:

资源所有者
一个实体的能力授予访问受保护的资源。
当资源所有者是一个人,它被称为一个
终端用户。

资源服务器
服务器托管受保护的资源,能够接受
和应对使用访问受保护的资源请求令牌。

客户端
应用程序使受保护的资源请求代表
资源所有者和授权。 “客户”一词
没有暗示任何特定的实现特征(例如,
应用程序在服务器上执行,是否一个桌面或其他
设备)。

授权服务器
服务器发行成功后客户端访问令牌
验证资源所有者和获得授权。

授权服务器之间的交互和资源服务器
超出了本规范的范围。授权服务器
可能是相同的服务器资源服务器或一个单独的实体。
一个授权服务器可以访问令牌所接受
多个资源服务器。

(第6页)

1.2。协议流

+ - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - +
| | -(一)-授权请求- > | |资源
| | | |
| | < -格兰特(B)授权- - - - - - | |
| | + - - - - - - - - - - - - - - - - - - +
| |
| | + - - - - - - - - - - - - - - - - - - +
| |——(C)授权格兰特- - > | |授权
服务器客户端| | | |
| | < -访问令牌(D)- - - - - - - - - - - - - - - | |
| | + - - - - - - - - - - - - - - - - - - +
| |
| | + - - - - - - - - - - - - - - - - - - +
| | -访问令牌(E)- - - - - - - - - - - - - - > | |资源
| | | |服务器
| | < -(F)- - -受保护的资源- - - - - - | |
+ - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - +

图1:抽象的协议流程

抽象的OAuth 2.0流程见图1描述了
四个角色之间的交互,包括以下步骤:

(一)客户端请求资源所有者的授权。的
授权请求可以直接向资源所有者
(如图所示),或者最好是间接通过授权
服务器作为中介。

(B)客户端接收到一个授权格兰特,这是一个
证书代表资源所有者的授权,
格兰特表示使用四种类型中定义
格兰特规范或使用一个扩展类型。的
授权批准类型取决于所使用的方法
客户端请求授权和支持的类型
授权服务器。

(C)的客户端请求的访问令牌验证
授权服务器和授权授予。

(D)授权服务器对客户端进行身份验证和验证
授权批准,如果有效,问题一个访问令牌。

(第7页)

(E)的客户端请求受保护的资源资源
服务器进行身份验证和访问令牌。

(F)的资源服务器验证访问令牌,如果有效,
服务请求。

客户的首选方法获得授权批准
从资源所有者(步骤(A)和(B)中描述)是使用
授权服务器作为中介,即见
图3在4.1节。

1.3。授权批准

一个表示资源的授权拨款凭证
所有者的授权使用的(访问受保护的资源)
客户获得一个访问令牌。这个规范定义了四个
格兰特类型——授权代码、隐式资源所有者密码
凭据和客户端凭据,以及可扩展性
机制来定义额外的类型。

1.3.1。授权代码

授权代码通过使用授权服务器
作为一个客户端和资源所有者之间的媒介。而不是
直接从资源所有者请求授权,客户端
指导资源所有者(通过其授权服务器
用户代理定义在[RFC2616]),进而指导
资源所有者回到客户端授权代码。

之前指挥的资源所有者回客户机
授权码,授权服务器进行身份验证
资源所有者和获得授权。因为资源所有者
只有认证与授权服务器,资源
主人的凭证没有与客户共享。

授权代码提供了一些重要的安全利益,
如对客户机进行身份验证的能力,以及
传播给你的客户,而不是直接访问令牌
它通过资源所有者的用户代理和可能
暴露在其他人,包括资源所有者。

1.3.2。隐式的

隐式格兰特是一个简化的授权代码流优化
为客户实现在浏览器中使用的脚本语言
JavaScript。在隐式流,而不是发布客户端
一个授权代码,直接客户端发出一个访问令牌

[8]页

(如资源所有者授权的结果)。格兰特的类型
是隐式的,没有中间的凭证(如授权
代码)发行(后来用于获得一个访问令牌)。

当发出一个访问令牌在隐式授予流
授权服务器不验证客户端。在一些
情况下,客户端可以验证身份通过重定向URI
用于传递客户机的访问令牌。访问令牌可能
受到资源所有者或其他应用程序访问
资源所有者的用户代理。

隐式授予改进的响应性和效率
客户(如客户端作为一个浏览器应用程序实现),
因为它减少了往返的数量要求获得一个
访问令牌。然而,这需权衡便利
使用隐式授予的安全影响,如这些
10.3和10.16中描述的部分,特别是当
授权代码授予类型是可用的。

1.3.3。资源所有者密码凭据

资源所有者(即密码凭据。用户名和密码)
可以直接使用作为一个授权拨款获得一个访问吗
令牌。凭证时应只用于有高
资源所有者和客户之间的信任程度(如。 ,
客户是设备的一部分操作系统或一个高度特权
应用程序),当其他授权授予类型
(如授权代码)。

尽管这种格兰特需要直接的客户端访问
资源所有者凭证,资源所有者凭证使用
单个请求和交换一个访问令牌。这
格兰特类型可以消除客户端存储的需求
资源所有者凭证以备将来之用,通过交换
凭证与长寿的访问令牌和刷新令牌。

1.3.4。客户端凭证

客户端凭证(或其他形式的客户端身份验证)
作为一个授权批准授权范围时
局限于受保护资源的控制下客户,
与授权或受保护资源之前安排
服务器。客户端凭证作为授权批准
通常当客户机代理代表其自己的(客户端
资源所有者)或者是请求访问保护
基于授权之前安排与资源
授权服务器。

(第9页)

1.4。访问令牌

访问令牌凭证用于访问受保护的资源。一个
访问令牌代表一个授权发布的是一个字符串
客户端。字符串通常是不透明的给客户端。令牌
代表具体范围和持续时间的访问,获得的
资源所有者和执行由资源服务器和授权
服务器。

令牌可能表示一个标识符用于检索的授权
信息或独立性的授权信息
可核实的方式(即。 ,一个令牌和一个字符串组成的一些数据
签名)。额外的身份验证凭证,超越
本规范的范围,可能需要为了
客户端使用一个令牌。

访问令牌提供了一个抽象层,更换不同
(如授权结构。 ,用一个用户名和密码)
令牌可以理解的资源服务器。这种抽象使
发行访问令牌的限制比授权拨款
用于获得它们,以及消除资源服务器的需要
了解各种身份验证方法。

访问令牌可以有不同的格式、结构和方法
利用(如。基于资源,加密属性)
服务器安全需求。访问令牌和属性
方法用于访问受保护的资源超出了范围
这个规范和定义的同伴规范等
[RFC6750]。

1.5。刷新令牌

刷新令牌是凭据用于获取访问令牌。刷新
令牌发行授权服务器和客户端
用于获得一个新的访问令牌时,当前的访问令牌
成为无效或过期,或获得额外的访问令牌
与相同或更窄的范围(访问令牌可能会更短
生命周期和更少的权限授权的资源
所有者)。发行一个刷新令牌是可选的自由裁量权
授权服务器。如果授权服务器刷新的问题
令牌,包括当发出一个访问令牌(即。步骤(D)
图1)。

刷新令牌是一个字符串代表授权授予
客户端资源所有者。字符串通常是不透明的
客户端。令牌代表一个标识符用于检索

(第10页)

授权信息。与访问令牌,刷新令牌
只适用与授权服务器和永远不会发送
资源服务器。

图2:刷新过期访问令牌

流程如图2所示,包括以下步骤:

(一)客户端请求一个访问令牌通过身份验证
授权服务器和授权授予。

(B)的授权服务器对客户端进行身份验证和验证
授权批准,如果有效,问题一个访问令牌
和一个刷新令牌。

(C)客户端是一个受保护的资源请求的资源
服务器访问令牌。

(D)资源服务器验证访问令牌,如果有效,
服务请求。

(E)步骤(C)和(D)重复访问令牌过期前。如果
客户知道访问令牌过期,就跳到步骤(G);
否则,它使另一个受保护的资源请求。

(F)由于访问令牌是无效的,资源服务器返回
一个无效的标记错误。

(11页)

(G)的客户端请求一个新的访问令牌验证
授权服务器和刷新令牌。的
客户机身份验证需求是基于客户类型
和授权服务器上的政策。

(H)授权服务器对客户端进行身份验证和验证
刷新令牌,如果有效,问题一个新的访问令牌(,
可选地,一个新的刷新令牌)。

步骤(C)、(D)(E)和(F)超出了这个范围
规范,第7节中描述。

1.6。 TLS版本

当传输层安全性(TLS)
规范,适当的版本(或TLS版本)将有所不同
随着时间的推移,基于广泛的部署和安全
漏洞。在撰写本文时,TLS 1.2版
(RFC5246)是最新版本,但有一个非常有限的
部署基础和可能不是现成的
实现。 TLS 1.0版本(RFC2246)是最广泛的
部署版本和将提供最广泛的互操作性。

实现也可以支持其他传输层安全性
机制,满足安全需求。

1.7。 HTTP重定向

这种规范使得广泛使用HTTP重定向,在其中
客户端或服务器引导资源所有者的授权
切换到另一个目的地。虽然在这个例子
规范的使用HTTP 302状态码,其他
方法可以通过用户代理来完成这个重定向
允许,被认为是一个实现细节。

1.8。互操作性

OAuth 2.0提供了丰富的和良好定义的授权框架
安全属性。然而,作为一个发达和高度可扩展的
和许多可选组件框架,就其本身而言,这个
规范是可能产生广泛的non-interoperable
实现。

此外,该规范留下一些所需的组件
部分或全部未定义(例如、客户登记,
授权服务器功能,端点发现)。没有

(第12页)

这些组件,客户必须手动和特别
针对特定的授权服务器和资源配置
服务器以进行互操作。

这个框架的目的是明确的预期,未来
将定义的概要文件和扩展的必要工作
实现完全的网络级的互操作性。

1.9。符号约定

关键词“必须”、“不能”、“需要”、“应当”,“不得”,
“应该”、“不应该”,“推荐”、“可能”和“可选的”
规范中描述将被解释为[RFC2119]。

该规范使用增强Backus-Naur形式(ABNF)
符号(RFC5234)。此外,规则uri引用
包括从“统一资源标识符(URI):通用语法”
[RFC3986]。

一些与安全相关的术语是被理解的
定义在[RFC4949]。这些条款包括,但不限于,
“攻击”、“身份验证”、“授权”、“证书”,
“保密”、“凭证”、“加密”,“身份”、“符号”,
“签名”、“信任”、“验证”和“确认”。

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

2。客户端注册

在初始协议之前,客户端注册的
授权服务器。客户端注册的方式
与授权服务器超出了这个范围
与HTML规范但通常涉及最终用户交互
注册表单。

客户端注册不需要之间的直接交互
客户端和授权服务器。当支持的
授权服务器,登记可以依靠其他方式
建立信任和获得所需的客户属性
(如。重定向的URI,客户类型)。例如,可以注册
完成使用自办发行或third-party-issued断言,
或由授权服务器执行客户端发现使用
可信的渠道。

(13页)

当注册客户端,客户端开发者应当:

o指定客户端类型如2.1节所述,

o提供客户重定向uri 3.1.2节中描述,
和

o包括授权服务器所需的任何其他信息
(如。、应用程序名称、网站描述,标志形象,
接受法律条款)。

2.1。客户端类型

OAuth定义了两个客户机类型,基于他们的能力
安全地进行身份验证与授权服务器(即。 ,能力
维护客户的保密资质):

保密
客户维护的机密性的能力
凭证(如。一个安全的服务器上,客户端实现
限制访问客户端凭据),或安全的能力
客户端身份验证使用其他手段。

公共
客户无法维护的保密性
凭证(如。 ,客户使用的设备上执行
资源所有者,比如安装本机应用程序或web
基于浏览器的应用程序),无法获得客户
身份验证通过其他手段。

客户名称是基于授权服务器的类型
安全认证和可接受风险的定义
水平的客户端凭据。授权服务器不应该
对客户端类型做出假设。

客户端可以实现分布式的组件,
与不同的客户类型和安全上下文(例如 ,一个
分布式客户端与一个机密的基于服务器的组件
和公众基于浏览器的组件)。如果授权服务器
不为这类客户提供支持或不提供
指导对他们的注册,客户应该
每个组件注册为一个单独的客户端。

(14页)

这个规范已经围绕以下客户
配置文件:

web应用程序
一个web应用程序是一个机密客户机上运行一个web
服务器。资源所有者访问客户端通过一个HTML用户
界面中呈现一个用户代理在设备上使用的
资源所有者。客户端凭证以及任何访问
令牌发给客户端存储在web服务器和
不接触或访问资源所有者。

user-agent-based应用程序
user-agent-based应用程序的公共端
从web服务器和客户机代码下载中执行
用户代理(例如 web浏览器)在设备上使用的资源
所有者。交通便利(和协议数据和凭证
资源所有者通常是可见的)。因为这样的应用程序
驻留在用户代理,他们可以无缝的使用
当请求授权用户代理功能。

本机应用程序
本机应用程序是一个公共客户端安装和执行
使用的设备资源所有者。协议数据和
资源所有者凭证访问。这是假设
包括在任何客户端身份验证凭据
应用程序可以提取。另一方面,动态
发行的凭证如访问令牌和刷新令牌
得到一个可接受的水平的保护。至少,这些
凭证不受恶意服务器的
应用程序可能交互。在一些平台上,这些凭证
可能会从其他应用程序驻留在相同的保护
设备。

2.2。客户机标识符

注册客户端客户端授权服务器问题
标识符——一个独一无二的字符串代表登记
由客户提供的信息。不是一个客户端标识符
秘密; 它是暴露在资源所有者,不得使用
进行客户端身份验证。客户端标识符是独一无二的
授权服务器。

客户端标识符字符串大小是左未定义
规范。客户端应该避免做出假设
标识符的大小。授权服务器应该文档大小
任何标识符的问题。

(第15页)

2.3。客户端身份验证

如果客户机类型是机密,客户端和授权
服务器建立一个适合客户机身份验证方法
授权服务器的安全需求。授权
服务器可以接受任何形式的会议客户端身份验证
安全需求。

保密客户通常发行(或创建)一套
客户端凭证用于身份验证和授权
服务器(如。、密码、公共/私有密钥对)。

授权服务器可以建立一个客户端身份验证方法
公共客户。不过,授权服务器不能依赖
在公共客户端身份验证识别的目的
客户端。

客户端必须不使用多个身份验证方法
请求。

2.3.1。客户密码

客户拥有一个客户密码可以使用HTTP基本
身份验证方案中定义的(RFC2617)进行身份验证
授权服务器。客户端标识符编码使用
“应用程序/ x-www-form-urlencoded”每编码算法
附录B,编码值作为用户名; 客户端
密码是使用相同的编码算法和作为
密码。授权服务器必须支持HTTP基本
为验证客户身份验证方案发表
客户密码。

例如(断行仅用于显示目的):

授权:基本czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

另外,授权服务器可以支持包括
使用下面的客户端证书请求主体
参数:

client_id
必需的。发给客户端在客户端标识符
由2.2节描述的注册过程。

client_secret
必需的。客户的秘密。客户端可以省略
参数如果客户机的秘密是一个空字符串。

(16页)

包括客户端凭证使用两个请求主体
参数是不可取的,应该不能局限于客户
直接利用HTTP基本身份验证方案(或其他
基于密码的HTTP身份验证方案)。参数只能
在请求主体和传播不能包含在
请求URI。

例如,请求刷新一个访问令牌(6节)
人体参数(多余的换行符用于显示目的
只):

POST HTTP / 1.1 /令牌
主持人:server.example.com
内容类型:应用程序/ x-www-form-urlencoded

grant_type = refresh_token&refresh_token = tGzv3JOkF0XG5Qx2TlKWIA
client_id = s6BhdRkqt3&client_secret = 7 fjfp0zbr1ktdrbnfvdmiw

授权服务器必须需要使用TLS中描述
1.6节在发送请求时使用密码身份验证。

因为这个客户端身份验证方法包括一个密码,
授权服务器必须防止任何端点使用它
蛮力攻击。

2.3.2。其他身份验证方法

授权服务器可以支持任何适当的HTTP身份验证
计划匹配其安全需求。当使用其他
身份验证方法,必须定义一个授权服务器
之间的映射(登记记录)和客户端标识符
身份验证方案。

2.4。未注册客户

该规范不排除使用未注册客户。
然而,使用此类客户超出了这个范围
规范和需要额外的安全分析和审查
其互操作性的影响。

(第17页)

3所示。协议的端点

授权过程利用两个授权服务器端点
(HTTP资源):

o授权使用的端点——客户端获取
从资源所有者通过授权用户代理重定向。

o标记客户端所使用的端点,交换一个授权
授予访问令牌,通常与客户端身份验证。

以及一个客户机端点:

o重定向所使用的端点,授权服务器返回
响应包含授权凭证给客户端通过
资源所有者的用户代理。

不是每个授权授予类型利用两个端点。
根据需要扩展授予类型可以定义额外的端点。

3.1。授权端点

授权使用端点与资源进行交互
所有者和获得授权批准。授权服务器
必须先验证资源所有者的身份。的方式
授权服务器验证资源所有者吗
(如。、用户名和密码登录会话cookie)超出了
本规范的范围。

客户的方式获得的位置
授权端点是超出了本规范的范围,
但位置通常提供的服务文档。

端点URI可能包括一个“应用程序/ x-www-form-urlencoded”
格式化每个附录B()查询组件([RFC3986]3.4节),
必须保留当添加额外的查询参数。的
端点URI必须不包括组件的一个片段。

自端点导致用户请求授权
身份验证和传输明文凭证(在
HTTP响应),授权服务器必须需要使用TLS
如1.6节所述当发送请求
授权端点。

授权服务器必须支持使用HTTP“获得”
方法[RFC2616]授权端点并可能支持
使用“POST”方法。

(18页)

参数发送没有值必须被视为如果他们
省略了从请求。授权服务器必须忽略
未识别的请求参数。请求和响应参数
不能包含不止一次。

3.1.1。响应类型

授权使用的端点授权代码
型和隐式授予型流动。客户端通知
授权服务器所需的授权使用以下类型
参数:

response_type
必需的。 “代码”的值必须是一个请求
授权代码由以下4.4.1节所述,“令牌”
请求一个访问令牌(隐式授予)所描述的
部分4.2.1,准备或注册扩展值作为描述
8.4节。

扩展响应类型可能包含一个空格分隔(% x20)的列表
值,值的顺序并不重要。、响应
输入“b”是一样的“b”)。这样的组合的意义
响应类型是由各自的规范定义的。

如果一个授权请求丢失“response_type”参数,
或者如果响应类型并不理解,授权服务器
必须返回一个错误响应4.1.2.1节中描述。

3.1.2。重定向端点

在完成与资源所有者的互动,
授权服务器引导资源所有者的用户代理
客户端。重定向用户代理的授权服务器
客户端端点先前建立的重定向
授权服务器客户端注册过程中或当
授权请求。

重定向端点URI必须绝对URI所定义的
(RFC3986)4.3节。可能包括一个端点URI
“应用程序/ x-www-form-urlencoded”格式(每个附录B)查询
组件([RFC3986]3.4节),必须保留当添加
额外的查询参数。端点URI必须不包括
片段组件。

(19页)

3.1.2.1。端点的请求保密

重定向端点应该需要使用TLS
在1.6节所请求的响应类型是“代码”或“令牌”,
或重定向请求时将导致的传播
在一个开放的网络敏感的凭证。这个规范
没有强制要求使用TLS因为写这篇文章的时候,
要求客户部署TLS对很多人来说是一个重大障碍
客户端开发人员。如果TLS不可用,授权服务器
要提醒资源所有者不安全的端点之前呢
重定向(如。授权期间,显示一条消息
请求)。

缺乏传输层安全能产生严重的影响
安全客户端和受保护的资源的授权
访问。使用传输层安全特别
关键在授权过程作为的一种形式
授权终端用户身份验证的客户端(例如、第三方
登录服务)。

3.1.2.2。注册要求

授权服务器必须需要以下客户
注册他们的重定向端点:

o公共客户。

o机密客户利用隐式授予类型。

授权服务器应该要求所有客户登记
重定向端点之前利用授权端点。

授权服务器应要求客户提供
完整的重定向的URI(客户端可以使用“状态”的要求
参数来实现每个请求定制)。如果需要
注册完成重定向的URI是不可能的,
授权服务器应该需要登记的URI
计划、权力和路径(允许客户端动态变化
只有当请求重定向URI的查询组件
授权)。

授权服务器可能允许客户端注册多个
重定向的端点。

缺乏一个重定向可以使一个URI登记要求
攻击者使用授权端点一样开放的转向器
在10.15节描述。

(第20页)

3.1.2.3。动态配置

如果已经注册了多个重定向的uri,如果只有部分
重定向的URI被注册,或如果没有重定向的URI
被注册,客户端必须包括一个重定向的URI
授权请求使用“redirect_uri”请求参数。

当一个重定向URI中包含一个授权请求,
授权服务器必须收到比较和匹配值
对至少一个注册(或重定向URI URI
中定义的组件)[RFC3986]第六节,如果任何重定向
uri是注册。如果客户登记包括完整的
重定向URI,授权服务器必须比较两个URI
使用简单的字符串比较[RFC3986]部分中定义6.2.1。

3.1.2.4。无效的端点

如果一个授权请求失败验证由于失踪,
无效的,或失配重定向的URI,授权服务器
应该通知错误的资源所有者和必须不
自动重定向用户代理无效的重定向的URI。

3.1.2.5。端点的内容

重定向请求客户端端点通常导致
HTML文档的反应,由用户代理处理。如果HTML
响应服务直接重定向请求的结果,
任何脚本包含在HTML文档将完全执行
访问重定向URI和它所包含的凭证。

客户端不应该包含任何第三方脚本(如。第三,
方分析、社会插件、广告网络)重定向
端点的响应。相反,它应提取的凭证
URI和重定向用户代理再到另一个端点
暴露的凭证(URI或其他地方)。如果第三方
脚本中,客户端必须确保自己的脚本
(用于提取和删除凭证的URI)
先执行。

3.2。令牌端点

令牌端点使用客户端获得一个访问令牌
展示其授权授予或刷新令牌。令牌
端点使用每个授权批准的除外
隐式授予类型(因为一个访问令牌直接发布)。

(21页)

客户的方式获得令牌的位置
端点是超出了本规范的范围,但位置
通常提供的服务文档。

因为请求令牌端点导致的传播
以明文凭证(HTTP请求和响应)
授权服务器必须需要使用TLS中描述
1.6节当发送请求令牌端点。

客户端必须使用HTTP“POST”方法时访问令牌
请求。

参数发送没有值必须被视为如果他们
省略了从请求。授权服务器必须忽略
未识别的请求参数。请求和响应参数
不能包含不止一次。

3.2.1之上。客户端身份验证

保密客户或其他客户必须发布客户端凭据
身份验证与授权服务器中描述
2.3节时请求令牌端点。客户端
身份验证用于:

o执行刷新令牌和授权码的绑定
他们发给客户端。客户端身份验证是至关重要的
当一个授权代码重定向传播
端点通过一个不安全的通道或重定向的URI
没有注册。

o恢复受损禁用客户端或客户端
改变其凭据,从而防止攻击者滥用
偷来的刷新令牌。改变单一的一套客户端
证书撤销整个组都要快得多
刷新令牌。

o实现身份验证管理最佳实践
需要旋转周期性凭证。旋转的整个集合
刷新令牌可能是一个挑战,而旋转的一个
的客户端凭据明显更容易。

(22页)

客户端可以使用“client_id”请求参数识别本身
当发送请求令牌端点。在
“grant_type“authorization_code请求令牌端点,一个
未经身份验证的客户端必须将其“client_id”以防止本身
从无意中接受代码用于客户机和一个
不同的“client_id”。这可以防止客户端替换
身份验证代码。 (它没有提供额外的安全性
受保护的资源)。

3.3。访问令牌的范围

授权和令牌端点允许客户端指定
访问请求的范围使用“范围”请求参数。在
将授权服务器使用“范围”响应参数
通知客户端访问令牌的范围。

范围参数的值表示为一个空间——列表
分隔,区分大小写的字符串。定义的字符串
授权服务器。如果值包含多个空格分隔
字符串,它们的顺序并不重要,每添加一个字符串
额外的访问请求的范围。

范围= scope-token *(SP scope-token)
scope-token = 1 *(% x21 / % x23-5B / % x5D-7E)

授权服务器可能全部或部分忽略了范围
请求的客户端,基于政策或授权服务器
资源所有者的指令。如果发布访问令牌的范围
不同于一个客户机请求的授权
服务器必须包括“范围”响应参数来通知
客户的实际范围。

如果客户机请求时省略了参数范围
授权,授权服务器必须的过程
请求使用一个预定义的默认值或失败请求
指示一个无效的范围。授权服务器应该
文档范围需求和默认值(如果定义)。

4所示。获得授权

客户端请求一个访问令牌,获得授权的
资源所有者。授权的形式来表达
授权批准,请求访问的客户机使用
令牌。格兰特OAuth定义了四个类型:授权代码,隐式的,
资源所有者密码凭据和客户端凭据。它还
提供了一个扩展机制来定义额外的资助类型。

(23页)

4.1。授权代码授予

授权代码授予类型用于获取访问
令牌和刷新令牌和为机密的客户进行了优化。
由于这是一个redirection-based流,客户端必须能够
交互与资源所有者的用户代理(通常是一个网络
浏览器)和接收传入的请求(通过重定向)
从授权服务器。

+ - - - - - - - - - - - +
| |资源
| |老板
| |
+ - - - - - - - - - - - +
^
|
(B)
+ +客户端标识符+ - - - - - | - - - - - - - - - - - - - - - - - - - - - - - - - - +
| - + - - - - -(A)和重定向URI - - - - - > | |
授权用户——| | | |
代理| - + - - - - -(B)——用户验证- > | |服务器
| | | |
| - + - - - - -(C)授权代码- - - - - - < | |
+ - - - - - - | - - - | - - - - - - + + - - - - - - - - - - - - - - - - - - +
| | ^ v
(一)(C)| |
| | | |
v ^ | |
+ - - - - - - - - - - - - + | |
| | > - - - - - -(D)- - - - - - - - - - - - - ' |授权代码
| | |客户&重定向URI
| | |
| | < - - - - - -访问令牌(E)- - - - - - - - - - - - - - - - - - - - - - - - - - -”
+ - - - - - - - - - - - - +(w /可选的刷新令牌)

注意:行说明步骤(A)、(B)和(C)闯入
通过用户代理两部分。

图3:授权代码流

(24页)

流程如图3所示包括以下步骤:

(一)客户端发起指导资源所有者的流动
用户代理授权的端点。客户端包括
客户标识符,请求范围、本地状态,
重定向的URI授权服务器将发送
用户代理回访问授予(或拒绝)。

(B)的授权服务器验证资源所有者(通过
用户代理),建立资源所有者
允许或拒绝客户的访问请求。

(C)假设资源所有者授予访问权限,授权
服务器切换用户重定向到客户端使用
重定向的URI(请求或在早些时候提供
客户端注册)。重定向URI包含一个
授权代码和任何本地状态由客户提供
早些时候。

(D)客户端请求的访问令牌授权
服务器的令牌端点,包括授权代码
在前面的步骤。使请求时,
客户端进行身份验证与授权服务器。客户端
包括重定向URI用于获得授权
代码验证。

(E)授权服务器对客户端进行身份验证,验证
授权代码,确保重定向的URI
收到匹配的URI用于重定向客户
步骤(C),如果有效,授权服务器响应返回
可选地,一个访问令牌和刷新令牌。

以下4.4.1。授权请求

客户端通过添加以下构造请求URI
参数的查询组件授权端点URI
使用“应用程序/ x-www-form-urlencoded”格式,每个附录B:

response_type
必需的。值必须设置为“代码”。

client_id
必需的。如2.2节所述客户端标识符。

redirect_uri
可选的。 3.1.2节中描述。

(25页)

范围
可选的。访问请求的范围描述
3.3节。

状态
推荐。一个不透明的价值所使用的客户端维护
请求和回调的状态。授权
服务器包括这个值时重定向用户代理
给客户端。参数应该用于预防
跨站点请求伪造如10.12节所述。

客户端将资源所有者使用一个构造URI
HTTP重定向响应,或者通过其他方式获得通过
用户代理。

例如,客户端将用户代理以下
HTTP请求使用TLS(多余的换行符用于显示目的
只):

GET /授权? response_type = code&client_id = s6BhdRkqt3&state = xyz
&redirect_uri 3 = https % % 2 f % % 2 2 fclient % 2典范易康姆% 2巴萨的HTTP / 1.1
主持人:server.example.com

授权服务器验证请求,以确保所有
必需的参数存在和有效。如果请求是有效的,
授权服务器验证资源所有者和获得
一个授权决策(要求资源所有者或
建立审批通过其他方式)。

当建立一个决定是,授权服务器指导
用户代理提供客户端使用HTTP重定向的URI
重定向响应,或通过其他方式通过
用户代理。

4.1.2。授权响应

如果资源所有者授予访问请求,授权
服务器问题授权代码,并将其给客户端
添加以下参数的查询组件
重定向URI使用“应用程序/ x-www-form-urlencoded”格式,
每一附录B:

代码
必需的。授权代码生成的
授权服务器。授权代码必须到期
发行后不久减轻泄漏的风险。一个
一生最大的授权代码10分钟
推荐。客户端不能使用授权代码

(26页)

不止一次。如果使用超过一个授权代码
一次,授权服务器必须拒绝请求,应该
撤销(如果可能的话)所有之前发布了基于令牌
授权代码。授权代码绑定到
客户端标识符和重定向的URI。

状态
如果需要“状态”参数出现在客户端
授权请求。从收到的精确值
客户端。

例如,授权服务器重定向用户代理
发送以下HTTP响应:

HTTP / 1.1 302年发现的
地点:https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
状态= xyz

客户端必须忽略识别响应参数。的
授权代码字符串大小是左未定义
规范。客户端应该避免对代码做任何假设
价值大小。授权服务器应该文档的大小
任何价值的问题。

4.1.2.1。错误响应

如果请求失败由于失踪,无效,或失配
重定向的URI,或者客户端标识符是缺失或无效的,
授权服务器应该通知的资源所有者
错误,不能自动重定向用户代理的
无效的重定向的URI。

如果资源所有者拒绝访问请求或者请求
失败的原因除了缺失或无效的重定向的URI,
授权服务器客户端通过添加以下通知
重定向的参数查询组件使用的URI
“应用程序/ x-www-form-urlencoded”格式,每个附录B:

错误
必需的。一个ASCII(USASCII)的错误代码
后:

invalid_request
请求缺少必需的参数,包括一个
无效的参数值,包括超过一个参数
一次,或者畸形。

(27页)

unauthorized_client
客户端未被授权请求授权
使用这种方法的代码。

access_denied
资源所有者或授权服务器拒绝
请求。

unsupported_response_type
授权服务器不支持获得一个
授权代码使用这个方法。

invalid_scope
所请求的范围是无效的,未知的,或畸形。

server_error
授权服务器遇到了一个意想不到的
条件,阻止它满足请求。
(这个错误代码是必需的,因为500内部服务器
错误HTTP状态代码不能被返回给客户端
通过一个HTTP重定向)。

temporarily_unavailable
授权服务器目前无法处理
请求由于暂时过载或维护
的服务器。 (这个错误代码是必要的,因为一个503
服务不可用HTTP状态代码不能返回
客户端通过一个HTTP重定向)。

“错误”参数的值必须不包括字符
外设置% x20-21 / % x23-5B / % x5D-7E。

error_description
可选的。人类可读的ASCII文本提供[USASCII]
附加信息,协助客户开发人员使用
理解错误发生。
“error_description”参数的值必须不包括
以外的字符% x20-21 / % x23-5B / % x5D-7E设置。

error_uri
可选的。 URI标识一个人类可读的web页面
关于错误的信息,用于提供客户端
开发人员使用额外的信息错误。
值必须符合“error_uri”参数
uri引用语法,因此必须不包括字符
外设置% x21 / % x23-5B / % x5D-7E。

(28页)

状态
如果需要一个“状态”参数出现在客户端
授权请求。从收到的精确值
客户端。

例如,授权服务器重定向用户代理
发送以下HTTP响应:

HTTP / 1.1 302年发现的
地点:https://client.example.com/cb?error=access_denied&state=xyz

4.1.3。访问令牌的请求

客户端发出请求令牌端点发送的
以下参数使用“应用程序/ x-www-form-urlencoded”
格式/附录B的utf - 8字符编码HTTP
请求实体:

grant_type
必需的。值必须设置为“authorization_code”。

代码
必需的。从收到的授权代码
授权服务器。

redirect_uri
必需的,如果“redirect_uri”参数是包含在
授权请求以下4.4.1节中所述,他们的
值必须是相同的。

client_id
必需的,如果客户没有认证的
授权服务器3.2.1节中描述。

如果客户机类型是保密的或客户端发布客户端
认证要求(或指定的其他凭证)
客户端必须进行身份验证与授权服务器作为描述
3.2.1节中。

(第29页)

例如,客户端使用TLS让下面的HTTP请求
(断行仅用于显示目的):

POST HTTP / 1.1 /令牌
主持人:server.example.com
授权:基本czZCaGRSa3F0MzpnWDFmQmF0M2JW
内容类型:应用程序/ x-www-form-urlencoded

grant_type = authorization_code&code = SplxlOBeZQQYbYS6WxSbIA
&redirect_uri 3 = https % % 2 f % 2 fclient % % 2易康姆% 2巴萨2典范

授权服务器必须:

o要求机密客户或任何客户端身份验证
客户端发布客户端凭证(或与其他
身份验证需求),

o验证客户端如果包含客户机身份验证,

o确保授权的代码发布的身份验证
保密客户,或者客户端是公共的,确保
代码发布“client_id”要求,

o确认授权代码是有效的,

o确保“redirect_uri”如果参数是礼物
“redirect_uri”参数是包含在最初的授权
请求以下4.4.1节中描述,如果包括确保
他们的价值观是相同的。

4.1.4。访问令牌的反应

如果访问令牌请求是有效的和授权的,
授权服务器问题一个访问令牌和可选的刷新
令牌如5.1节所述。如果请求客户端
身份验证失败或无效,授权服务器返回
一个错误的反应如5.2节所述。

(30页)

一个例子成功的响应:

HTTP / 1.1 200 OK
内容类型:application / json;charset = utf - 8
cache - control:不是商店
编译指示:no - cache

{
:“access_token 2 yotnfzfejr1zcsicmwpaa”,
“token_type”:“例子”,
“expires_in”:3600年,
:“refresh_token tGzv3JOkF0XG5Qx2TlKWIA”,
:“example_parameter example_value”
}

4.2。隐式授予

隐式授予类型用于获取访问令牌(它不
支持刷新令牌)的发行,对公众进行了优化
客户操作特定的重定向的URI。这些客户
通常是实现在浏览器中使用脚本语言
比如JavaScript。

由于这是一个redirection-based流,客户端必须能够
交互与资源所有者的用户代理(通常是一个网络
浏览器)和接收传入的请求(通过重定向)
从授权服务器。

与授权代码授予类型,客户端
单独的授权和访问令牌的请求,
客户端接收访问令牌授权的结果
请求。

隐式授予类型不包括客户端身份验证
依赖资源所有者和登记
重定向的URI。因为访问令牌到编码
重定向的URI,它可能暴露于资源所有者和其他
应用程序驻留在相同的设备。

(31页)

+ - - - - - - - - - - - +
| |资源
| |老板
| |
+ - - - - - - - - - - - +
^
|
(B)
+ +客户端标识符+ - - - - - | - - - - - - - - - - - - - - - - - - - - - - - - - - +
| - + - - - - -(A)和重定向URI - - - > | |
授权用户——| | | |
代理| - | - - - - -(B)-用户验证- > | |服务器
| | | |
| | <——(C)——重定向URI - - - - - < | |
与访问令牌+ | | - - - - - - - - - - - - - - - - - - +
| |在片段
| | + - - - - - - - - - - - - - - - - - - +
| | - - - - -(D)- - -重定向URI - - - - - >托管| |
客户端| | | |没有片段
| | | |资源
|(F)| < - - - - - -脚本(E)- - - - - - - - - - - - - - - - - - - < | |
| | + - - - - - - - - - - - - - - - - - - +
+ - | - - - - - - - - - - +
| |
(一)(G)访问令牌
| |
v ^
+ - - - - - - - - - - - - +
| |
客户端| |
| |
+ - - - - - - - - - - - - +

注意:行说明步骤(A)和(B)分为两种
部分,因为他们通过用户代理。

图4:隐式授予流

(第32页)

流程如图4所示,包括以下步骤:

(B)的授权服务器验证资源所有者(通过
用户代理),建立资源所有者
允许或拒绝客户的访问请求。

(C)假设资源所有者授予访问权限,授权
服务器切换用户重定向到客户端使用
重定向URI提供了。重定向的URI包含
URI访问令牌的片段。

(D)的用户代理之前,通过重定向指令
托管客户机请求的资源(不
包括片段/[RFC2616])。切换用户保留了
片段在本地信息。

(E)网站客户资源(通常是一个返回一个web页面
HTML文档使用嵌入式脚本)访问的能力
完整的重定向URI包括聘请的片段
用户代理,提取访问令牌(和其他
片段中包含的参数)。

(F)网站提供的用户代理执行脚本
客户端在本地资源,提取访问令牌。

(G)的用户代理将访问令牌传递给客户端。

1.3.2看到部分和9使用隐式授予为背景。
见章节10.3和10.16重要的安全考虑
当使用隐式授予。

4.2.1。准备授权请求

客户端通过添加以下构造请求URI
参数的查询组件授权端点URI
使用“应用程序/ x-www-form-urlencoded”格式,每个附录B:

response_type
必需的。值必须设置为“令牌”。

client_id
必需的。如2.2节所述客户端标识符。

(第33页)

redirect_uri
可选的。 3.1.2节中描述。

范围
可选的。访问请求的范围描述
3.3节。

客户端将资源所有者使用一个构造URI
HTTP重定向响应,或者通过其他方式获得通过
用户代理。

例如,客户端将用户代理以下
HTTP请求使用TLS(多余的换行符用于显示目的
只):

GET /授权? response_type = token&client_id = s6BhdRkqt3&state = xyz
&redirect_uri 3 = https % % 2 f % % 2 2 fclient % 2典范易康姆% 2巴萨的HTTP / 1.1
主持人:server.example.com

授权服务器验证请求,以确保所有
必需的参数存在和有效。授权服务器
必须确认重定向的URI,它将重定向
重定向URI访问令牌匹配的客户端注册
3.1.2中所描述的部分。

如果请求是有效的,授权服务器验证
资源所有者和获得授权决策(通过询问
资源所有者或通过建立审批通过其他方式)。

当建立一个决定是,授权服务器指导
用户代理提供客户端使用HTTP重定向的URI
重定向响应,或通过其他方式通过
用户代理。

(34页)

4.2.2。访问令牌的反应

如果资源所有者授予访问请求,授权
服务器问题一个访问令牌,并将其添加到客户端
以下参数的片段组件重定向
URI使用“应用程序/ x-www-form-urlencoded”格式,每
附录B:

access_token
必需的。访问令牌授权发布的服务器。

token_type
必需的。中描述的令牌发出的类型
7.1节。值是不区分大小写。

expires_in
推荐。的一生在几秒钟内访问令牌。为
值“3600”表示,访问令牌
在一个小时的时间到期生成响应。
如果省略,授权服务器应该提供
过期时间通过其他方式或文档的默认值。

范围
可选的,如果相同的客户机请求的范围;
否则,必需的。访问令牌的范围
由3.3节描述。

状态
如果需要“状态”参数出现在客户端
授权请求。从收到的精确值
客户端。

授权服务器不能刷新令牌。

例如,授权服务器重定向用户代理
发送以下HTTP响应(多余的换行符
仅显示目的):

HTTP / 1.1 302年发现的
地点:http://example.com/cb access_token = 2 yotnfzfejr1zcsicmwpaa
状态= xyz&token_type = example&expires_in = 3600

开发人员应该注意一些用户代理不支持
包含一个片段组件在HTTP响应“位置”
头字段。这样的客户需要使用其他的方法
将比3 xx重定向响应,客户端
返回一个HTML页面,包括一个“继续”按钮
行动与重定向的URI。

(35页)

客户端必须忽略识别响应参数。的访问
令牌字符串大小是离开这个规范定义的。的
客户机应该避免假设值大小。的
授权服务器应该文档的任何值的大小问题。

4.2.2.1。错误响应

如果资源所有者拒绝访问请求或者请求
失败的原因除了缺失或无效的重定向的URI,
授权服务器客户端通过添加以下通知
参数的片段分量重定向使用的URI
“应用程序/ x-www-form-urlencoded”格式,每个附录B:

错误
必需的。一个ASCII(USASCII)的错误代码
后:

invalid_request
请求缺少必需的参数,包括一个
无效的参数值,包括超过一个参数
一次,或者畸形。

unauthorized_client
客户端未被授权请求一个访问令牌
使用这种方法。

access_denied
资源所有者或授权服务器拒绝
请求。

unsupported_response_type
授权服务器不支持获得一个
访问令牌使用这种方法。

invalid_scope
所请求的范围是无效的,未知的,或畸形。

(第36页)

“错误”参数的值必须不包括字符
外设置% x20-21 / % x23-5B / % x5D-7E。

状态
如果需要一个“状态”参数出现在客户端
授权请求。从收到的精确值
客户端。

例如,授权服务器重定向用户代理
发送以下HTTP响应:

HTTP / 1.1 302年发现的
地点:https://client.example.com/cb错误= access_denied&state = xyz

4.3。资源所有者密码凭据

资源所有者授予类型适用于密码凭据
情况下,资源所有者的信任关系
客户端,如设备操作系统或一个高度特权

(37页)

应用程序。授权服务器时应特别小心
启用这个格兰特类型和只允许它在其他流动
可行的。

这种资助类型适用于客户获得的能力
资源所有者的凭据(用户名和密码,通常使用
一个互动的形式)。它还可以用于迁移现有客户
使用HTTP基本身份验证方案,如直接或消化
身份验证的OAuth转换存储凭证的
访问令牌。

+ - - - - - - - - - - - +
| |资源
| |老板
| |
+ - - - - - - - - - - - +
v
|资源所有者
(一)密码凭据
|
v
+ - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - +
| | >——(B)——资源所有者- - - - - - - > | |
| | | |密码凭证授权
服务器客户端| | | |
| | <——(C)——访问令牌- - - - - - - - - - - - < | |
| |(w /可选的刷新令牌)| |
+ - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - +

图5:资源所有者凭证流密码

流程如图5所示包括以下步骤:

(一)资源所有者提供客户端用户名和
密码。

(B)的客户端请求一个访问令牌授权
服务器的令牌端点,包括收到的凭证
从资源所有者。做请求时,客户端
认证与授权服务器。

(C)授权服务器对客户端进行身份验证和验证
资源所有者凭证,如果有效,一个访问的问题
令牌。

(38页)

4.3.1。授权请求和响应

客户端获取资源所有者的方法
凭证已经超出了本规范的范围。客户端
必须抛弃凭证一旦获得一个访问令牌。

4.3.2。访问令牌的请求

客户端发出请求令牌端点通过添加
以下参数使用“应用程序/ x-www-form-urlencoded”
格式/附录B的utf - 8字符编码HTTP
请求实体:

grant_type
必需的。值必须设置为“密码”。

用户名
必需的。资源所有者的用户名。

密码
必需的。资源所有者密码。

范围
可选的。访问请求的范围描述
3.3节。

如果客户机类型是保密的或客户端发布客户端
认证要求(或指定的其他凭证)
客户端必须进行身份验证与授权服务器作为描述
3.2.1节中。

例如,客户端使以下HTTP请求使用
传输层安全(多余的换行显示目的
只):

POST HTTP / 1.1 /令牌
主持人:server.example.com
授权:基本czZCaGRSa3F0MzpnWDFmQmF0M2JW
内容类型:应用程序/ x-www-form-urlencoded

grant_type =密码和用户名= johndoe&password = A3ddj3w

(39页)

授权服务器必须:

o要求机密客户或任何客户端身份验证
客户端发布客户端凭证(或与其他
身份验证需求),

o验证客户端如果包含客户机身份验证,和

o验证资源所有者凭证使用其密码
现有的密码验证算法。

因为这个请求利用资源所有者的访问令牌
密码,授权服务器必须防止端点
蛮力攻击(如。 ,使用速率限制或生成
警报)。

4.3.3。访问令牌的反应

如果访问令牌请求是有效的和授权的,
授权服务器问题一个访问令牌和可选的刷新
令牌如5.1节所述。如果请求失败的客户
身份验证或无效,授权服务器返回一个
错误响应如5.2节所述。

一个例子成功的响应:

HTTP / 1.1 200 OK
内容类型:application / json;charset = utf - 8
cache - control:不是商店
编译指示:no - cache

{
:“access_token 2 yotnfzfejr1zcsicmwpaa”,
“token_type”:“例子”,
“expires_in”:3600年,
:“refresh_token tGzv3JOkF0XG5Qx2TlKWIA”,
:“example_parameter example_value”
}

4.4。客户端证书授予

客户端可以使用只有客户请求一个访问令牌
凭证(或其他支持身份验证的手段)
客户端在请求访问受保护的资源
控制,或者另一个之前的资源所有者
安排与授权服务器(的方法
本规范的范围)。

(40页)

使用的客户端凭据格兰特类型只能保密
客户。

图6:客户端凭证流

流程如图6所示包括以下步骤:

(一)服务器和客户机进行身份验证和授权
请求一个访问令牌从牌端点。

(B)授权服务器对客户端进行身份验证,如果有效,
问题一个访问令牌。

4.1.1。授权请求和响应

由于客户端身份验证作为授权格兰特,
不需要额外的授权请求。

10/24/11。访问令牌的请求

客户端发出请求令牌端点通过添加
以下参数使用“应用程序/ x-www-form-urlencoded”
格式/附录B的utf - 8字符编码HTTP
请求实体:

grant_type
必需的。值必须设置为“client_credentials”。

范围
可选的。访问请求的范围描述
3.3节。

客户端必须进行身份验证与授权服务器
3.2.1节中描述。

(41页)

例如,客户端使以下HTTP请求使用
传输层安全(多余的换行显示目的
只):

POST HTTP / 1.1 /令牌
主持人:server.example.com
授权:基本czZCaGRSa3F0MzpnWDFmQmF0M2JW
内容类型:应用程序/ x-www-form-urlencoded

grant_type = client_credentials

授权服务器必须对客户端进行身份验证。

4.4.3。访问令牌的反应

如果访问令牌请求是有效的和授权的,
授权服务器问题描述的一个访问令牌
5.1节。刷新令牌不应包括在内。如果请求
客户端身份验证失败或无效,授权服务器
返回一个错误响应如5.2节所述。

一个例子成功的响应:

HTTP / 1.1 200 OK
内容类型:application / json;charset = utf - 8
cache - control:不是商店
编译指示:no - cache

{
:“access_token 2 yotnfzfejr1zcsicmwpaa”,
“token_type”:“例子”,
“expires_in”:3600年,
:“example_parameter example_value”
}

4.5。扩展授予

客户端使用一个扩展授予类型通过指定类型
使用绝对URI(定义的授权服务器)
“grant_type”参数值的令牌端点,
添加任何必要的附加参数。

(42页)

例如,要求一个访问令牌使用安全断言
2.0断言标记语言(SAML)授予类型所定义的
(OAuth-SAML2),客户端可以使用下面的HTTP请求
TLS(断行仅用于显示目的):

POST HTTP / 1.1 /令牌
主持人:server.example.com
内容类型:应用程序/ x-www-form-urlencoded

grant_type =瓮% 3 aietf % 3 aparams % 3 aoauth % 3 agrant-type % 3 asaml2 -
bearer&assertion = PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
[… 为了简便起见,我们省略了…]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24 -

5。发行一个访问令牌

5.1。成功的响应

授权服务器问题一个访问令牌和可选的刷新
令牌,通过添加以下参数和结构响应
实体的HTTP响应200(OK)状态码:

access_token
必需的。访问令牌授权发布的服务器。

token_type
必需的。中描述的令牌发出的类型
7.1节。值是不区分大小写。

(43页)

refresh_token
可选的。刷新令牌,可以用于获得新
访问令牌使用相同的授权给予描述
在第六节。

范围
可选的,如果相同的客户机请求的范围;
否则,必需的。访问令牌的范围
由3.3节描述。

参数都包含在HTTP响应的实体
使用“application / json”定义的媒体类型(RFC4627)。的
参数序列化为一个JavaScript对象表示法(JSON)
结构通过添加每个参数在最高的层次结构。
参数名称和字符串值作为JSON字符串。
数值作为JSON数据。的顺序
参数不重要,可以有所不同。

授权服务器必须包括HTTP“cache - control”
响应头域[RFC2616]的值在任何“不是商店”
响应包含令牌、证书或其他敏感
信息,以及“杂注”响应头域[RFC2616]
用一个“no - cache”的价值。

例如:

HTTP / 1.1 200 OK
内容类型:application / json;charset = utf - 8
cache - control:不是商店
编译指示:no - cache

{
:“access_token 2 yotnfzfejr1zcsicmwpaa”,
“token_type”:“例子”,
“expires_in”:3600年,
:“refresh_token tGzv3JOkF0XG5Qx2TlKWIA”,
:“example_parameter example_value”
}

客户端必须忽略名称在响应识别价值。的
尺寸的令牌和收到的授权其他值
服务器未定义。客户端应该避免
假设值大小。授权服务器应该
文档的任何值的大小问题。

(44页)

5.2。错误响应

授权服务器响应HTTP 400(坏的请求)
状态代码(除非特别说明),并包括以下
参数与响应:

错误
必需的。一个ASCII(USASCII)的错误代码
后:

invalid_request
请求缺少必需的参数,包括一个
不支持的参数值(除了授予类型),
重复一个参数,包括多个证书,
利用多个验证机制
客户端,或者另有畸形。

invalid_client
(如客户端身份验证失败。未知的客户端,没有
包括客户端身份验证,或不受支持的
身份验证方法)。授权服务器可能
返回一个HTTP 401(未经授权)状态码来表示
它支持HTTP身份验证方案。如果
客户端试图验证通过“授权”
请求头字段,授权服务器必须
回应一个HTTP 401(未经授权)状态码
包括“WWW-Authenticate”响应标头字段
匹配的客户端所使用的身份验证方案。

invalid_grant
提供授权批准(如。、授权
代码,资源所有者凭证)或刷新令牌
无效,过期、撤销、不匹配的重定向
URI用于授权请求,或发布
另一个客户端。

unauthorized_client
经过身份验证的客户端未被授权使用
授权批准的类型。

unsupported_grant_type
授权批准类型不支持
授权服务器。

(第45页)

invalid_scope
所请求的范围是无效的,不为人知,畸形,或
超过了资源所有者授予的范围。

“错误”参数的值必须不包括字符
外设置% x20-21 / % x23-5B / % x5D-7E。

参数都包含在HTTP响应的实体
使用“application / json”定义的媒体类型(RFC4627)。的
通过添加参数序列化为JSON结构
结构参数在最高水平。参数名称和字符串
值作为JSON字符串。包括数值
为JSON数据。参数的顺序并不重要,可以
有所不同。

例如:

HTTP / 1.1 400错误请求
内容类型:application / json;charset = utf - 8
cache - control:不是商店
编译指示:no - cache

{
“错误”:“invalid_request”
}

(46页)

6。刷新一个访问令牌

如果授权服务器向客户端发出刷新令牌
客户会刷新请求令牌端点通过添加
以下参数使用“应用程序/ x-www-form-urlencoded”
格式/附录B的utf - 8字符编码HTTP
请求实体:

grant_type
必需的。值必须设置为“refresh_token”。

refresh_token
必需的。刷新令牌发给客户端。

范围
可选的。访问请求的范围描述
3.3节。请求的范围必须不包含任何范围
不是最初的资源所有者,如果省略了
视为等于最初授予的范围
资源所有者。

因为刷新令牌通常是持久的凭据
请求更多的访问令牌,刷新令牌绑定到
客户端发布。如果客户机类型是保密的或
客户端发布客户端凭证(或指定其他
身份验证需求),客户端必须进行身份验证
授权服务器3.2.1节中描述。

例如,客户端使以下HTTP请求使用
传输层安全(多余的换行显示目的
只):

POST HTTP / 1.1 /令牌
主持人:server.example.com
授权:基本czZCaGRSa3F0MzpnWDFmQmF0M2JW
内容类型:应用程序/ x-www-form-urlencoded

grant_type = refresh_token&refresh_token = tGzv3JOkF0XG5Qx2TlKWIA

(47页)

授权服务器必须:

o要求机密客户或任何客户端身份验证
客户端发布客户端凭证(或与其他
身份验证需求),

o验证客户端是否包括和客户端身份验证
确保刷新令牌发出身份验证
客户端,

o确认刷新令牌。

如果有效,授权,授权服务器访问的问题
令牌如5.1节所述。如果请求失败
验证或无效,授权服务器返回一个错误
如5.2节所述的反应。

授权服务器可能问题一个新的刷新令牌,在这种情况下
客户端必须丢弃旧的刷新令牌和替换它
新刷新令牌。授权服务器可以撤销
刷新令牌之后,一个新的刷新令牌给客户机。如果一个
新刷新令牌,刷新令牌必须范围
相同的刷新令牌包含的客户
请求。

7所示。访问受保护的资源

客户端访问受保护资源的访问
令牌到资源服务器。资源服务器必须验证
访问令牌,并确保它没有到期,其范围
涵盖了所请求的资源。所使用的资源的方法
服务器验证访问令牌(以及任何错误响应)
超出了本规范的范围,但通常涉及一个
资源服务器和之间的交互或协调
授权服务器。

客户端利用访问令牌的方法
与资源服务器验证取决于类型的访问
颁发的令牌授权服务器。一般来说,它包括
使用HTTP请求头字段(RFC2617)“授权”的
身份验证方案的规范定义的访问
使用令牌类型,如[RFC6750]。

(48页)

7.1。访问令牌类型

访问令牌类型为客户端提供了信息
需要成功地利用访问令牌进行保护
资源请求(连同特定类型属性)。客户端
不能使用一个访问令牌如果不理解令牌
类型。

例如,“持票人”令牌类型中定义(RFC6750)是利用
通过简单地包括访问令牌请求字符串:

1 /资源/ HTTP / 1.1
主持人:example.com
授权:无记名mf_9.b5f jqm——4.1

而“mac”令牌类型中定义(OAuth-HTTP-MAC)是利用
发布消息身份验证代码(MAC)的关键
访问令牌用于HTTP的某些组件的迹象
请求:

1 /资源/ HTTP / 1.1
主持人:example.com
授权:MAC id =“h480djs93hd8”,
现时标志= " 274312:dj83hs9s”,
mac = " kDZvddkndxvhGRXZhvuDjEWhGeE = "

上面的示例仅供演示目的。
建议开发人员查阅[RFC6750]和[OAuth-HTTP-MAC]
规范使用前。

每一个访问令牌类型定义指定额外的属性
(如果有的话)发送到客户机一起“access_token”反应
参数。它还定义了HTTP身份验证方法
包括访问令牌时请求受保护的资源。

7.2。错误响应

如果一个资源访问请求失败,资源服务器应该通知
客户端错误。而这样的细节错误响应
超出了本规范的范围,本文建立了吗
一个公共注册中心在11.4节错误值之间共享
OAuth令牌的身份验证方案。

新的OAuth身份验证方案设计主要是令牌
验证应该定义一个机制提供一个错误
状态代码到客户端,允许误差值
注册在注册表误差建立了此规范。

(49页)

这样的计划可能会限制有效的错误代码的集合的一个子集
注册的值。如果返回的错误代码是使用一个命名
参数,参数名称应该是“错误”。

其他方案能够用于OAuth令牌认证,
但主要不是为了这个目的而设计的,可以结合他们的错误
注册表值以同样的方式。

新的身份验证方案也可以选择指定的使用
“error_description”和“error_uri”参数,返回错误
信息的方式并行使用
规范。

8。可扩展性

8.1。定义访问令牌类型

访问令牌类型可以定义两种方式中的一种:注册
注册表的访问令牌类型(以下程序
11.1节),或者通过使用一个独特的绝对URI作为它的名字。

利用URI类型应限于特定于供应商的名称
实现一般不适用的,和特定于
资源服务器的实现细节
使用。

所有其他类型必须注册。类型名称必须符合
类型名称ABNF。如果类型定义包含一个新的HTTP
身份验证方案,HTTP的类型名称应该是相同的
身份验证方案名称(按[RFC2617])的定义。令牌类型
“例子”是留给在例子中使用。

类型名称= 1 * name-char
name-char =“-”/”。 “/”_”/数字/α

8.2。定义新的端点参数

新请求或响应参数使用授权
端点或令牌端点定义和注册
OAuth参数注册程序后在11.2节。

参数名称必须符合param-name ABNF和参数
值必须是明确定义的(如语法。、使用ABNF或参考
现有的参数的语法)。

param-name = 1 * name-char
name-char =“-”/”。 “/”_”/数字/α

(50页)

未登记的不是特定于供应商的参数扩展
普遍适用的和特定于实现
授权服务器的细节,他们应该使用
使用一个特定于供应商的前缀不可能冲突
(如其他注册值。 ,开始“companyname_”)。

8.3。定义新的授权授予类型

新的授权授予类型可以定义分配他们
独特的绝对URI使用“grant_type”参数。如果
扩展格兰特端点类型需要额外的令牌参数,
他们必须注册在OAuth参数注册表所述
由11.2节。

8.4。定义新的授权端点响应类型

新的授权使用的端点响应类型
定义和授权注册端点响应类型
注册过程后,在11.3节。响应类型
名称必须符合响应类型ABNF。

响应类型= response-name *(SP response-name)
response-name = 1 * response-char
response-char = " _ " /数字/α

如果一个响应类型包含一个或多个空格字符(% x20)
比较作为一个空格分隔的值列表的顺序吗
值并不重要。只有一个值可以注册,
涵盖所有其他安排相同的值。

例如,响应类型“令牌代码”是未定义的
规范。然而,一个扩展可以定义和注册
“令牌代码”反应类型。一旦注册,相同的组合
不能注册为“代码令牌”,但两个值可以用来
表示相同的反应类型。

8.5。定义额外的错误代码

在这种情况下,(即协议扩展。、访问令牌类型
扩展参数,或扩展授予类型)需要额外的
格兰特使用错误代码的授权代码错误
4.1.2.1响应(部分),隐式授予错误响应
4.2.2.1(部分),令牌错误响应(5.2节),或
资源访问错误响应(7.2节),这样的错误代码
定义的。

(51页)

扩展错误代码必须注册(以下程序
11.4节)如果扩展他们结合使用
注册端点注册访问令牌类型参数,或一个
格兰特类型的扩展。错误代码使用未注册扩展
可以注册。

错误代码必须符合错误ABNF和应该前缀
一个确定的名字。例如,一个错误识别
无效的值设置为扩展参数“例子”
名为“example_invalid”。

= 1 * error-char错误
error-char = % x20-21 / % x23-5B / % x5D-7E

9。本机应用程序

本机应用程序客户端安装,并在设备上执行
资源所有者(即使用。、桌面应用程序本地移动
应用程序)。本机应用程序需要特殊考虑
有关安全、平台功能,整体终端用户
体验。

授权端点需要客户端之间的交互
和资源所有者的用户代理。本机应用程序可以调用
外部用户代理或应用程序中嵌入一个用户代理。
例如:

o外部用户代理——本机应用程序可以捕获
使用重定向响应从授权服务器URI
与计划注册操作系统调用
客户端处理程序,手动复制粘贴的凭证,
运行一个本地web服务器,安装一个用户代理扩展,或
通过提供一个重定向URI识别服务器托管
资源客户的控制,进而使
响应本机应用程序可用。

o嵌入用户代理——本机应用程序获得响应
通过直接与嵌入式通信用户代理
监测期间释放的状态改变资源负载,或
访问用户代理的cookie存储。

在选择外部或嵌入用户代理,开发人员
应该考虑以下几点:

o外部用户代理可能会提高完成率,
资源所有者可能已经有一个活跃的会话
授权服务器,消除需要重新。它
提供了一个熟悉的终端用户体验和功能。的

(52页)

资源所有者也依赖于用户代理功能或扩展
协助认证(如。密码管理器,2
设备的读者)。

o嵌入式用户代理可能会提供改进的可用性,因为它消除了
需要切换上下文和打开新的窗口。

o嵌入式用户代理构成安全挑战,因为资源
主人在一个身份不明的窗口没有验证
发现在大多数视觉保护外部用户代理。一个
嵌入式用户代理教育用户身份不明的信任
请求进行身份验证(使钓鱼攻击更容易
执行)。

在选择之间的隐式授予类型和权限
代码授予类型,应考虑如下:

o本机使用授权代码授予类型的应用程序
应该没有使用客户端证书,由于本机
应用程序无法客户机凭据保密。

o在使用隐式授予类型流时,刷新令牌不是
返回,这需要重复授权过程
访问令牌到期。

10。安全注意事项

作为一个灵活的和可扩展的框架,OAuth的安全
考虑取决于很多因素。以下部分
集中在三个为实现者提供安全指导方针
客户端配置文件2.1节中描述:web应用程序,
user-agent-based应用程序和本地应用程序。

一个全面的OAuth安全模型和分析,以及
背景协议设计,提供了
[OAuth-THREATMODEL]。

10.1。客户端身份验证

授权与web服务器建立客户端凭据
应用程序客户端对客户端身份验证的目的。的
授权服务器是鼓励考虑更强的客户
比客户端密码身份验证方法。 Web应用程序客户端
必须确保客户密码和其他客户的保密
凭证。

(53页)

授权服务器不能问题客户端密码或其他
客户端凭证或user-agent-based本机应用程序
应用程序客户端对客户端身份验证的目的。的
授权服务器可能问题客户密码或其他凭证
为一个特定的本地应用程序客户机的安装
特定的设备。

当客户机身份验证是不可能的,授权服务器
应采用其他方法来验证客户的身份——对吗
例子,要求客户端的注册重定向URI
或者争取资源所有者确认身份。一个有效的
重定向URI并不足以验证客户的身份
当要求资源所有者授权但可以使用
防止假冒客户后交付凭证
获取资源所有者授权。

授权服务器必须考虑的安全影响
与未经身份验证的客户端交互,采取措施,限制
其他凭证(如的潜在风险。 ,刷新令牌)
发出这样的客户。

10.2。客户端模拟

恶意客户机可以冒充另一个客户机并获得访问
如果模仿客户端未能保护资源,或者是
无法,保持其客户端凭据保密。

授权服务器必须时客户端进行身份验证
可能的。如果授权服务器无法验证客户端
由于客户的特性,授权服务器必须要求
任何重定向URI用于接收登记授权
反应,应利用其他手段来保护资源所有者
从这些潜在的恶意的客户。例如,
授权服务器可以进行资源所有者协助
识别客户端和它的起源。

授权服务器应该执行显式的资源所有者
身份验证和向资源所有者提供信息
客户端和请求的授权范围和生命周期。它是
资源所有者来审查的上下文中的信息
当前客户端和授权或拒绝请求。

授权服务器不应该处理重复授权
自动请求(不活跃的资源所有者交互)
没有对客户端进行身份验证或依赖其他措施
确保来自原来的客户和重复请求
不是一个冒名顶替者。

(54页)

10.3。访问令牌

访问令牌的凭证(以及任何机密访问令牌
属性)必须在运输和存储,保密
只有在授权服务器之间共享,资源服务器
访问令牌是有效的,和客户的访问令牌
发行。访问令牌的凭证只能传输使用TLS
如1.6节所述服务器身份验证所定义的
[RFC2818]。

当使用隐式授予类型、访问令牌传播
URI的片段,可以使未经授权的聚会。

授权服务器必须确保访问令牌不能
生成、修改、或猜测产生有效的访问令牌
未经授权的聚会。

客户应该请求访问令牌的最小范围
必要的。授权服务器应客户的身份
考虑在选择如何荣誉请求的范围和可能
问题一个权利小于请求的访问令牌。

本规范不提供任何资源的方法
服务器,以确保一个访问令牌交给给定
由授权服务器客户端发布到客户端。

10.4。刷新令牌

授权服务器可以刷新令牌的web应用程序
客户和本地应用程序客户端。

刷新令牌必须在运输和存储,保密
授权服务器和客户端之间共享只有人
刷新令牌发放。授权服务器必须维护
刷新令牌之间的绑定和客户端
发行。刷新令牌只能使用TLS作为传播
1.6节中描述与定义的服务器身份验证
[RFC2818]。

授权服务器必须验证之间的绑定更新
令牌和客户机身份每当客户端身份
身份验证。当客户机身份验证是不可能的,
授权服务器应该部署其他手段来检测刷新
令牌滥用。

例如,授权服务器可以使用刷新令牌
旋转的一个新的刷新令牌发出每一次访问
令牌刷新响应。前刷新令牌失效

(55页)

但保留由授权服务器。如果一个刷新令牌
妥协,随后由攻击者和使用
合法的客户端,其中一个将一个无效刷新
令牌,通知授权服务器的漏洞。

授权服务器必须确保不能刷新令牌
生成、修改、或猜测产生有效刷新令牌
未经授权的聚会。

10.5。授权码

授权码的传播应该在一个安全的
频道,客户端应该和它需要使用TLS
重定向URI URI标识网络资源。自
授权码是通过用户代理重定向传播,他们
通过用户代理可能会披露历史和HTTP
引用头文件。

授权码是明文无记名凭证,用于
验证资源所有者获得授权的
授权服务器资源所有者回到相同
客户端完成的过程。因此,如果客户依赖
自己的资源所有者的授权代码认证,
客户重定向端点必须需要使用TLS。

授权码必须是短暂的和一次性的。如果
授权服务器观察多个试图交换一个
授权代码访问令牌,授权服务器
应该试图撤销所有访问令牌已经授予根据
妥协授权代码。

如果可以对客户端进行身份验证,授权服务器必须
客户端进行身份验证,确保授权代码
发布相同的客户端。

10.6。授权代码重定向URI操纵

当请求授权使用授权代码
类型,客户端可以通过“redirect_uri”URI指定一个重定向
参数。如果攻击者可以操纵的价值
重定向的URI,它可以导致授权服务器重定向
资源所有者用户代理的URI的控制下
攻击者授权代码。

攻击者可以创建一个帐户在一个合法的客户端和启动
认证流程。当攻击者的用户代理发送
授权服务器授权访问,攻击者获取
授权合法的客户端提供的URI和替换

(56页)

客户的重定向URI URI的控制下
攻击者。攻击者然后技巧受害者到后
操作链接授权访问合法的客户端。

一旦在授权服务器,是促使受害者
正常的,代表一个合法有效的请求和信任的客户,
并授权请求。然后重定向到一个受害者
端点的控制下攻击者的授权
代码。攻击者发送完成认证流程
授权代码到客户端使用原来的重定向的URI
由客户提供。客户端交流授权代码
一个访问令牌和链接到攻击者的客户账户,
现在可以访问受保护的资源授权
受害者(通过客户端)。

为了防止这种攻击,授权服务器必须
确保重定向URI用于获得授权代码
当交换提供的重定向URI相同吗
授权代码访问令牌。授权服务器
必须要求公共客户,应该需要保密客户
登记他们的重定向uri。如果提供了重定向的URI
在请求,授权服务器必须对验证
注册的价值。

10.7。资源所有者密码凭据

资源所有者授予类型通常用于密码凭据
遗留或迁移的原因。它减少了存储的整体风险
用户名和密码由客户但不消除的需要
暴露高度特权凭证给客户端。

这种格兰特因为格兰特带来更高的风险比其他类型
它维护反模式的密码本议定书试图避免的。
客户端可以滥用的密码,或者密码
攻击者(如无意中被披露。或者,通过日志文件
其他由客户记录)。

此外,由于资源所有者没有控制
资源所有者的授权过程(介入时结束
它移交证书客户端),客户端可以获得
访问令牌和一个更广泛的范围比所期望的资源
所有者。应该考虑的范围和授权服务器
通过这种格兰特一生发行的访问令牌。

授权服务器和客户端应该减少使用这个格兰特
类型和尽可能地利用其他资助类型。

(57页)

10.8。要求保密

访问令牌,刷新令牌,资源所有者密码,和客户
凭证不得传播的清晰。授权
代码不应该传播的清晰。

“状态”和“范围”参数不应该包括敏感
客户或在纯文本资源所有者的信息,因为他们可以
不安全的通道上传输或存储上缺乏自信。

10.9。确保端点真实性

为了防止中间人攻击,授权
服务器必须需要使用TLS与服务器身份验证
(RFC2818)所定义的任何请求发送到授权和
令牌的端点。客户端必须验证授权服务器的
TLS(RFC6125)和定义的证书符合它
服务器身份验证的要求。

10.10。 Credentials-Guessing攻击

授权服务器必须防止攻击者猜测访问
令牌,授权码,刷新令牌,资源所有者
密码,和客户端凭据。

攻击者猜测的概率生成令牌(和其他
凭证不用于处理由最终用户)必须小于
或等于2 ^(-128)和应小于或等于2 ^(-160)。

授权服务器必须利用其他手段来保护
凭证供终端用户使用。

10.11。网络钓鱼攻击

广泛部署及类似的协议可能会导致最终用户
习以为常的做法被重定向到网站上
他们被要求输入密码。如果最终用户不
小心地进入之前验证这些网站的真实性
他们的凭证,攻击者可以利用这一点
实践窃取资源所有者的密码。

服务提供商应该试图对终端用户进行风险教育
钓鱼攻击姿势和应该提供机制,使它容易
为最终用户确认他们的网站的真实性。客户端
开发人员应该考虑他们如何的安全影响
与用户代理(如互动。、外部嵌入),
最终用户的验证能力的真实性
授权服务器。

(58页)

为了减少网络钓鱼攻击的风险,授权服务器
必须需要使用TLS在每个端点用于终端用户
交互。

10.12。跨站点请求伪造

跨站请求伪造(CSRF)是一个攻击者利用
导致用户代理的受害者最终用户遵守一个恶意的URI
(如。 ,提供给用户代理作为一个误导性的链接,图片,或者
重定向)服务器(通常是通过建立信任
存在一个有效的会话cookie)。

CSRF攻击客户端的重定向URI允许攻击者
注入自己的授权代码或访问令牌,可以
导致客户端相关使用一个访问令牌
攻击者的受保护的资源,而不是受害者的(如。 ,保存
受害者的银行账户信息,一个受保护的资源
攻击者控制的)。

客户端必须实现CSRF保护重定向的URI。
这通常是通过要求任何请求发送到
重定向URI端点绑定请求包含一个值
(如用户代理的认证状态。哈希的会话
饼干用于验证用户代理)。客户端应
利用“状态”请求参数将这个值
授权服务器时授权请求。

一旦从终端用户,获得授权
授权服务器将用户重定向用户代理回
客户所需的绑定值包含在“状态”
参数。绑定值允许客户端验证
效度的请求匹配的绑定值
用户代理的认证状态。用于CSRF绑定值
保护必须包含一个non-guessable值(如中描述
10.10节)和用户代理的认证状态(例如,
会话cookie,HTML5本地存储)必须保存在一个位置
只有客户端和用户代理(即。 ,保护
同源策略)。

CSRF攻击授权服务器的授权
端点可能导致攻击者获取用户授权
一个恶意的客户没有涉及或报警终端用户。

授权服务器必须实现CSRF保护它
授权端点并确保恶意客户端不能
获得授权没有意识和明确的同意
资源所有者。

(59页)

10.13。 “点击劫持”

“点击劫持”的攻击中,攻击者会注册一个合法的客户端
然后构造一个恶意网站的加载
授权服务器的授权端点web页面
透明的iframe覆盖上一组虚拟按钮,
精心构造是直接放置在重要
按钮在授权页面。当一个终端用户的点击
误导可见按钮时,用户点击一个
无形的按钮在授权页面(如一个“授权”
按钮)。这允许攻击者欺骗一个资源所有者
给予客户访问终端用户不知情的情况下。

为了防止这种形式的攻击,本机应用程序应该使用
外部浏览器而不是嵌入浏览器内
当请求用户授权的应用程序。对于大多数新
浏览器,避免iframes可以执行授权
服务器使用(非标) “x-frame-options”头。这
标题可以有两个值,“拒绝”和“sameorigin”,这将阻止
任何框架或框架的网站有不同的起源,
分别。对老版本浏览器的JavaScript frame-busting
技术可以使用但可能不是有效的在所有的浏览器。

10.14。代码注入和输入验证

代码注入攻击发生在一个输入或外部
变量使用一个应用程序unsanitized和原因
修改应用程序逻辑。这可能允许攻击者
获取应用程序的设备或其数据,导致拒绝
服务或引入一个广泛的恶意的副作用。

授权服务器和客户端必须清洁(和验证
可能)收到的任何值——特别是,的值
“状态”和“redirect_uri”参数。

10.15。开放的转向器

授权服务器授权端点和客户端
重定向端点可以作为开放配置和操作不当
转向器。一个开放的转向器是一个端点使用参数
自动重定向用户代理指定的位置
参数值没有任何验证。

开放转向器可用于网络钓鱼攻击,或由攻击者
让终端用户访问恶意网站通过使用URI的权威
组件的熟悉和信任的目的地。此外,如果
授权服务器只允许客户端注册的一部分
重定向的URI,攻击者可以使用一个开放的转向器由

(60页)

客户端通过构造一个重定向的URI
授权服务器验证,但将发送授权代码
或访问令牌端点攻击者的控制下。

10.16。滥用访问令牌在隐式扮演资源所有者
流

为公共客户使用隐式流动,这个规范没有
为客户提供任何方法来确定客户端访问
令牌了。

资源所有者可以自愿委托访问的资源
授予一个攻击者的恶意客户端访问令牌。这可能
是由于网络钓鱼或其他的借口。攻击者也可以偷
一个令牌通过其他机制。攻击者可能会尝试
模拟资源所有者通过提供一个访问令牌
合法的公共端。

在隐式流(response_type =令牌),攻击者可以很容易的
开关的令牌授权服务器的响应,
取代真正的与之前发布的访问令牌
攻击者。

服务器与本地应用程序依赖于交流
通过反向信道的访问令牌来识别用户
客户端可能同样被攻击者创建一个
妥协可以注入任意偷来访问应用程序
令牌。

任何公共端,使假设只有资源
所有者可以将它与一个有效的资源的访问令牌
容易受到这种类型的攻击。

这种类型的攻击可以公开的信息资源所有者
在合法的客户端攻击者(恶意客户端)。这
还将允许攻击者在合法的执行操作吗
客户端与相同的权限资源所有者最初
授予访问令牌或授权代码。

验证客户资源所有者的范围
规范。使用授权的任何规范的过程
作为一种委托终端用户身份验证的客户端(例如,
第三方登录服务)不得使用隐式流
额外的安全机制,使客户端
确定访问令牌的使用(如发布。观众,
限制访问令牌)。

(61页)

11。 IANA的考虑

11.1。 OAuth访问令牌类型注册表

本规范建立了OAuth访问令牌类型注册表。

访问令牌类型注册规范要求
([RFC5226])两周后的审核期
oauth-ext-review@ietf.org邮件列表,在一个或更多的建议
指定的专家。然而,允许的分配值
在出版之前,指定专家(s)可能会批准
注册一旦满足这样一个规范
出版了。

注册请求必须被发送到oauth-ext-review@ietf.org
审查和评论的邮件列表,一个合适的主题
(如。 ”,请求访问令牌类型:榜样”)。

在审查期间,指定的专家(s)要么
批准或拒绝注册请求,这个决定进行沟通
到评论列表和IANA。否认应该包括一个解释
如果适用,建议如何使请求
成功的。

IANA必须只接受从指定的专家(s)注册表更新
而且应该直接登记的所有请求检查邮件
列表。

11.1.1。注册模板

类型名称:
请求的名称(如。 “示例”)。

额外的令牌端点响应参数:
额外的响应参数一起返回
“access_token”参数。新的参数必须分开
注册在OAuth参数注册表中所描述的
11.2节。

HTTP身份验证方案(s):
HTTP身份验证方案名称(s),如果有的话,
使用访问受保护的资源请求进行身份验证令牌
这一类型。

改变控制器:
跟踪rfc标准,国家“IETF”。对另一些人来说,给这个名字
负责任的政党。其他细节(如。邮寄地址,
电子邮件地址,主页URI)也可能包括在内。

(62页)

规范文档(s):
参考文档(s)指定参数,
最好包括一个URI,它可以用来检索的一个副本
文档(s)。也可能表明相关的部分
被包括但不是必需的。

11.2。 OAuth参数注册表

本规范建立了OAuth注册表参数。

额外的参数包含在授权端点
请求,授权端点响应,令牌端点
请求,或令牌端点响应与一个注册
规范要求([RFC5226])两周后审核期
oauth-ext-review@ietf.org邮件列表,在一个或的建议
指定的专家。然而,允许的分配
值在出版之前,指定的专家(s)可能会批准
注册一旦满足这样一个规范
出版了。

注册请求必须被发送到oauth-ext-review@ietf.org
审查和评论的邮件列表,一个合适的主题
(如。请求参数:示例”)。

在审查期间,指定的专家(s)要么
批准或拒绝注册请求,这个决定进行沟通
到评论列表和IANA。否认应该包括一个解释
如果适用,建议如何使请求
成功的。

IANA必须只接受从指定的专家(s)注册表更新
而且应该直接登记的所有请求检查邮件
列表。

11.2.1。注册模板

参数名称:
请求的名称(如。 “示例”)。

参数的使用地点:
(s)的位置,可以使用参数。可能的
位置是授权请求,授权响应,令牌
请求,或令牌响应。

改变控制器:
跟踪rfc标准,国家“IETF”。对另一些人来说,给这个名字
负责任的政党。其他细节(如。邮寄地址,
电子邮件地址,主页URI)也可能包括在内。

(63页)

规范文档(s):
参考文档(s)指定参数,
最好包括一个URI,它可以用来检索的一个副本
文档(s)。也可能表明相关的部分
被包括但不是必需的。

11.2.2。初始注册表内容

OAuth注册表参数的初始内容有:

o参数名称:client_id
o参数使用地点:授权请求,请求令牌
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:client_secret
o参数使用地点:令牌的请求
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:response_type
o参数使用地点:授权请求
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:redirect_uri
o参数使用地点:授权请求,请求令牌
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:范围
o参数使用地点:授权请求,授权
反应,请求令牌,令牌响应
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:状态
o参数使用地点:授权请求,授权
响应
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:代码
o参数使用地点:授权响应,令牌的请求
o改变控制器:IETF
o规范文档(s):RFC 6749

(64页)

o参数名称:error_description
o参数使用地点:授权响应,令牌的回应
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:error_uri
o参数使用地点:授权响应,令牌的回应
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:grant_type
o参数使用地点:令牌的请求
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:access_token
o参数使用地点:授权响应,令牌的回应
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:token_type
o参数使用地点:授权响应,令牌的回应
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:expires_in
o参数使用地点:授权响应,令牌的回应
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名:用户名
o参数使用地点:令牌的请求
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名:密码
o参数使用地点:令牌的请求
o改变控制器:IETF
o规范文档(s):RFC 6749

o参数名称:refresh_token
o参数使用地点:请求令牌,令牌响应
o改变控制器:IETF
o规范文档(s):RFC 6749

(65页)

11.3。 OAuth授权端点响应类型注册表

本规范建立了OAuth授权端点
响应类型注册表。

额外的响应类型与授权终端使用
注册一个规范要求([RFC5226])两周后
审核期在oauth-ext-review@ietf.org邮件列表,
指定一个或多个专家的建议。然而,允许的
分配的值在出版之前,指定的专家(s)
可能批准注册一旦满足这样的吗
规范将发表。

注册请求必须被发送到oauth-ext-review@ietf.org
审查和评论的邮件列表,一个合适的主题
(如。 “请求响应类型:榜样”)。

在审查期间,指定的专家(s)要么
批准或拒绝注册请求,这个决定进行沟通
到评论列表和IANA。否认应该包括一个解释
如果适用,建议如何使请求
成功的。

IANA必须只接受从指定的专家(s)注册表更新
而且应该直接登记的所有请求检查邮件
列表。

11.3.1。注册模板

响应类型名称:
请求的名称(如。 “示例”)。

改变控制器:
跟踪rfc标准,国家“IETF”。对另一些人来说,给这个名字
负责任的政党。其他细节(如。邮寄地址,
电子邮件地址,主页URI)也可能包括在内。

规范文档(s):
引用指定类型的文件(s),最好
包括一个URI,可用于检索的一个副本
文档(年代)。也可能表明相关的部分
包括但不是必需的。

(66页)

11.3.2。初始注册表内容

OAuth授权端点注册中心的最初反应类型
内容是:

o响应类型名称:代码
o改变控制器:IETF
o规范文档(s):RFC 6749

o响应类型名称:令牌
o改变控制器:IETF
o规范文档(s):RFC 6749

11.4。 OAuth扩展注册表错误

本规范建立了OAuth扩展注册表错误。

额外的错误代码一起使用与其他协议扩展
(即。、扩展授予类型访问令牌类型,或扩展
注册参数)规范要求([RFC5226])
审核期两周后在oauth-ext-review@ietf.org
邮件列表,在一个或多个指定专家的建议。
然而,允许分配的值在出版之前,
指定的专家(s)可能批准登记一次
满足这样的规范将发表。

注册请求必须被发送到oauth-ext-review@ietf.org
审查和评论的邮件列表,一个合适的主题
(如。错误代码:请求示例”)。

在审查期间,指定的专家(s)要么
批准或拒绝注册请求,这个决定进行沟通
到评论列表和IANA。否认应该包括一个解释
如果适用,建议如何使请求
成功的。

IANA必须只接受从指定的专家(s)注册表更新
而且应该直接登记的所有请求检查邮件
列表。

(67页)

11.4.1。注册模板

错误的名字:
请求的名称(如。 “示例”)。值错误的名字
必须不包括字符以外的% % x23-5B x20-21 / /
% x5D-7E。

错误的使用地点:
的位置(s)可以使用错误。可能的
位置是授权代码授予错误响应
4.1.2.1(部分),隐式授予错误响应
4.2.2.1(部分),令牌错误响应(5.2节),或资源
访问错误响应(7.2节)。

相关协议的扩展:
扩展的名称授予类型、访问令牌类型,或
扩展参数错误代码一起使用
与。

改变控制器:
跟踪rfc标准,国家“IETF”。对另一些人来说,给这个名字
负责任的政党。其他细节(如。邮寄地址,
电子邮件地址,主页URI)也可能包括在内。

规范文档(s):
参考文档(s)指定错误代码,
最好包括一个URI,它可以用来检索的一个副本
文档(s)。也可能表明相关的部分
被包括但不是必需的。

12。引用

12.1。引用标准

(RFC2119)他。 ”关键字用于rfc指示
RFC 2119要求的水平”,BCP 14日,1997年3月。

RFC2246迪克斯,t·c·艾伦,“TLS协议1.0版”,
RFC 2246,1999年1月。

[RFC2616]菲尔丁,R。盖,J。大亨,J。 Frystyk,H。
masint,L。 Leach,P。超文本,t·伯纳斯·李。
传输协议——HTTP / 1.1”,RFC 2616,1999年6月。

RFC2617法兰克人,J。 Hallam-Baker,P。 Hostetler,J。劳伦斯,S。
Leach,P。 Luotonen,。 l·斯图尔特,HTTP
身份验证:基本和消化访问认证”,
RFC 2617,2617年6月。

(68页)

RFC2818 Rescorla,E。 “HTTP / TLS”,RFC 2818,2818年5月。

RFC3629 Yergeau,F。 utf - 8,转换的格式
ISO 10646“,10646年性病,RFC 3629,2003年11月。

RFC3986 berners - lee,T。菲尔丁,R。和l . masint”制服
资源标识符(URI):通用语法”,66年性病,
RFC 3986,2005年1月。

RFC4627 Crockford,D。 application / json,“媒体类型
JavaScript对象表示法(JSON) ”,RFC 4627,2006年7月。

RFC4949 Shirey说,R。 “网络安全术语表,版本2”,
RFC 4949,4949年8月。

RFC5226 Narten,t·h·Alvestrand,“编写一个指南
在RFC IANA考虑节”,BCP 26日RFC 5226,
2008年5月。

RFC5234克罗克,d . p . Overell,“增强BNF语法
规格:ABNF”,68年性病,RFC 5234,2008年1月。

RFC5246迪克斯,t和大肠Rescorla传输层安全性
1.2”(TLS)协议版本,RFC 5246,2008年8月。

RFC6125 Saint-Andre,和p·j·霍奇斯,”表示
域的应用程序服务的身份验证
在互联网使用x .公钥基础设施
(PKIX)证书在传输层的上下文中
安全性(transport layer Security,TLS) ”,RFC 6125,2011年3月。

(USASCII)美国国家标准研究所”编码字符
设置——7位美国标准信息
交换”,ANSI X3.4,1986。

(w3c.rec - html401 - 19991224)
Raggett D。 Le开胃,。 HTML 4.01,雅各布斯,”
规范”,万维网联盟
建议rec - html401 19991224,1999年12月,
< http://www.w3.org/tr/1999/rec - html401 http://www.w3.org/tr/1999/rec >。

(w3c.rec - xml - 20081126)
布雷,T。 Paoli,J。 Sperberg-McQueen C。梅勒尔,E。
和f . Yergeau”,可扩展标记语言(XML)1.0
(第五版) ”,万维网联盟
建议rec - xml - 20081126,2008年11月,
< http://www.w3.org/tr/2008/rec - xml - 20081126 >。

(69页)

12.2。有益的参考

(OAuth-HTTP-MAC)
Hammer-Lahav E。 Ed,“HTTP身份验证:MAC访问
身份验证”,正在进行的工作,2012年2月。

(OAuth-SAML2)
坎贝尔,b和c . Mortimore SAML 2.0无记名断言
OAuth 2.0概要”,正在进行的工作,2012年9月。

(OAuth-THREATMODEL)
Lodderstedt,T。 ,McGloin。M。 OAuth 2.0,p .狩猎。
威胁模型和安全方面的考虑”,工作
在进步,2012年10月。

(OAuth-WRAP)
哈特,D。 Ed,汤姆,一个。伊顿,B。 OAuth,y Goland。
网络资源授权配置文件”,正在进行的工作,
2010年1月。

寒莫拉赫吾(RFC5849),E。 “OAuth 1.0协议”,RFC 5849,
2010年4月。

RFC6750琼斯,m·d·哈特,“OAuth 2.0授权
框架:不记名使用令牌”,RFC 6750,2012年10月。

(70页)

附录a .增强Backus-Naur形式(ABNF)语法

本节提供增强Backus-Naur形式(ABNF)语法
描述本规范中定义的元素使用
符号(RFC5234)。定义以下ABNF Unicode
代码点[w3c.rec - xml - 20081126); 这些人物通常
在utf - 8编码。元素的顺序提出了第一个定义。

后面的一些定义,使用“uri引用”
定义从[RFC3986]。

的一些定义遵循使用这些常见的定义:

VSCHAR = % x20-7E
NQCHAR = % x21 / % x23-5B / % x5D-7E
NQSCHAR = % x20-21 / % x23-5B / % x5D-7E
UNICODECHARNOCRLF = % x09 / % x20-7E / % x80-D7FF /
% xE000-FFFD / % x10000-10FFFF

(UNICODECHARNOCRLF定义是基于字符的定义
[W3C的2.2节。 rec - xml - 20081126],但省略马车
返回和换行字符。)

. 1。 “client_id”语法

2.3.1节中定义的“client_id”元素是:

客户机id = * VSCHAR

由信用证。 “client_secret”语法

2.3.1节中定义的“client_secret”元素是:

端秘密= * VSCHAR

出具。 “response_type”语法

3.1.1“response_type”元素中定义部分和8.4:

响应类型= response-name *(SP response-name)
response-name = 1 * response-char
response-char = " _ " /数字/α

(71页)

各。 “范围”语法

3.3节中定义的“范围”元素是:

范围= scope-token *(SP scope-token)
scope-token = 1 * NQCHAR

本。 “状态”的语法

“状态”元素中定义部分以下4.4.1,4.1.2,4.1.2.1,
4.2.1,准备4.2.2,4.2.2.1:

= 1 * VSCHAR状态

要求寄出。 “redirect_uri”语法

“redirect_uri”元素中定义部分以下4.4.1,4.1.3,
和4.2.1:准备

redirect-uri = uri引用

A.7。 “错误”的语法

“错误”中定义的元素部分4.1.2.1 4.2.2.1,5.2,
7.2和8.5:

= 1 * NQSCHAR错误

如系。 “error_description”语法

“error_description”元素中定义部分4.1.2.1,
4.2.2.1、5.2和7.2:

错误描述= 1 * NQSCHAR

A.9。 “error_uri”语法

“error_uri”元素中定义部分4.1.2.1 4.2.2.1,5.2,
和7.2:

error-uri = uri引用

(72页)

A.10。 “grant_type”语法

“grant_type”元素中定义部分4.1.3 4.3.2,10/24/11,
4.5,6:

grant-type = grant-name / uri引用
grant-name = 1 * name-char
name-char =“-”/”。 “/”_”/数字/α

A.11。 “代码”语法

4.1.3节中定义的“代码”元素是:

= 1 * VSCHAR代码

A.12。 “access_token”语法

4.2.2 access_token”元素中定义部分和5.1:

访问令牌= 1 * VSCHAR

A.13。 “token_type”语法

4.2.2 token_type”元素中定义部分,5.1,和8.1:

令牌类型=类型名称/ uri引用
类型名称= 1 * name-char
name-char =“-”/”。 “/”_”/数字/α

A.14。 “expires_in”语法

4.2.2 expires_in”元素中定义部分和5.1:

将于= 1 *位

所以。 “用户名”语法

4.3.2节中定义的“用户名”元素是:

用户名= * UNICODECHARNOCRLF

A.16。 “密码”语法

4.3.2节中定义的“密码”元素是:

密码= * UNICODECHARNOCRLF

(73页)

A.17。 “refresh_token”语法

“refresh_token”元素定义在章节5.1和6:

refresh-token = 1 * VSCHAR

A.18。端点参数语法

新的端点的语法参数在8.2节中定义:

param-name = 1 * name-char
name-char =“-”/”。 “/”_”/数字/α

附录b .使用应用程序/ x-www-form-urlencoded媒体类型

本规范在刚出版的时候,
“应用程序/ x-www-form-urlencoded”媒体类型中定义
部分17.13.4[W3C。 rec - html401 - 19991224]但不能注册
注册表的IANA MIME媒体类型
(< http://www.iana.org/assignments/media-types >)。此外,,
定义是不完整的,因为它没有考虑non-US-ASCII
字符。

为克服此缺点当生成使用这个媒体的有效载荷
类型、名称和值必须使用utf - 8字符编码
编码方案(RFC3629); 由此产生的八位字节序列
需要进一步使用转义编码规则中定义
[w3c.rec - html401 - 19991224]。

当解析的数据负载使用这个媒体类型,名称和
值产生的扭转名称/值编码结果
需要被视为八隅体序列,使用utf - 8编码解码
字符编码方案。

例如,值组成的六个Unicode代码点
(1)U + 0020(空间),(2)U + 0025(百分号)
(3)U + 0026(&),(4)U + 002 b(加号),
(5)U + 00 a3(井号)和(6)U + 20 ac(欧元标志)将编码
到下面的八位字节序列(使用十六进制符号):

82年20 25 26日2 b C2 A3 E2 AC

然后在有效载荷为:

+ % 2 b % C2%A3%E2 % 25% 25% 25% ac

(74页)

附录c .确认

最初的OAuth 2.0协议规范编辑大卫
瑞克丹,基于前两个出版物:OAuth 1.0社区
规范[RFC5849],OAuth包装(OAuth Web资源
授权概要文件)[OAuth-WRAP]。伊兰锤然后编辑很多
中间的草稿,演变成这个RFC。安全
考虑部分被Torsten Lodderstedt起草,马克
McGloin,菲尔·亨特,安东尼Nadalin,约翰布拉德利。一节
在使用“应用程序/ x-www-form-urlencoded”媒体类型
由朱利安Reschke起草。 ABNF部分起草了迈克尔
b·琼斯。

OAuth 1.0社区规范被伊兰锤子和编辑
由马克•阿特伍德Dirk Balfanz,达伦,理查德M。
Conlan,布莱恩做饭,利亚斑鸠,Breno de Medeiros布莱恩·伊顿
凯兰Elliott-McCrea,拉里·哈尔伊兰锤,本劳丽,克里斯
墨西拿,约翰装甲,萨姆•奎格利大卫。瑞克丹伊兰桑德勒
Brian Slesinsky托德Sieling乔纳森•中士和安迪·史密斯。

OAuth包装规范被迪克哈特和由编辑
布莱恩·伊顿Yaron y Goland,迪克·哈特,汤姆和艾伦。

这个规范是OAuth工作组的工作,
包括许多活跃的和专用的参与者。特别是,
以下个人贡献的想法,反馈,和措辞
塑造和形成最终的规格:

迈克尔·亚当斯,阿曼达Anganes安德鲁•阿诺特Dirk Balfanz,艾登
钟,约翰·布拉德利,马科斯卡塞雷斯,布莱恩·坎贝尔,斯科特•康托尔
布莱恩做饭,罗杰船员,利亚斑鸠,比尔·德·赫拉,安德烈的学习,
布莱恩·伊顿韦斯利艾迪,沃尔特长老,布莱恩Ellin,伊戈尔
蒂姆•弗里曼Faynberg乔治·弗莱彻卢卡Frosini,埃文·吉尔伯特,
Yaron y Goland,布伦特高盛,摩挲Gronowski,伊兰锤,
迪克哈特,贾斯汀哈特,克雷格•希思菲尔·亨特,迈克尔·b·琼斯,
琼斯,约翰·坎普,马克·肯特的Raffi Krikorian,Chasen Le Hara
拉姆Lerdorf、Torsten Lodderstedt Hui-Lan,凯西·卢卡斯,保罗
马德森,阿拉斯泰尔•其余的夏娃梅勒尔,詹姆斯•经理Mark McGloin
劳伦斯苗,威廉·米尔斯,查克•Mortimore安东尼•Nadalin
朱利安•Reschke贾斯汀富裕,彼得•Saint-Andre Nat Sakimura,抢劫
塞尔马吕斯Scurtescu Naitik Shah,卢克谢泼德,弗拉德。斯克沃尔佐夫,
贾斯汀·史密斯,海滨的歌,和合Steingarten,基督教Stuebner
杰里米•Suriel保罗Tarjan,亨利·s·汤普森,克里斯托弗•托马斯
艾伦汤姆,富兰克林谢霆锋,肖恩·威登,Skylar尼克•沃克
伍德沃德。

(75页)

这个文档是布莱恩的主席下做饭,
Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins.
The area directors included Lisa Dusseault, Peter Saint-Andre, and
Stephen Farrell.

Author's Address

Dick Hardt (editor)
Microsoft

EMail: dick.hardt@gmail.com
URI: http://dickhardt.org/

[Page 76]

posted @ 2017-10-12 01:49 Endv 阅读(1450) 评论(0) 编辑收藏举报

刷新页面返回顶部

C# java C++ 开源通信

OAuth 2.0 RFC 框架中文

公告

C# java C++ 开源通信

OAuth 2.0 RFC 框架 中文

公告

OAuth 2.0 RFC 框架中文