首页 > 代码库 > 【rfc6749】机翻 The OAuth 2.0 Authorization Framework
【rfc6749】机翻 The OAuth 2.0 Authorization Framework
本文禁止转载
原文地址 http://tools.ietf.org/html/rfc6749
下面内容全部是谷歌娘的翻译 = = ，写这个的目的是给自己留个备份，这样就不用每次打开谷歌娘了。
------------------------- 机翻的分割线 ----------------------------------------
OAuth的2.0授权框架
抽象
OAuth的2.0授权框架允许第三方
应用程序获取有限的访问HTTP服务，无论是在
代表的资源所有者通过编排批准互动
资源所有者和HTTP服务之间，或者通过使
第三方应用程序，以获得以自己的名义访问。此
规范取代并淘汰了1.0协议描述的OAuth
在RFC5849。
本备忘录状态
这是一个互联网标准跟踪文档。
这份文件是互联网工程任务组的产物
（IETF）。它代表了IETF社会的共识。它有
接受公众审查，并已批准发布的
互联网工程指导小组（IESG）。更多相关信息
Internet标准是在RFC5741中第2节可用。
这个文档的当前状态信息，任何勘误表，
以及如何提供反馈，它可在获得
http://www.rfc-editor.org/info/rfc6749。
版权声明
版权所有（c）2012 IETF信托认定为人员
文档作者。版权所有。
这份文件是受BCP78和IETF信托的法律
与IETF文档的规定
（http://trustee.ietf.org/license-info）在之日起施行
本文件发布。请查看这些文件
小心，因为他们描述就您的权利和限制
本文件。代码组件从这个文件中提取一定
包括在第4.E描述简体BSD许可证文本
提供信托法律规定，不保证
在简化的BSD许可证描述。
1.简介
在传统的客户机 - 服务器认证模型中，客户端
上的请求访问被限制的资源（受保护的资源）
服务器通过使用与服务器进行认证的资源主人的
凭据。为了提供第三方应用程序访问
有限资源，资源所有者分享其凭据
第三方。这就造成一些问题和局限性：
?第三方应用程序都需要存储资源
供将来使用所有者的凭证，通常在一个密码
明文。
O服务器需要支持密码验证，尽管
安全弱点与生俱来的密码。
?第三方应用程序获得过宽对资源的访问
业主的受保护的资源，使资源拥有者没有任何
限制持续时间或访问的有限子集的能力
资源。
O资源拥有者不能撤销访问单个第三方
没有撤销访问所有的第三方，且必须这样做了
改变第三方的密码。
在妥协的任何第三方应用效果?妥协
最终用户的密码，并全部由该受保护的数据的
密码。
OAuth的通过引入一个授权层解决了这些问题
并从该资源的分离的客户端的角色
所有者。在OAuth的，客户端请求访问控制的资源
由资源所有者和托管由资源服务器，并且是
发出一组不同的凭证比那些资源的
所有者。
而不是使用资源所有者的凭证来访问受保护
资源，客户端获得访问令牌 - 一个字符串表示一个
具体范围，寿命和其他访问属性。访问令牌
通过授权服务器与发给第三方客户端
审批资源所有者。客户端使用的访问令牌
访问由资源服务器托管的受保护的资源。
例如，最终用户（资源所有者）可以授予打印
存储在光电服务（客户端）访问受保护她的照片
共享服务（资源服务器），没有分享她的用户名和
密码与打印服务。相反，她验证
直接与由照片共享服务信任的服务器
（授权服务器），其中发出打印服务delegation-
特定的凭证（访问令牌）。
该规范是专为使用HTTP（[RFC2616]）。该
使用OAuth的超比HTTP以外的任何协议是超出范围。
OAuth的1.0协议（[RFC5849]），已作为一个信息
文件，是一个小型特设社区努力的结果。此
标准跟踪规范建立的OAuth的1.0部署
经验，以及额外的用例和可扩展
要求聚集在更广泛的IETF社区。 OAuth的2.0
协议不向下兼容的OAuth1.0。两个版本
在网络上可以共存，并实现可以选择
同时支持。然而，这是本说明书的意图
新的实现支持的OAuth2.0在本规定
文件和OAuth的1.0仅用于支持现有
部署。 OAuth的2.0协议股份很少实施
与1.0的OAuth协议的细节。实施者熟悉
OAuth的1.0应该接近这个文件没有任何假设为
它的结构和细节。
1.1。角色
OAuth的定义四种角色：
资源拥有者
能够准许访问受保护资源的实体。
当该资源的所有者是一个人，它被称作为
最终用户。
资源服务器
服务器托管的受保护的资源，能够接受的
和响应使用访问令牌保护的资源请求。
客户
使受保护的资源请求代表的应用
资源所有者和其授权。术语“客户”呢
并不意味着任何特定的实现的特性（例如，
服务器，桌面，或其它关于是否应用程序执行
设备）。
授权服务器
服务器发出的访问令牌给客户端成功后
验证该资源的所有者，并获得授权。
授权服务器和资源服务器之间的交互
超出了本说明书的范围。授权服务器
可以是相同的服务器资源的服务器或单独的实体。
单个授权服务器可通过发出接受访问令牌
多个资源服务器。
1.2。协议流
+--------++---------------+
| | - （A） - 授权申请 - >|资源|
| | |业主|
| |< - （B） - 授权格兰特---| |
| | +--------+
| |
| | +--------+
| | - （C） - 授权格兰特 - >|授权|
|客户| |服务器|
| |< - （D）-----访问令牌-------| |
| | +--------+
| |
| | +--------+
| | - （E）-----访问令牌------>|资源|
| | |服务器|
| |< - （F） - 受保护的资源---| |
+--------++---------------+
+--------+ +---------------+
| |--(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中示出的抽象的OAuth2.0流程描述的
四种角色之间的相互作用，包括以下步骤：
（A）的客户端从资源所有者请求授权。该
授权请求可以直接向资源所有者
（如图所示），或优选地通过间接的授权
服务器作为中介。
（二）客户端收到授权金，这是一种
凭证代表了资源所有者的授权，
表达使用在此的4批类型之一定义
说明书或使用扩展许可类型。该
授权许可类型取决于所使用的方法
客户端请求的授权和由所支持的类型
授权服务器。
（C）客户端通过与认证请求的访问令牌
授权服务器和提出的授权金。
（D）中的授权服务器的客户端，并验证认证
授权拨款，如果有效，发出一个访问令牌。
（E）的客户端请求保护的资源从资源
服务器进行身份验证通过提出访问令牌。
（F）的资源服务器验证的访问令牌，如果有效，
处理请求。
优选的方法为客户端获得授权许可
从资源所有者（在工序（A描绘）和（B））是使用
授权服务器作为中介，其示出在
图3中的第4.1节。
1.3。授权授予
授权授予是代表资源凭证
所有者的授权（访问其受保护的资源）的使用
客户端获得一个访问令牌。该规范定义了四种
授予类型 - 授权码，含蓄，资源所有者的密码
凭据，和客户端证书 - 以及一个可扩展
机制来定义其他类型。
1.3.1。授权码
通过使用授权服务器获得授权码
作为客户端和资源的所有者之间的中介。而不是
直接从资源所有者请求授权，则客户端
指示资源所有者授权服务器（通过其
如[RFC2616]中定义用户代理），这反过来又指示
资源所有者回到与授权码的客户端。
前引导资源所有者返回给客户端与
授权代码，授权服务器认证该
资源所有者成于授权。因为资源所有者
仅验证与授权服务器，该资源
老板的凭据从不与客户共享。
该授权码提供了一些重要的安全利益，
如验证客户端的能力，以及在
传输的接入令牌直接向客户端，而不
通过资源所有者的用户代理和潜在的传递
其暴露给其他人，包括资源的所有者。
1.3.2。含蓄
隐式基金是一个简化的授权码流优化
对于使用脚本语言，例如在浏览器中实现的客户端
如JavaScript。在隐式流动，而不是发出所述客户
授权码，客户端直接发出的访问令牌
（作为资源所有者授权的结果）。补助类型
是隐含的，因为没有中间凭证（如授权
代码）发行（后来用于获取一个访问令牌）。
当隐授予流时发出的访问令牌，该
授权服务器不验证客户端。在一些
情况下，客户身份可以通过重定向的URI进行验证
用于访问令牌传递给客户端。可访问令牌
暴露于该资源的所有者或其它的应用程序能够访问
资源所有者的用户代理。
隐性补助提高一些反应能力和效率
客户端（例如实施为在浏览器应用程序中的客户端），
因为它减少，以获得所需的往返行程的数目
访问令牌。然而，这种便利性应该对称重
使用隐式授予的安全隐患，如
在第10.3和10.16中描述，尤其是当
授权码授予类型可用。
1.3.3。资源所有者密码凭据
资源所有者密码凭据（即用户名和密码）
可直接使用作为授权授予，得到存取
令牌。当有一个高的凭据，才应使用
信任的资源所有者和客户端之间的程度（例如，在
客户端设备的操作系统或高权限的一部分
应用程序），并且当其它授权授予类型不
可供选择的（如一个授权代码）。
尽管这笔款项类型要求的直接客户端访问
资源所有者凭证，资源所有者凭证使用
对于单个请求和被交换为访问令牌。此
授予类型可以无需在客户端存储
资源所有者证书以供将来使用，通过交换
具有长寿命的访问令牌或凭证刷新令牌。
1.3.4。客户端证书
客户端证书（或其他形式的客户端身份验证）可以
作为一个授权授予当授权范围
在客户端的控制下，限制在受保护的资源，
或受保护资源的预先布置成与授权
服务器。客户端凭据作为一个授权授予
通常当客户端代理代表自己（客户端
还资源所有者）或请求访问受保护的
基于授权资源预先布置成与
1.4。访问令牌
访问令牌是用于访问受保护的资源的凭据。一个
访问令牌是代表发出的授权字符串
客户端。字符串通常是不透明的到客户端。令牌
代表特定范围和访问时长，授予
资源所有者，并强制执行资源服务器和授权
服务器。
令牌可以表示用于检索授权的标识符
信息，或可以自包含在一个授权信息
可核实的方式（即由一些数据和一个令牌字符串
签字）。附加身份验证凭据，这是超越
本说明书的范围中，可能需要为使
客户端使用的令牌。
访问令牌提供了一个抽象层，更换不同
授权构建体（例如，用户名和密码）与单个
由资源服务器令牌理解。这种抽象使得
发出访问令牌比授权授予限制性更强
用于获得它们，以及消除资源服务器的需要
理解各种各样的认证方法。
访问令牌可以具有不同的格式，结构和方法
利用率（例如，加密属性）基于所述资源
服务器的安全性要求。访问令牌属性和
用于访问受保护的资源的方法，超出的范围
本说明书和由同伴等规格定义
如[RFC6750]。
1.5。刷新令牌
刷新令牌来获得访问令牌的凭据。刷新
令牌由授权服务器向客户机发出，并且
用于获得一个新访问令牌时当前接入令牌
变得无效或过期，或获得额外的访问令牌
具有相同或更窄的范围（接入令牌可以具有更短的
使用寿命比授权资源较少的权限
所有者）。发出刷新令牌是在可选的自由裁量权
授权服务器。如果授权服务器发出刷新
令牌，则发出一个访问令牌（即，步骤（D）中，当包含
图1）。
刷新令牌是表示要授予权限的字符串
客户通过该资源的所有者。该字符串通常是不透明
客户端。令牌表示用于检索的标识符
授权信息。不同于访问令牌，令牌刷新的
旨在仅与授权服务器并不会发送
资源服务器。
+--------++---------------+
| | - （A）-------授权授予--------->| |
| | | |
| |< - （B）-----------访问令牌-------------| |
| |＆刷新令牌| |
| | | |
| | +----------+| |
| | - （C）----访问令牌---->| | | |
| | | | | |
| |< - （D） - 受保护的资源 - |资源| |授权|
|客户| |服务器| |服务器|
| | - （E）----访问令牌---->| | | |
| | | | | |
| |< - （F） - 无效的令牌错误 - | | | |
| | +----------+| |
| | | |
| | - （G）-----------刷新令牌----------->| |
| | | |
| |< - （H）-----------访问令牌-------------| |
+--------+可选刷新令牌+--------+
+--------+ +---------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | | Authorization | | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +---------------+
图2：刷新过期的访问令牌
在图2所示的流程包括以下步骤：
（A）客户端通过与认证请求的访问令牌
授权服务器和呈现的授权授予。
（B）中的授权服务器的客户端，并验证认证
授权授予，如果有效，发出一个访问令牌
和刷新令牌。
（C）的客户端，使受保护的资源请求到资源
服务器出示的访问令牌。
（D）中的资源服务器验证所述接入令牌，并且如果有效，
处理请求。
（E）的步骤（C）和（D）重复，直到访问令牌到期。如果
客户端知道访问令牌过期，它跳过步骤（G）;
否则，它使另一受保护的资源的请求。
（F）由于访问令牌是无效的，资源服务器返回
一个无效的令牌错误。
（G）客户端通过验证请求新的访问令牌
授权服务器和展示刷新令牌。该
客户端认证要求是基于客户端类型
并在授权服务器策略。
（H），该授权服务器的客户端，并验证认证
刷新令牌，并且如果有效，发出一个新的访问令牌（和，
任选地，新的刷新令牌）。
步骤（C），（D），（E）和（F）是此范围以外的
说明书中，如同在第7节中所述。
1.6。 TLS版本
每当传输层安全性（TLS）用于由该
规范，相应的版本（或版本）TLS会有所不同
随着时间的推移，基于广泛部署和已知的安全
漏洞。在写这篇文章的时候，TLS1.2版
[RFC5246]是最新的版本，但是有一个非常有限
部署基地，可能不是现成的
实现。 TLS版本1.0[RFC2246]是最广泛
部署的版本，并提供最广泛的互操作性。
实现也可能支持额外的传输层安全性
满足他们的安全需求的机制。
1.7。 HTTP重定向
这说明大量使用HTTP重定向，其中
在客户端或授权服务器指示资源所有者的
用户代理到另一个目的地。虽然在本实施例
说明书中示出了使用的HTTP 302状态代码，任何其他
经由用户代理可利用的方法来完成此重定向
允许和被认为是一个实现细节。
1.8。互通性
的OAuth2.0提供了丰富的授权框架，明确定义
安全属性。然而，作为一个丰富的和高度可扩展的
框架具有许多任选组分，就其本身而言，本
规范可能产生广泛的非互操作
实现。
此外，这个规范留下了一些必需的组件
部分或完全不确定的（如，客户端注册，
授权服务器的能力，端点发现）。没有
该规范已经被设计围绕以下客户端
简介：
Web应用程序
一个Web应用程序在网络上运行的客户端保密
服务器。资源拥有者通过HTML的用户访问客户端
接口中所使用的设备上的用户代理呈现
资源所有者。客户端凭证，以及任何访问
向客户机发出的令牌存储在web服务器上，并且
不暴露于或由该资源的所有者访问。
用户代理的应用程序
用户代理为基础的应用程序是一个公共的客户，其中
客户机代码被从网络服务器下载的，并在一个执行
用户代理（例如，网络浏览器）的设备上所使用的资源
所有者。协议数据和凭证都很方便（和
经常可见的），以在资源所有者。由于这种应用程序
驻留在用户代理中，它们可以使无缝使用的
请求授权时，用户代理能力。
本机应用程序
本机应用程序是一个公共的客户端安装和执行上
所使用的资源的所有者设备。协议数据和
凭据访问资源所有者。假定
这包括在任何客户端身份验证凭据
应用程序可以被提取。另一方面，动态
颁发证书，如访问令牌或刷新令牌可以
得到保护的可接受的水平。至少，这些
凭据免受恶意服务器与该
应用程序可以交互。在某些平台上，这些凭据
可能被保护驻留在相同的其他应用程序
装置。
2.2。客户端标识符
授权服务器发出的注册客户端一个客户端
标识符 - 代表注册的唯一字符串
由客户提供的信息。客户端标识符不是
秘密的;它暴露于资源所有者和绝不能使用
单独的客户端身份验证。客户端标识符是唯一的
授权服务器。
客户标识字符串大小未定义本
规范。客户应避免作出有关的假设
标识的大小。授权服务器应记录尺寸
任何标识的IT问题。
2.3。客户端身份验证
如果客户端类型是保密的，在客户端和授权
服务器建立适合于客户端身份验证方法
授权服务器的安全要求。授权
服务器可以接受任何形式的客户端身份验证的满足其
安全性要求。
机密的客户通常发出的（或建立）一套
用于与授权认证的客户端凭证
服务器（例如，密码，公钥/私钥对）。
授权服务器可以建立一个客户端身份验证方法
公众客户。但是，授权服务器必须不依赖
关于用于识别的目的，公共客户机验证
客户端。
客户在每个绝不能使用多个身份验证方法
请求。
2.3.1。客户端密码
在拥有客户端密码，客户端可以使用HTTP基本
在[RFC2617]定义的认证方案与认证
授权服务器。客户端标识符是使用所述经编码
“应用程序/ x www的窗体-urlencoded”每个编码算法
附录B，和编码值被用作用户名;客户端
密码被使用相同的算法进行编码，并用作
密码。授权服务器必须支持HTTP基本
为验证发出一个客户端身份验证方案
客户端密码。
例如（额外换行符仅供显示）：
授权：基本czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
此外，授权服务器可以支持包括
使用下面的请求体客户端凭据
参数：
CLIENT_ID
必需的。在发给客户端的客户端标识符
按2.2节所述的注册过程。
client_secret
必需的。客户端的秘密。客户端可以省略
参数如果客户端秘密为空字符串。
包括使用两个在请求体的客户端凭证
参数是不推荐的，并应限制客户无法
直接利用HTTP基本身份验证方案（或其他
基于密码的HTTP认证方案）。参数只能
在请求体发送和不得列入
请求URI。
例如，一个请求以刷新使用访问令牌（第6节）
车身参数（多余的换行符用于显示目的
只）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
授权服务器必须要求使用TLS作为中描述
使用密码认证发送请求时，第1.6节。
自该客户端的认证方法包括密码，则
授权服务器必须保护利用它反对任何端点
蛮力攻击。
2.3.2。其他身份验证方法
授权服务器可以支持任何适当的HTTP认证
计划匹配的安全要求。当使用其它
身份验证方法，授权服务器必须定义
客户标识符（登记备案）之间的映射
认证方案。
2.4。未登记的客户
本规范不排除使用未经注册的客户。
然而，使用这样的客户端的是超出了这个范围
规范和要求额外的安全性分析和审查
其互操作性的影响。
3.协议端点
授权过程利用两个授权服务器端点
（HTTP资源）：
?授权端点 - 使用客户端获得
授权，通过用户代理重定向资源所有者。
?令牌端点 - 客户端使用交换授权
授予访问令牌，通常与客户端身份验证。
以及一个客户端点：
O重定向端点 - 使用授权服务器返回
通过包含授权证书给客户端的响应
资源所有者的user-agent。
不是每个授权交付式利用两个端点。
根据需要延长授予的类型也可以定义更多的端点。
3.1。授权端点
授权端点用于与资源交互
老板和获得授权授予。授权服务器
必须先验证资源所有者的身份。在路上
该授权服务器认证资源所有者
（例如，用户名和密码登录，会话cookie），超出了
本规范的范围。
通过该客户端获取的所述位置的装置
授权端点不属于本规范的范围，
但位置通常提供的服务文档中。
端点URI可以包括“应用程序/ x-WWW的形式，进行了urlencoded”
格式（每附录B）查询组件（[RFC3986]第3.4节）
这必须增加额外的查询参数时被保留。该
端点URI不能包含一个片段组成部分。
因为请求的授权端点结果在用户
认证和明文凭证的发送（在
HTTP响应），授权服务器必须要求使用TLS
如第1.6节所述的发送请求到时候
授权端点。
授权服务器必须支持使用HTTP的“GET”
法[RFC2616]的授权端点可以支持
使用“POST”的方法为好。
没有值发送参数必须被视为如果他们
从请求被删去。授权服务器必须忽略
无法识别的请求参数。请求和响应参数
绝不能包含超过一次。
3.1.1。响应类型
授权端点使用的授权码授予
类型和隐式类型授予流动。客户端通知
授权服务器的所需授予类型的使用下
参数：
RESPONSE_TYPE
必需的。该值必须是“码”之一的请求
授权码所描述的第4.1.1节，“令牌”的
请求访问令牌（隐含补助金）所描述的
第4.2.1节，或所描述的注册推广价值
第8.4节。
扩展响应类型可能包含一个空格分隔（％×20）名单
值，其中值的顺序并不重要（例如，响应
输入“A B”的相同“B A”）。这种复合的含义
响应类型是由它们各自的规格所定义。
如果授权请求缺少“RESPONSE_TYPE”参数，
或者，如果响应类型是不理解，授权服务器
如第4.1.2.1描述必须返回一个错误响应。
3.1.2。重定向端点
在完成它的相互作用与资源所有者后，将
授权服务器指示资源所有者的用户代理回
客户端。授权服务器重定向用户代理向
此前既定的客户端的重定向端点
授权服务器在客户端注册过程中或当
使授权请求。
重定向端点URI必须是绝对URI所定义
[RFC3986]第4.3节。端点URI可以包括
“应用程序/ x www的窗体-urlencoded”格式化（按附录B）查询
组件（[RFC3986]第3.4节），这必须在添加时必须保留
额外的查询参数。端点URI必须不包括
片段组成部分。
3.1.2.1。端点请求保密
重定向端点应该要求使用TLS的描述
在第1.6节时所要求的响应类型是“代码”或“令牌”，
或者当重定向请求将导致的传输
敏感的凭据，在一个开放的网络。该规范不
不是因为在写这篇文章的时候强制使用TLS，
需要的客户端部署TLS是一个显著障碍为许多
客户端的开发。如果TLS是不可用，授权服务器
应该提醒有关不安全端点资源所有者之前
授权期间重定向（例如，显示消息
要求提供）。
缺乏传输层安全性的可以对造成严重影响
在客户端的安全性和它被授权的受保护的资源
访问。使用传输层安全性是特别
临界当授权过程被用作一种形式的
由客户授权终端用户的认证（例如，第三方
签到服务）。
3.1.2.2。注册要求
授权服务器必须需要以下客户端
注册他们的重定向端点：
澳公共客户。
利用隐性授予O型机密的客户。
授权服务器应要求所有客户登记，
之前使用的授权端点重定向端点。
授权服务器应要求客户提供
完整的重定向URI（客户端可以使用“状态”的要求
参数来实现每个请求的定制）。如果要求
完整的重定向URI的登记是不可能的，该
授权服务器应要求URI的登记
方案，授权和路径（允许客户动态变化
重定向URI的请求时，只有查询组件
授权）。
授权服务器可以让客户注册多个
重定向端点。
缺乏重定向URI登记要求可以启用
攻击者使用的授权的端点作为一个开放重定向作为
第10.15描述。
3.1.2.3。动态配置
如果多个重定向的URI已经登记，如果只有部分
重定向的URI已经被注册，或如果没有重定向的URI具有
已经注册，客户端必须包括与重定向URI
使用“redirect_uri”请求参数授权请求。
当一个重定向的URI被包括在授权请求，则
授权服务器必须比较并匹配收到的值
针对所述至少一个已注册的重定向的URI（或URI
如[RFC3986]第6定义，如果有的话重定向组件）
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。令牌端点
令牌端点所使用的客户端通过，以获得访问令牌
展示其授权许可或刷新令牌。令牌
端点使用除了每个授权授予
隐授予型（因为一个访问令牌直接发放）。
通过该客户端获得令牌的位置的装置
端点不属于本规范的范围，但位置
通常所提供的服务的文档中。
端点URI可以包括“应用程序/ x-WWW的形式，进行了urlencoded”
格式（每附录B）查询组件（[RFC3986]第3.4节）
这必须增加额外的查询参数时被保留。该
端点URI不能包含一个片段组成部分。
由于在传输请求令牌端点结果
明文凭证（在HTTP请求和响应），则
授权服务器必须要求使用TLS作为中描述
1.6节将请求发送到令牌端点时。
使访问令牌，当客户端必须使用HTTP“POST”的方法
请求。
没有值发送参数必须被视为如果他们
从请求被删去。授权服务器必须忽略
无法识别的请求参数。请求和响应参数
绝不能包含超过一次。
3.2.1。客户端身份验证
机密客户端或其他客户端发出的客户端凭据必须
如上述与授权服务器认证
2.3节发出请求到令牌端点时。客户
身份验证用于：
?强制刷新令牌和授权码到绑定
在客户端，他们发出。客户端身份验证是关键
当授权代码被发送到重定向
端点通过不安全的通道，或当重定向URI有
未登记在充分。
?从受损的客户端通过禁用客户端或恢复
改变其凭证，从而防止了攻击者滥用
被盗刷新令牌。改变一组客户端
凭据是不是取消了一整套显著快
刷新令牌。
?实施认证管理最佳做法，
需要定期凭证旋转。一整组的转动
刷新令牌可以是具有挑战性，而一个单一的旋转
一套客户端凭据是显著容易。
客户可以使用“CLIENT_ID”请求参数来确定自身
将请求发送到令牌时端点。在
“authorization_code”“grant_type”请求令牌端点，一个
未经身份验证的客户端必须发送它的“CLIENT_ID”，以防止自己
无意中接受用于与一客户端的代码
不同的“CLIENT_ID”。这保护了端离的取代
认证码。 （它为没有额外的安全
受保护的资源。）
3.3。访问令牌范围
授权和令牌端点允许客户指定
使用“范围”请求参数的访问请求的范围。在
转，授权服务器使用“范围”的响应参数
通知发出的访问令牌的范围的客户端。
范围参数的值表示为空间 - 列表
分隔，区分大小写字符串。该字符串被定义
授权服务器。如果值包含多个空格分隔
字符串，它们的顺序并不重要，而且每串增加了一个
其他访问范围所请求的范围。
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
授权服务器可以完全或部分地忽略范围
由客户端请求的，基于所述授权服务器策略或
资源所有者的说明。如果发出的访问令牌范围
是从所述一个由客户机，则授权请求不同
服务器必须包括“适用范围”响应参数通知
的实际范围的客户端授权。
如果请求当客户端忽略范围参数
授权，授权服务器必须要么处理
请求使用预先定义的缺省值，或失败的请求
指示无效的范围。授权服务器应
记录其范围的要求和默认值（如果定义）。
4.获得授权
要请求访问令牌，客户端从获得授权
资源所有者。授权中表达的形式
授权授予，该客户端使用请求访问
令牌。 OAuth的定义了四种类型的授予：授权码，含蓄，
资源所有者密码凭据，客户端凭据。这也
提供了用于定义额外授予类型的扩展机制
4.1。授权码授予
授权码交付式被用来获得两个访问
令牌和刷新令牌，并进行了优化，保密的客户。
由于这是一个重定向基于流时，客户端必须能够
与资源所有者的用户代理进行交互（典型的web
浏览器）和能够接收传入的请求（通过重定向）
从授权服务器。
+----------+
|资源|
|业主|
| |
+----------+
^
|
（B）
+----|-----+客户端标识符+--------+
| - +----（A） - 重定向URI---->| |
|用户 - | |授权|
|代理 - +----（B） - 用户认证--->|服务器|
| | | |
| - +----（C） - 授权码---<| |
+ - |----| ---++---------------+
| |^ V
（A）（C）| |
| | | |
^ V| |
+---------+| |
| |>---（D） - 授权码---------“|
|客户|＆重定向URI|
| | |
| |<---（E）-----访问令牌-------------------“
+---------+（W /可选刷新令牌）
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------‘ |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------‘
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.注意：线示出步骤（A），（B）和（C）被分解成
两部分，因为他们通过用户代理。
图3：授权码流
在图3中所示的流程包括以下步骤：
（A）客户端通过引导资源所有者的启动流程
用户代理到授权端点。该客户端包括
它的客户端标识符，要求的范围，地方国有和
重定向URI到授权服务器将发送
用户代理回来一次授予访问权限（或拒绝）。
（B）中的授权服务器经由验证该资源的所有者（
用户代理）并建立是否资源所有者
授予或拒绝客户端的访问请求。
（C）假设资源所有者授予访问权限，授权
服务器使用重定向用户代理返回给客户端
重定向URI前面提供（请求或在
客户端注册）。重定向URI包括
授权代码和客户端提供的任何地方国有
更早。
（D）的客户端请求的访问令牌从授权
通过包括授权码服务器的令牌端点
在上一步骤接收。发出请求时，所述
客户端与授权服务器进行身份验证。客户端
包括重定向的URI用于获得授权
为验证码。
（E）的授权服务器验证客户端，验证
授权码，并且确保了重定向的URI
收到匹配的URI用来重定向客户端
步骤（C）。如果有效，授权服务器返回响应以
接入令牌和任选的刷新令牌。
4.1.1。授权请求
客户端通过添加以下构造请求URI
参数到授权端点URI的查询组件
使用“应用程序/ x www的窗体-urlencoded”的格式，按附录B：
RESPONSE_TYPE
必需的。值必须设置为“代码”。
CLIENT_ID
必需的。如2.2节所述的客户端标识符。
redirect_uri
可选。由于第3.1.2节。
范围
可选。接入请求的范围所描述的
第3.3节。
状态
推荐使用。客户端使用一个不透明的值维持
请求和回调的状态。授权
重定向回用户代理服务器时，包括此值
到客户端。参数应该用于预防
跨站点请求伪造在第10.12节描述。
资源所有者的构造URI使用客户端指示
HTTP重定向的响应，或者通过经由提供给它的其他装置
用户代理。
例如，客户端会指示用户代理进行以下
使用TLS（带额外的行HTTP请求，打破了显示器用途
只）：
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
授权服务器验证请求，以确保所有
必需的参数是存在并有效。如果该请求是有效的，
授权服务器认证资源所有者成于
授权决定（通过询问资源所有者或
建立通过其它方式批准）。
当判定成立时，授权服务器指示
使用HTTP用户代理所提供的客户端重定向URI
重定向响应，或者通过经由提供给它的其他装置
用户代理。
4.1.2。授权响应
如果资源所有者授予的访问请求时，授权
服务器发出一个授权代码和它由传送到客户端
加入以下参数的查询部件
重定向URI使用“应用程序/ x www的窗体-urlencoded”的格式，
按附录B：
代码
必需的。由生成的授权码
授权服务器。授权代码必须到期
它发出后不久，以减轻泄漏的风险。一
10分钟最大的授权码寿命
推荐使用。客户不得使用授权码
不止一次。如果授权码用于多
一次，授权服务器必须拒绝该请求，并应
撤销（如果可能）的所有令牌以前发布的基础上
该授权码。该授权码势必
客户端标识符和重定向URI。
状态
必选如果“状态”参数存在于客户端
授权请求。从接收到的精确值
客户端。
例如，授权服务器重定向用户代理通过
发送以下HTTP响应：
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
客户端必须忽略无法识别的响应参数。该
授权码字符串大小是左未定义本
规范。客户应避免对代码的假设
值的大小。授权服务器应记录的大小
任何值IT问题。
4.1.2.1。错误响应
如果请求失败，原因是缺少的，无效的，或者不匹配
重定向的URI，或者如果客户端标识符丢失或无效，
授权服务器应该通知的资源所有者
错误，必须不自动重定向用户代理到
无效的重定向URI。
如果资源所有者拒绝访问请求，或者如果请求
失败的原因不是丢失或无效的重定向URI等，
授权服务器通过将下面的通知客户端
使用参数来重定向URI的查询组件
“应用程序/ x www的窗体-urlencoded”的格式，按附录B：
错误
必需的。从一个单一的ASCII[USASCII]错误代码
如下：
INVALID_REQUEST
该请求缺少必需的参数，包括
无效的参数值，包括参数超过
一次，或者说是不正常的。
unauthorized_client
客户端未被授权以请求授权
代码中使用这种方法。
拒绝访问
资源所有者或授权服务器拒绝
请求。
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识别与人类可读的网页
有关错误，用于提供客户机的信息
开发商与有关错误的附加信息。
值的“error_uri”参数必须符合
URI引用的语法，因而不能包含的字符
外集％X21/％x23-5B/％X5D-7E。
状态
必需如果“状态”参数存在于客户端
授权请求。从接收到的精确值
客户端。
例如，授权服务器重定向用户代理通过
发送以下HTTP响应：
HTTP/1.1302发现
地点：https://client.example.com/cb?error=access_denied&state=xyz
4.1.3。访问令牌请求
客户端通过发送发出请求令牌端点
以下使用的参数“应用程序/ x-WWW的形式，进行了urlencoded”
按附录B格式UTF-8在HTTP字符编码
请求的实体：
grant_type
必需的。值必须设置为“authorization_code”。
代码
必需的。从接收到的授权码
授权服务器。
redirect_uri
REQUIRED，如果“redirect_uri”参数被列入
授权请求4.1.1节描述的那样，他们
值必须是相同的。
CLIENT_ID
REQUIRED，如果客户端不与认证
授权服务器在第3.2.1节中所述。
如果客户端类型为机密或客户端发出客户端
凭据（或交办的其他认证要求），该
所描述的客户端必须与授权服务器进行身份验证
在第3.2.1节。
例如，客户端使用TLS以下HTTP请求
（额外换行符仅供显示）：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
授权服务器必须：
?要求对客户的机密或任何客户端身份验证
发布客户证书（或与其他客户机
认证要求），
?验证客户端，如果客户端验证包括，
o确保授权代码发给认证
机密的客户，或者如果客户端是公共的，确保了
代码请求发出“CLIENT_ID”
o确认该授权码是有效的，并
?确保“redirect_uri”参数存在，如果
“redirect_uri”参数被列入初始授权
要求在第4.1.1节中所述，如果包括确保
它们的值是相同的。
4.1.4。访问令牌响应
如果访问令牌请求是有效的和授权，则
授权服务器发出一个访问令牌和可选刷新
令牌在第5.1节所描述的。如果请求客户端
验证失败或无效，则授权服务器返回
错误响应，在5.2节所述。
一个例子成功的响应：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
4.2。隐授予
隐式授予类型用于获得访问令牌（它不
支持发行刷新令牌），并公开了优化
客户端已知操作一个特定的重定向的URI。这些客户端
通常使用脚本语言来实现在浏览器
如JavaScript。
由于这是一个重定向基于流时，客户端必须能够
与资源所有者的用户代理进行交互（典型的web
浏览器）和能够接收传入的请求（通过重定向）
从授权服务器。
不像授权码交付式，其中，客户端发出
授权和访问令牌独立的要求，
客户端接收访问令牌作为授权的结果
请求。
隐式类型授予不包括客户端身份验证，并
依赖于资源所有者的存在和登记
重定向URI。因为该访问令牌被编码成
重定向的URI，它可暴露于该资源的所有者和其他
驻留在相同的设备上的应用程序。
+----------+
|资源|
|业主|
| |
+----------+
^
|
（B）
+----|-----+客户端标识符+--------+
| - +----（A） - 重定向URI--->| |
|用户 - | |授权|
|代理 - |----（B） - 用户验证 - >|服务器|
| | | |
| |<---（C）---重定向URI----<| |
| |与访问令牌+--------+
|在片段|
| | +--------+
| |----（D）---重定向URI---->|网站托管|
|无片段|客户| |
| | |资源|
|（F）|<---（E）-------脚本---------<| |
| | +--------+
+ - |--------+
| |
（A）（G）访问令牌
| |
^ V
+---------+
| |
|客户|
| |
+---------+
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |注意：示出步骤（A）和（B）的线被分成两个
部分因为他们通过用户代理。
图4：隐授予流量
在图4中所示的流程包括以下步骤：
（A）客户端通过引导资源所有者的启动流程
用户代理到授权端点。该客户端包括
它的客户端标识符，要求的范围，地方国有和
重定向URI到授权服务器将发送
用户代理回来一次授予访问权限（或拒绝）。
（B）中的授权服务器经由验证该资源的所有者（
用户代理）并建立是否资源所有者
授予或拒绝客户端的访问请求。
（C）假设资源所有者授予访问权限，授权
服务器使用重定向用户代理返回给客户端
重定向URI早些时候提供的。重定向URI包括
在URI片段的访问令牌。
（D）中的用户代理如下通过使重定向指令
请求发送到Web托管的客户资源（不
包括每[RFC2616]的片段）。用户代理保留
片段信息在本地。
（E）的Web托管客户端的资源返回一个网页（通常是
带有嵌入式脚本的HTML文件）能够访问的
满重定向的URI包含由保留片段
用户代理，并提取访问令牌（和其他
中所含的片段的参数）。
（F）的用户代理执行由Web托管提供的脚本
客户端在本地的资源，提取访问令牌。
（G）的用户代理传递所述访问令牌给客户端。
请参见1.3.2节和9背景上使用隐授予。
参见第10.3和10.16的重要的安全注意事项
使用隐授予的时候。
4.2.1。授权请求
客户端通过添加以下构造请求URI
参数到授权端点URI的查询组件
使用“应用程序/ x www的窗体-urlencoded”的格式，按附录B：
RESPONSE_TYPE
必需的。值必须设置为“令牌”。
CLIENT_ID
必需的。如2.2节所述的客户端标识符。
redirect_uri
可选。由于第3.1.2节。
范围
可选。接入请求的范围所描述的
第3.3节。
状态
推荐使用。客户端使用一个不透明的值维持
请求和回调的状态。授权
重定向回用户代理服务器时，包括此值
到客户端。参数应该用于预防
跨站点请求伪造在第10.12节描述。
资源所有者的构造URI使用客户端指示
HTTP重定向的响应，或者通过经由提供给它的其他装置
用户代理。
例如，客户端会指示用户代理进行以下
使用TLS（带额外的行HTTP请求，打破了显示器用途
只）：
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
授权服务器验证请求，以确保所有
必需的参数是存在并有效。授权服务器
必须验证重定向URI，并向它重定向
访问令牌相匹配的客户端作为注册的重定向URI
第3.1.2节。
如果该请求是有效的，授权服务器认证该
资源所有者和获得授权决定（通过询问
资源所有者，或通过建立通过其他方式批准）。
当判定成立时，授权服务器指示
使用HTTP用户代理所提供的客户端重定向URI
重定向响应，或者通过经由提供给它的其他装置
用户代理。
4.2.2。访问令牌响应
如果资源所有者授予的访问请求时，授权
服务器发出一个访问令牌，它通过增加提供给客户端
以下参数来重定向的片段组成部分
使用“应用程序/ x www的窗体-urlencoded”的格式，每个URI
附录B：
access_token
必需的。通过授权服务器发出的访问令牌。
token_type
必需的。作为标记的描述中发出的类型
第7.1节。值不区分大小写。
expires_in
推荐使用。在访问令牌秒的寿命。为
例如，值“3600”表示该访问令牌将
在一小时内从生成该响应时间期满。
如果省略，授权服务器应当提供
通过其他手段或文档的默认值的期满时间。
范围
可选的，如果与由客户端请求的范围;
否则，必需的。访问令牌的范围
按3.3节所述。
状态
必选如果“状态”参数存在于客户端
授权请求。从接收到的精确值
客户端。
授权服务器不能发出刷新令牌。
例如，授权服务器重定向用户代理通过
发送以下HTTP响应（额外换行符的
只作展示用途）：
HTTP/1.1302发现
地点：http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
与状态= XYZ＆token_type=例如：expires_in=3600
开发人员应该注意，有些用户代理不支持
包含一个片段组成部分中的HTTP“位置”的反应
头字段。这样的客户将需要使用其他方法
重定向客户端比3XX重定向响应 -
例如，返回一个HTML页面，其中包括一个“继续”按钮
与链接到重定向URI的动作。
客户端必须忽略无法识别的响应参数。访问
令牌字符串大小由本规范未定义。该
客户应避免作出假设值的大小。该
授权服务器应记录它发出的任何值的大小。
4.2.2.1。错误响应
如果请求失败，原因是缺少的，无效的，或者不匹配
重定向的URI，或者如果客户端标识符丢失或无效，
授权服务器应该通知的资源所有者
错误，必须不自动重定向用户代理到
无效的重定向URI。
如果资源所有者拒绝访问请求，或者如果请求
失败的原因不是丢失或无效的重定向URI等，
授权服务器通过将下面的通知客户端
使用参数来重定向URI的片段组成部分
“应用程序/ x www的窗体-urlencoded”的格式，按附录B：
错误
必需的。从一个单一的ASCII[USASCII]错误代码
如下：
INVALID_REQUEST
该请求缺少必需的参数，包括
无效的参数值，包括参数超过
一次，或者说是不正常的。
unauthorized_client
客户无权请求访问令牌
采用这种方法。
拒绝访问
资源所有者或授权服务器拒绝
请求。
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识别与人类可读的网页
有关错误，用于提供客户机的信息
开发商与有关错误的附加信息。
值的“error_uri”参数必须符合
URI引用的语法，因而不能包含的字符
外集％X21/％x23-5B/％X5D-7E。
状态
必需如果“状态”参数存在于客户端
授权请求。从接收到的精确值
客户端。
例如，授权服务器重定向用户代理通过
发送以下HTTP响应：
HTTP/1.1302发现
地点：https://client.example.com/cb#error=access_denied&state=xyz
4.3。资源所有者密码凭据授予
资源所有者密码凭证交付式适用于
情况下，资源的所有者与该信任关系
客户端，如设备操作系统或高权限
应用程序。授权服务器应特别注意，当
启用此授予类型，只允许它在其他流不
可行的。
这笔赠款类型是适合于能够获得的客户
资源所有者的凭据（用户名和密码，通常使用
交互式表格）。它也可以用来迁移现有客户
采用直接认证计划，如HTTP Basic或摘要
身份验证的OAuth通过将存储的凭据到
访问令牌。
+----------+
|资源|
|业主|
| |
+----------+
V
|资源所有者
（A）密码凭据
|
V
+---------++---------------+
| |> - （B）----资源所有者------->| |
| |密码凭据|授权|
|客户| |服务器|
| |< - （C）----访问令牌---------<| |
| |（W /可选刷新令牌）| |
+---------++---------------+
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+图5：资源所有者密码凭据流
在图5中所示的流程包括以下步骤：
（A）资源所有者向客户端提供的用户名和
密码。
（二）客户端请求的访问令牌从授权
通过包括收到的证书服务器的令牌端点
从资源所有者。发出请求时，客户端
验证与授权服务器。
（C）的授权服务器的客户端，并验证认证
资源所有者凭据，如果有效，发出一个访问
令牌。
4.3.1。授权请求和响应
通过该客户端获取资源所有者的方法
凭据超出了本规范的范围。客户端
必须丢弃的凭据，一旦一个访问令牌已经获得。
4.3.2。访问令牌请求
客户端通过将发出请求令牌端点
以下使用的参数“应用程序/ x-WWW的形式，进行了urlencoded”
按附录B格式UTF-8在HTTP字符编码
请求的实体：
grant_type
必需的。值必须设置为“密码”。
用户名
必需的。资源所有者的用户名。
密码
必需的。资源所有者的密码。
范围
可选。接入请求的范围所描述的
第3.3节。
如果客户端类型为机密或客户端发出客户端
凭据（或交办的其他认证要求），该
所描述的客户端必须与授权服务器进行身份验证
在第3.2.1节。
例如，客户端使用下列HTTP请求
传输层安全（额外换行符用于显示目的
只）：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
授权服务器必须：
?要求对客户的机密或任何客户端身份验证
发布客户证书（或与其他客户机
认证要求），
?验证客户端，如果客户机认证包括在内，
o使用验证资源所有者密码凭据其
现有的密码验证算法。
由于该访问令牌请求利用资源所有者的
密码，授权服务器必须防止端点
蛮力攻击（例如，使用速率限制或发电
警报）。
4.3.3。访问令牌响应
如果访问令牌请求是有效的和授权，则
授权服务器发出一个访问令牌和可选刷新
令牌在第5.1节所描述的。如果请求客户端失败
认证或无效，授权服务器返回一个
错误响应，在5.2节所述。
一个例子成功的响应：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
4.4。客户端证书授予
客户端可以只使用它的客户端请求访问令牌
证书（或认证的其他支持方式），当
客户端请求下访问受保护的资源，其
控制，或者那些其他资源所有者以前一直是
布置成与授权服务器（的方法，其中超出
本规范的范围内）。
客户端证书交付式只能用于保密
客户端。
+---------++---------------+
| | | |
| |> - （A） - 客户端认证--->|授权|
|客户| |服务器|
| |< - （B）----访问令牌---------<| |
| | | |
+---------++---------------+
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+图6：客户端凭证流
在图6中所示的流程包括以下步骤：
（A）与授权服务器的客户端进行身份验证和
要求从令牌端点访问令牌。
（B）中的授权服务器验证客户端，并且如果有效，
发出一个访问令牌。
4.4.1。授权请求和响应
由于客户端的认证用作认证授予，
无需额外的授权请求。
4.4.2。访问令牌请求
客户端通过将发出请求令牌端点
以下使用的参数“应用程序/ x-WWW的形式，进行了urlencoded”
按附录B格式UTF-8在HTTP字符编码
请求的实体：
grant_type
必需的。值必须设置为“client_credentials”。
范围
可选。接入请求的范围所描述的
第3.3节。
客户必须与授权服务器进行身份验证
在第3.2.1节中描述。
例如，客户端使用下列HTTP请求
传输层安全（额外换行符用于显示目的
只）：
POST/令牌HTTP/1.1
主持人：server.example.com
授权：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW
内容类型：应用程序/ x www的窗体-urlencoded
grant_type= client_credentials
授权服务器必须验证客户端。
4.4.3。访问令牌响应
如果访问令牌请求是有效的和授权，则
中所述授权服务器发出一个访问令牌
5.1节。刷新令牌不应被列入。如果请求
失败的客户端认证或无效，授权服务器
返回一个错误响应，在5.2节所述。
一个例子成功的响应：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}4.5。扩展资助
客户端通过指定交付式使用的扩展交付式
使用绝对URI（由授权服务器定义）作为
值令牌端点的“grant_type”参数，并通过
添加任何必要的附加参数。
例如，以请求使用安全断言接入令牌
标记语言（SAML）所界定2.0断言交付式
[OAuth的SAML2]，客户端可以使用做出以下HTTP请求
TLS（额外换行符仅供显示）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
[...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
如果访问令牌请求是有效的和授权，则
授权服务器发出一个访问令牌和可选刷新
令牌在第5.1节所描述的。如果请求客户端失败
认证或无效，授权服务器返回一个
错误响应，在5.2节所述。
5.发出一个访问令牌
如果访问令牌请求是有效的和授权，则
授权服务器发出一个访问令牌和可选刷新
令牌在第5.1节所描述的。如果请求客户端失败
认证或无效，授权服务器返回一个
错误响应，在5.2节所述。
5.1。成功的响应
授权服务器发出一个访问令牌和可选刷新
令牌，并构造通过添加以下参数的响应
于实体主体具有一个200（OK）状态码的HTTP响应的：
access_token
必需的。通过授权服务器发出的访问令牌。
token_type
必需的。作为标记的描述中发出的类型
第7.1节。值不区分大小写。
expires_in
推荐使用。在访问令牌秒的寿命。为
例如，值“3600”表示该访问令牌将
在一小时内从生成该响应时间期满。
如果省略，授权服务器应当提供
通过其他手段或文档的默认值的期满时间。
refresh_token
可选。刷新令牌，它可以被用来获得新的
使用相同的授权授予访问令牌描述
第6节。
范围
可选的，如果与由客户端请求的范围;
否则，必需的。访问令牌的范围
按3.3节所述。
参数被包括在实体主体的HTTP响应
使用“应用/ JSON的”媒体按[RFC4627]定义的类型。该
参数序列化为一个JavaScript对象符号（JSON）
结构由最高结构层次添加每个参数。
参数名称和字符串值包括为JSON字符串。
数值列为JSON号码。的顺序
参数并不重要，可以有所不同。
授权服务器必须包含HTTP“的Cache-Control”
响应报头字段[RFC2616]“无店铺”在任何一个值
含响应令牌，凭证或其他敏感
信息，以及在“语用”响应报头字段[RFC2616]
用“无缓存”的值。
例如：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
客户端必须忽略在响应中无法识别的值的名称。该
令牌和其它值的大小从授权接收
服务器没有定义。客户应避免
约值大小的假设。授权服务器应
记录它发出的任何值的大小。
5.2。错误响应
授权服务器的HTTP400（错误请求）响应
状态代码（除非另有规定），其包含下列
参数的回应：
错误
必需的。从一个单一的ASCII[USASCII]错误代码
如下：
INVALID_REQUEST
该请求缺少必需的参数，包括
不支持的参数值（除授予除外），
重复参数，包括多个凭证，
利用多于一个的机制用于认证
客户端，或者说是不正常的。
invalid_client
客户端身份验证失败（例如，未知客户端，没有
客户端验证包括，或不支持
身份验证方法）。授权服务器可能
返回一个HTTP401状态码来表示
身份验证方案支持哪些HTTP。如果
客户端尝试通过“授权”认证
请求头领域，授权服务器MUST
与HTTP401状态码和
包括“WWW身份验证”响应头字段
匹配所使用的客户机的验证方案。
invalid_grant
所提供的授权许可（例如，授权
码，资源所有者凭证）或刷新令牌就是
无效的，过期的，撤销，不重定向匹配
的URI用在授权请求，或者发出至
另一个客户端。
unauthorized_client
经过身份验证的客户端不被授权使用该
授权授予类型。
unsupported_grant_type
授权授予类型不支持的
授权服务器。
invalid_scope
所请求的范围是无效的，未知的，畸形，或
超过授予的资源所有者的范围。
值的“错误”参数不能包含的字符
外集％x20-21/％x23-5B/％X5D-7E。
error_description
可选。人类可读的ASCII[USASCII]文本提供
附加信息，用于协助客户，显影剂中
理解所发生的错误。
值的“error_description”参数不能包含
设定％x20-21/％x23-5B/％X5D-7E以外的字符。
error_uri
可选。一个URI识别与人类可读的网页
有关错误，用于提供客户机的信息
开发商与有关错误的附加信息。
值的“error_uri”参数必须符合
URI引用的语法，因而不能包含的字符
外集％X21/％x23-5B/％X5D-7E。
参数被包括在实体主体的HTTP响应
使用“应用/ JSON的”媒体按[RFC4627]定义的类型。该
参数是通过将每个序列化为一个JSON结构
参数最高结构层次。参数名称和字符串
值包括为JSON字符串。数字值被包括在内
作为JSON数字。参数的顺序并不重要，可以
有所不同。
例如：
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}6.刷新访问令牌
如果授权服务器发出一个刷新令牌给客户端，该
客户通过将使得刷新请求令牌端点
以下使用的参数“应用程序/ x-WWW的形式，进行了urlencoded”
按附录B格式UTF-8在HTTP字符编码
请求的实体：
grant_type
必需的。值必须设置为“refresh_token”。
refresh_token
必需的。向客户机发出刷新令牌。
范围
可选。接入请求的范围所描述的
第3.3节。所请求的范围必须不包括任何适用范围
原本不授予资源所有者，如果省略则
视为等于最初授予的范围
资源所有者。
由于刷新令牌用于一般恒久的凭据
请求额外访问令牌，刷新令牌被绑定到
它所发出的客户端。如果客户端类型是保密的，或
客户端发出的客户证书（或交办的其他
认证要求），客户端必须与认证
授权服务器在第3.2.1节中所述。
例如，客户端使用下列HTTP请求
传输层安全（额外换行符用于显示目的
只）：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
授权服务器必须：
?要求对客户的机密或任何客户端身份验证
发布客户证书（或与其他客户机
认证要求），
?验证客户端，如果客户端验证包括在内，
确保刷新令牌发给认证
客户端，和
?验证刷新令牌。
如果有效授权，授权服务器发出的访问
令牌在第5.1节所描述的。如果请求失败
验证或无效，授权服务器返回一个错误
响应，在5.2节所述。
授权服务器可以发出新的刷新令牌，在这种情况
客户端必须丢弃旧的刷新令牌，并将其与替换
新的刷新令牌。授权服务器可以撤销老
发布一个新的刷新令牌给客户端后刷新令牌。如果
发出新的刷新令牌，刷新令牌范围必须是
相同的，包括在所述客户端的刷新令牌
请求。
7.访问受保护的资源
客户端通过提供接入访问受保护的资源
令牌到资源服务器。资源服务器必须验证
访问令牌，并确保它没有过期，并且其范围
涵盖所请求的资源。所使用的资源的方法
服务器来验证所述接入令牌（以及任何错误响应）
不属于本规范的范围，但通常涉及的
资源服务器和之间的相互作用或配位
授权服务器。
在其中客户端利用所述接入令牌的方法
与资源服务器验证依赖于访问的类型
令牌由授权服务器发出的。典型地，它涉及
使用HTTP“授权”请求头场[RFC2617]与
由接入规范中定义的认证方案
令牌类型使用，如[RFC6750]。
7.1。访问令牌类型
访问令牌类型为客户端提供的信息，
成功利用访问令牌，使受保护的需要
资源请求（连同类型特定属性）。客户端
不得使用一个访问令牌，如果它不明白令牌
类型。
例如，在[RFC6750]中定义的“载体”记号类型被利用
通过简单地包括在请求访问令牌字符串：
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM而在[OAuth的-HTTP-MAC]中定义的“陆委会”令牌类型由使用
与发出消息认证码（MAC）键一起
被用于签署的HTTP的某些组件的访问令牌
要求：
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
nonce="274312:dj83hs9s",
mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
所提供的上述实例仅用于说明目的。
建议开发人员参考[RFC6750]和[OAuth的-HTTP-MAC]
使用前规范。
每一个访问令牌类型定义指定的附加属性
（如有的话）发送到客户端连同“access_token”响应
参数。它还定义了用于HTTP的身份验证方法
包括访问令牌使受保护的资源请求时。
7.2。错误响应
如果资源访问请求失败，资源服务器应该通知
错误的客户端。而这样的错误响应的细节
不属于本规范的范围，该文件规定
在第11.4节共同注册表错误值进行共享
OAuth的令牌认证方案。
主要用于令牌的OAuth认证的新方案
认证应该定义一个机制来提供错误
状态代码给客户机，其中，所述误差值是允许的
在本规范制定的错误登记注册。
这样的方案可以限制该组有效的错误码的一个子集
注册值。如果使用将返回错误代码命名
参数，参数名称应为“错误”。
能够被用于OAuth的令牌认证其他方案，
但主要不是为了这个目的，可以结合自己的错误
值到注册表中相同的方式。
新的认证计划，可能也选择了指定使用的
“error_description”和“error_uri”参数返回错误
以平行的方式对他们的在此使用情况的信息
规范。
8.可扩展性
8.1。定义访问令牌类型
访问令牌类型可在以下两种方式之一来定义：在注册
访问令牌类型的注册表（下面的程序
部分11.1），或通过使用一个唯一的绝对URI作为其名称。
利用URI名称类型应仅限于特定供应商
实现，它们不常用适用，并且是特定于
资源服务器的实现细节，他们是
使用。
所有其他类型都必须登记。类型名称必须符合
类型名ABNF。如果类型定义包括一个新的HTTP
认证方案，类型名称应该是相同的HTTP
认证方案名称（由[RFC2617]定义）。标记类型
“榜样”是在实例保留。
类型名=1*名称字符
名称 - 炭=“ - ”/“”。 /“_”/ DIGIT/ ALPHA
8.2。定义新的端点参数
新的请求或响应参数与授权使用
端点或令牌端点被定义，并在注册
OAuth的Parameters注册表按照11.2节的程序。
参数名称必须符合参数名ABNF和参数
值语法必须明确定义（例如，使用ABNF，或参考
到现有参数的语法）。
参数名称=1*名称字符
名称 - 炭=“ - ”/“”。 /“_”/ DIGIT/ ALPHA
未登记的供应商特定的参数的扩展，不
通常适用的，并且是特定于实施
授权服务器的在那里它们被用于应详细说明
利用供应商特定的前缀是不太可能与相冲突
其他已注册的值（例如，以‘companyname_‘）。
8.3。定义新的授权授予类型
新的授权授予类型可以通过分配来定义他们
独特的绝对URI以便与“grant_type”参数的使用。如果
扩展授予类型需要额外的令牌端点的参数，
描述他们必须注册在OAuth的Parameters注册表
由第11.2节。
8.4。定义新的授权端点响应类型
与授权端点使用新的响应类型
定义并在授权端点响应类型注册
注册表按照11.3节的程序。响应类型
名称必须符合响应式ABNF。
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
如果一个响应类型包含一个或多个空格字符（％X20）时，它
是作为比较值的空格分隔列表中的顺序
值无所谓。只值一个订单可以注册，
覆盖同一组值的所有其他安排。
例如，响应式“令牌代码”未定义本
规范。然而，一个扩展可以定义和注册
“令牌代码”响应类型。一旦注册成功，同样的组合
不能被注册为“代码令牌”，而这两个值可以用于
表示相同的响应类型。
8.5。定义其他错误代码
在情况下，协议扩展（即访问令牌类型，
扩展参数，或延长授予类型）需要额外的
错误代码将与授权码授予错误使用
响应（第4.1.2.1），隐含的授予错误响应
（第4.2.2.1），令牌错误响应（第5.2节），或者
资源访问错误响应（第7.2节），这样的错误代码可能是
定义。
扩展错误代码必须注册（下面的程序
部分11.4），如果它们被一起使用的扩展是一个
注册的访问令牌类型，注册端点参数，或
扩展交付式。与未注册的扩展使用错误代码
可登记。
错误代码必须符合错误ABNF，应该由前缀
标识名称时可能。例如，一个错误识别
设置扩展参数无效值“榜样”应该是
名为“example_invalid”。
错误=1*错误字符
错误的char=％x20-21/％x23-5B/％X5D-7E
9.本机应用程序
本机应用程序安装并在设备上执行的客户端
所使用的资源所有者（即桌面应用，本地移动
应用程序）。本机应用程序需要特殊考虑
涉及到安全性，平台功能，和整体的最终用户
的经验。
授权端点需要在客户端之间的交互
而资源所有者的用户代理。本机应用程序可以调用
外部用户代理或嵌入在应用程序中的用户代理。
例如：
?外部用户代理 - 本机应用程序可以捕获
使用重定向URI从授权服务器的响应
与操作系统调用注册的方案
客户端的处理程序，凭证的手动复制和粘贴，
运行本地Web服务器，安装用户代理扩展，或
通过提供重定向的URI识别服务器托管
在客户端的控制下的资源，而这又使得
响应提供给本机应用程序。
?嵌入式用户代理 - 本机应用程序获得响应
通过与嵌入式用户代理通过直接连通
资源负荷期间监测状态变化发出，或
访问用户代理的cookie存储。
当外部或嵌入用户代理之间进行选择，开发人员
应考虑以下几点：
?外部用户代理可以提高完成率，作为
资源所有者可能已经有一个活跃的会话与
授权服务器，无需重新进行身份验证。它
提供了一种熟悉的最终用户体验和功能。该
资源所有者也可能依赖于用户代理的功能或扩展
协助认证（例如，密码管理器，双因素
装置阅读器）。
?嵌入式用户代理可以提供更高的可用性，因为它消除
需要切换上下文，并打开新的窗口。
?嵌入式用户代理带来了安全挑战，因为资源
业主证在一名身份不明的窗口而不访问
在大多数外部用户代理发现视觉保护。一个
嵌入式用户代理灌输最终用户信任不明
认证请求（使钓鱼攻击更容易
执行）。
当隐式授予类型和授权之间进行选择
代码授予类型，应考虑以下因素：
?使用该授权码交付式原生应用
应该这样做，而无需使用客户端凭据，由于本土
应用程序无法保持客户端凭据保密。
o如果使用隐授予式流量，刷新令牌不
回来了，这需要重复授权过程中一旦
访问令牌到期。
10.安全注意事项
作为一种灵活的和可扩展的框架，OAuth的安全
考虑取决于许多因素。以下各节
提供实施者与集中在三个安全指引
2.1节中描述的客户端配置文件：Web应用程序，
用户代理的应用程序，和本机应用程序。
综合OAuth安全模型和分析，以及
背景用于协议设计，由设置
[OAuth的THREATMODEL。
10.1。客户端身份验证
授权服务器建立与Web客户端凭据
应用程序客户端的客户端身份验证的目的。该
授权服务器鼓励考虑更强的客户端
认证是指比客户端密码。 Web应用程序客户端
必须确保客户的密码和其他客户的保密
凭据。
授权服务器不能发出客户端密码或其他
客户端凭据本地应用程序或用户的基于代理
应用程序客户端的客户端身份验证的目的。该
授权服务器可以发出客户端密码或其它凭证
对于本地应用程序客户端上的一个特定的安装
特定设备。
当客户端认证是不可能的，授权服务器
应采用其他方法来验证客户的身份 - 为
例如，要求客户端重定向URI的登记
或争取资源所有者，以确认身份。有效
重定向URI不足以验证客户的身份
请求资源所有者授权但可用于当
防止后交付凭证伪造客户端
获取资源所有者授权。
授权服务器必须考虑的安全问题
与未认证的客户端交互，并采取措施限制
其他凭证的潜在风险（如，刷新令牌）
发出这样的客户。
10.2。客户端模拟
恶意的客户端可以伪装成其他的客户端，并获得访问
受保护的资源，如果被模拟的客户端无法，或者说是
无法，保持其客户端凭据保密。
授权服务器必须验证客户端，只要
可能的。如果授权服务器无法验证客户端
由于客户机的性质，授权服务器必须要求
任何重定向的登记的URI用于接收授权
响应和应利用其他手段来保护资源拥有者
从这些潜在的恶意的客户端。例如，该
授权服务器可以接合该资源的所有者，以协助
识别客户端和它的起源。
授权服务器应该执行显式的资源拥有者
认证和提供有关的信息资源所有者
在客户端和请求授权范围和寿命。这是
达资源所有者审查的上下文中的信息
目前的客户端，并授权或拒绝该请求。
授权服务器不应该重复处理授权
自动请求（不活跃的资源拥有者的互动）
没有认证的客户端或依赖等措施，
确保该重复请求来自原始客户机和
不是冒领。
10.3。访问令牌
访问令牌凭据（以及任何机密访问令牌
属性）必须保密传输和存储，并
只有授权服务器之间共享的资源的服务器的
访问令牌是有效的，并在客户端向谁访问令牌是
发行。只允许使用TLS传输访问令牌凭据
如在第1.6节描述的服务器认证通过定义
[RFC2818]。
当使用隐式授予类型，接入令牌发送
在URI片段，它可以将其暴露在未经授权的第三方。
授权服务器必须确保访问令牌不能
生成，修改或猜到出示有效的访问令牌
未经授权的第三方。
客户应该要求访问令牌的最小范围
必要的。授权服务器应以客户的身份
考虑到选择如何兑现要求的范围，并可能在
发出一个访问令牌少权比要求。
本说明书中没有提供任何方法对资源
服务器，以确保访问令牌由给定提供给它
客户端是由授权服务器颁发给客户端。
10.4。刷新令牌
授权服务器可能会发出刷新令牌的Web应用程序
客户和本地应用程序客户端。
刷新令牌必须保密传输和存储，并
只在授权服务器和客户端向谁共享
刷新令牌发出。授权服务器必须保持
刷新令牌和客户端的人有之间的结合
发行。只允许使用TLS作为传输刷新令牌
通过定义在第1.6节描述的服务器认证
[RFC2818]。
授权服务器必须验证刷新之间的结合
每当客户机身份可以是令牌和客户机标识
验证。当客户端认证是不可能的，该
授权服务器应部署等手段来检测刷新
令牌滥用。
例如，授权服务器可以采用刷新令牌
在一个新的刷新令牌与每个接入转动发出
令牌刷新响应。以前的刷新令牌无效
而是由授权服务器保留。如果刷新令牌
损害并随后使用由两个攻击者和
合法的客户端，其中一人将提出一个无效的刷新
令牌，这将通知授权服务器的违反。
授权服务器必须确保刷新令牌不能
生成，修改或猜测通过，以产生有效的刷新令牌
未经授权的第三方。
10.5。授权码
授权码的传输应通过安全
信道，并在客户端应该要求使用TLS与其
redirection（重定向）的URI如果URI标识的网络资源。因为
授权码是通过用户代理重定向传播，他们
可能会通过用户代理的历史和HTTP披露
引荐头。
授权码操作明文承载凭据，用于
验证谁在授予授权资源所有者
授权服务器是相同的资源所有者返回到
客户端来完成这个过程。因此，如果客户机依赖于
为它自己的资源所有者认证授权码，则
客户端重定向端点必须要求使用TLS。
授权代码必须是短暂和一次性使用。如果
授权服务器观察多次尝试交换的
一个访问令牌授权码，授权服务器
应该尝试取消已给予基于所有的访问令牌
被感染的授权码。
如果客户端进行身份验证，授权服务器必须
认证客户机，并确保该授权码是
颁发给相同的客户端。
10.6。授权码重定向URI操作
当请求授权使用授权码授予
类型，客户端可以通过“redirect_uri”指定一个重定向的URI
参数。如果攻击者可以操纵的价值
重定向的URI，它可能会导致授权服务器重定向
资源所有者用户代理向一个URI的控制下
攻击者的授权码。
攻击者可以在一个合法的客户端创建一个帐户，并启动
授权流程。当攻击者的用户代理被发送到
授权服务器授予访问权限，攻击者劫掠
授权的URI提供的合法的客户端，并取代
10.8。要求保密
访问令牌，令牌刷新，资源所有者的密码，和客户端
证书必须不被明文传输。授权
代码不应该在明确的传输。
“国家”和“范围”参数不应该包含敏感
以纯文本的客户端或资源拥有者的信息，因为他们可以
通过不安全的通道发送或存储不安全。
10.9。确保端点真实性
为了防止人在这方面的中间人攻击，授权
服务器必须要求使用TLS与服务器的身份验证
由[RFC2818]为发送给授权的任何请求中定义和
令牌端点。客户端必须验证授权服务器的
由[RFC6125]定义TLS证书，并按照其
要求服务器身份认证。
10.10。凭据猜测攻击
授权服务器必须阻止猜测攻击者访问
令牌，授权码，刷新标记，资源所有者
密码和客户端证书。
攻击者的概率猜测生成令牌（和其他
凭证不用于处理最终用户）必须小于
或等于2^（ - 128），并应小于或等于2^（ - 160）。
授权服务器必须利用其他手段来保护
凭证供终端用户使用。
10.11。网络钓鱼攻击
广泛部署这种和类似的协议可能导致最终用户
成为习以为常面临被重定向到网站的做法
他们被要求输入密码。如果最终用户不
小心进入之前核实这些网站的真伪
他们的凭据，将有可能对攻击者利用此
实践窃取资源所有者的密码。
服务提供者应尝试教育最终用户有关的风险
钓鱼式攻击姿势，并应提供可以很容易的机制
对于最终用户，以确认他们的网站的真实性。客户
开发人员应该考虑的是如何安全的影响，他们
与用户代理（例如，外部，嵌入式）相互作用，并且
最终用户的验证的真伪能力
授权服务器。
客户端的重定向URI与URI的控制之下
攻击者。然后，攻击者诱骗受害人到下面的
操纵连杆授权访问合法的客户端。
一旦在授权服务器，受害人出现一个提示
代表一个合法的和值得信赖的客户端的正常，有效的请求，
并授权该请求。受害人随后被重定向到一个
攻击者的，与授权的控制下端点
代码。攻击者通过发送完成授权流程
使用原始重定向的URI授权码给客户端
由客户提供。客户交流的授权码
有一个访问令牌，并将其链接到攻击者的客户帐户，
现在可以访问授权的受保护的资源
受害者（经由客户机）。
为了防止这样的攻击，授权服务器MUST
确保该重定向的URI用于获得授权码
相同的URI交换时提供的重定向
授权代码的访问令牌。授权服务器
必须要求公共机构提供服务，并应要求保密的客户
登记他们的重定向的URI。如果重定向URI提供
在请求，授权服务器必须验证它靠在
注册的值。
10.7。资源所有者密码凭据
资源所有者密码凭证交付式通常用于
传统的或迁移的原因。它降低存储的总体风险
用户名和密码由客户端，但不消除需要
暴露较高权限的凭证给客户端。
此批类型携带比其他类型的授予，因为风险较高
它保持了密码的反模式该协议旨在避免。
客户端可以滥用密码，或者密码
无意间可以通过日志文件或披露给攻击者（例如，
保持客户端等记录）。
此外，由于资源所有者不具有控制权
授权过程（资源所有者的参与结束时
它移交其凭据到客户端），客户端可以获取
具有较宽范围的访问令牌比所期望的资源
所有者。授权服务器应考虑的范围和
通过这种交付式发出的访问令牌的使用寿命。
授权服务器和客户端应尽量减少使用这种补助
键入并尽可能利用其他授予类型。
为了减少网络钓鱼攻击，授权服务器的风险
必须要求对用于最终用户的每个端点使用TLS
互动。
10.12。跨站请求伪造
跨站请求伪造（CSRF）是一种攻击中，攻击者
导致受害者终端用户的用户代理遵循一个恶意的URI
（例如，提供给用户代理作为一个误导链接，图像，或
重定向）到信任的服务器（通常是通过建立
存在一个有效的会话cookie）。
针对客户端的重定向URI CSRF攻击允许攻击者
注入自己的授权码或访问令牌，该令牌可
使用与相关联的接入令牌导致客户端
攻击者的受保护的资源，而不是受害者的（例如，保存
受害人的银行账户信息，以保护资源
被攻击者控制）。
客户端必须实现其重定向URI CSRF保护。
这通常是通过要求发送到任何请求
redirection（重定向）的URI端点包括一个值，绑定请求
用户代理的认证状态（会话例如，散列
饼干用于验证用户代理）。客户端应该
利用“国家”的请求参数来实现这一价值的
授权服务器进行授权请求时。
一旦授权已被从最终用户获得的
授权服务器重定向最终用户的用户代理回
客户端包含在“状态”所需的绑定值
参数。绑定值使客户端验证
请求通过匹配的结合值的有效性
用户代理的认证状态。使用CSRF绑定值
保护必须包含一个非猜测的值（如上述
第10.10节），和用户代理的认证状态（例如，
会话cookie，HTML5本地存储）必须保持在一个位置
只可访问的客户端和用户代理（即，由保护
同源策略）。
对授权服务器的授权CSRF攻击
端点可导致攻击者获得最终用户授权
对于不涉及或提醒终端用户恶意客户端。
授权服务器必须实现对CSRF保护它
授权端点，并确保一个恶意的客户端不能
获得授权没有意识，明确同意
该资源的所有者。
在客户端建立一个重定向URI，将通过
授权服务器验证，但将发送授权码
或者接入令牌到攻击者的控制下的端点。
10.16。访问令牌误用假冒资源所有者的隐
流程
对于使用隐式流动的公共客户，这个规范不
为客户机提供的任何方法，以确定哪些客户端的接入
令牌发出。
一个资源所有者可以通过自愿委托对资源的访问
授予访问令牌到攻击者的恶意的客户端。这可能
因网络钓鱼或其他借口。攻击者还可以盗取
通过其他机制的令牌。然后，攻击者可能试图
通过提供访问令牌一个冒充资源所有者
合法的公共客户端。
在隐式流量（RESPONSE_TYPE=令牌），攻击者可以很容易地
切换令牌从授权服务器的响应，
与先前发出的一个替代真正的访问令牌
攻击者。
服务器与依靠的是原生应用程序通信
通过接入令牌在背沟道识别的用户
客户端可能被攻击者创建一个被类似地损害
受损的应用程序，可以注入任意被盗访问
标记。
任何公共客户，使得假设只有资源
车主可以凭有效的访问令牌目前它的资源
容易受到这种类型的攻击。
这种类型的攻击可能会使有关资源所有者信息
在合法的客户端攻击（恶意的客户端）。此
也将允许攻击者在合法执行操作
客户端使用相同的权限作为资源所有者原本谁
授予的访问令牌或授权的代码。
验证资源所有者给客户超出范围，这
规范。使用授权过程的任何规格
作为委托终端用户认证到客户的一种形式（例如，
第三方登录服务）不能使用隐而不流
额外的安全机制，这将使客户端
确定供其使用（例如，特定受众发出的访问令牌
限制访问令牌）。
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的Parameters注册表
第11.2节。
HTTP认证方案（S）：
在HTTP认证方案名称（S），如果有的话，用
验证使用的访问令牌保护的资源请求
此类型。
更改控制器：
对于标准跟踪RFC中，国家“IETF”。对于其他人，给的名字
的责任方。其他细节（例如，邮政地址，
电子邮件地址，主页的URI）也可以被包括在内。
规范文档（S）：
参考文件（多个）指定的参数，
优选包括可用于检索的副本的URI
该文件（多个）。相关部分也可能的指示
被包括在内，但不是必需的。
11.2。 OAuth的Parameters注册表
本规范规定了OAuth的Parameters注册表。
列入授权端点的其他参数
请求，授权端点响应时，令牌端点
请求，或令牌端点响应中注册的一
规范所要求的（[RFC5226]）在为期两周的审查期后，
在oauth-ext-review@ietf.org邮件列表，在其中一个建议或
更指定的专家。然而，为了允许的分配
值出版之前，指定的专家（S）可能会批准
注册一旦被满足，这样的规范将
发表。
登记请求必须被发送到oauth-ext-review@ietf.org
邮件列表进行审查和评论，用适当的主题
（例如，“请求参数：例如”）。
在审查期间，在指定的专家（S），要么
批准或拒绝注册请求，通信这一决定
在审查清单和IANA。否认应该包括一个解释
并且，如果适用，建议，如何使请求
成功的。
IANA只能接受指定专家注册表更新（S）
并应直接登记的审查邮寄的所有要求
列表。
11.2.1。登记模板
参数名：
请求的名称（例如，“例如”）。
参数的用法的位置：
的位置（S），其中参数可以使用。可能
地点是授权请求，授权响应，令牌
请求，或令牌响应。
更改控制器：
对于标准跟踪RFC中，国家“IETF”。对于其他人，给的名字
的责任方。其他细节（例如，邮政地址，
电子邮件地址，主页的URI）也可以被包括在内。
规范文档（S）：
参考文件（多个）指定的参数，
优选包括可用于检索的副本的URI
该文件（多个）。相关部分也可能的指示
被包括在内，但不是必需的。
11.2.2。初始登记内容
OAuth的Parameters注册表的初始内容是：
O参数名：CLIENT_ID
O参数的使用位置：授权请求，令牌请求
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：client_secret
O参数的使用位置：令牌请求
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：RESPONSE_TYPE
O参数的使用位置：授权请求
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：redirect_uri
O参数的使用位置：授权请求，令牌请求
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：范围
O参数的使用位置：授权请求，授权
对此，令牌请求，响应令牌
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：状态
O参数的使用位置：授权请求，授权
响应
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：密码
O参数的使用位置：授权响应，令牌请求
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：error_description
O参数的使用位置：授权响应，响应令牌
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：error_uri
O参数的使用位置：授权响应，响应令牌
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：grant_type
O参数的使用位置：令牌请求
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：access_token
O参数的使用位置：授权响应，响应令牌
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：token_type
O参数的使用位置：授权响应，响应令牌
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：expires_in
O参数的使用位置：授权响应，响应令牌
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：用户名
O参数的使用位置：令牌请求
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：密码
O参数的使用位置：令牌请求
O更改控制器：IETF
O规格文件（S）：RFC6749
O参数名：refresh_token
O参数的使用位置：令牌请求，响应令牌
O更改控制器：IETF
O规格文件（S）：RFC6749
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）：
参考文件（多个）指定的类型，优选
包括可用于检索的副本的URI
文件（S）。有关章节的指示也可
包括在内，但不是必需的。
11.3.2。初始登记内容
OAuth的授权端点响应类型的注册表的初始
内容是：
O响应类型名称：代码
O更改控制器：IETF
O规格文件（S）：RFC6749
O响应类型名称：令牌
O更改控制器：IETF
O规格文件（S）：RFC6749
11.4。 OAuth的扩展错误登记
本规范规定了OAuth的扩展错误的注册表。
与其他协议扩展一起使用额外的错误代码
（即延长授予的类型，访问令牌类型，或延长
参数）被注册了规范所要求的（[RFC5226]）
在oauth-ext-review@ietf.org为期两周的审查期后，
邮件列表，在其中一个建议或多个指定的专家。
然而，为了允许在出版之前的值的分配，
指定的专家（S）可能会批准登记，一旦他们
认为这样的规范将予以公布。
登记请求必须被发送到oauth-ext-review@ietf.org
邮件列表进行审查和评论，用适当的主题
（例如，“请求错误代码：例如”）。
在审查期间，在指定的专家（S），要么
批准或拒绝注册请求，通信这一决定
在审查清单和IANA。否认应该包括一个解释
并且，如果适用，建议，如何使请求
成功的。
IANA只能接受指定专家注册表更新（S）
并应直接登记的审查邮寄的所有要求
列表。
11.4.1。登记模板
错误名称：
请求的名称（例如，“例如”）。值的误差名
不能包含集％x20-21/％x23-5B/以外的字符
％X5D-7E。
错误的使用位置：
的位置（S），其中可以使用该错误。可能
地点是授权码授予错误响应
（第4.1.2.1），隐含的授予错误响应
（第4.2.2.1），令牌错误响应（第5.2节），或资源
访问错误的响应（第7.2节）。
相关协议扩展：
扩展授予类型的名称，访问令牌类型，或
该错误代码一起使用的扩展参数
用。
更改控制器：
对于标准跟踪RFC中，国家“IETF”。对于其他人，给的名字
的责任方。其他细节（例如，邮政地址，
电子邮件地址，主页的URI）也可以被包括在内。
规范文档（S）：
参考文件（多个）指定错误代码，
优选包括可用于检索的副本的URI
该文件（多个）。相关部分也可能的指示
被包括在内，但不是必需的。
12.参考
12.1。规范性引用文件
[RFC2119] Bradner，S.，“在RFC中使用的关键词来指示
要求等级“，BCP14，RFC2119，1997年3月。
[RFC2246]的Dierks，T和C·艾伦，“该TLS协议版本1.0”
RFC 2246，1999年1月。
[RFC2616]菲尔丁，R.，Gettys的，J.，辉门，J.，Frystyk，H.，
Masinter，L.，利奇，P.，和T.伯纳斯 - 李，“超文本
传输协议 - HTTP/1.1“，RFC2616，1999年6月。
[RFC2617]弗兰克斯，J.，哈勒姆 - 贝克，P.，霍斯泰特勒，J.，劳伦斯，S.，
利奇，P.，Luotonen，A.，和L.斯图尔特，“HTTP
验证：基本和摘要访问认证“，
RFC 2617，1999年6月。
[RFC2818] Rescorla，E.，“HTTP在TLS”，RFC2818，2000年5月。
[RFC3629] Yergeau，F。，“UTF-8中的一个转换格式
ISO10646“，STD63，RFC3629，2003年11月。
[RFC3986]伯纳斯 - 李，T.，菲尔丁，R.和L. Masinter，“制服
资源标识符（URI）：通用语法“，STD66，
RFC3986，2005年1月。
[RFC4627]克罗克福德，D.，“应用/ JSON纸张类型
JavaScript对象符号（JSON）“，RFC4627，2006年7月。
[RFC4949] Shirey，R.，“互联网安全术语表，第2版”
RFC4949，2007年8月。
[RFC5226] Narten，T.和H. Alvestrand，“指南编写一个
IANA考虑在RFC中节“，BCP26，RFC5226，
2008年5月。
[RFC5234]克罗克，D和P. Overell，“增强BNF的语法
产品规格：ABNF“，STD68，RFC5234，2008年1月。
[RFC5246]的Dierks，T和E. Rescorla，“传输层安全
（TLS）协议1.2版“，RFC5246，2008年8月。
[RFC6125]圣安德烈，P.和J·霍奇斯，“代表和
基于域的应用服务身份验证
在使用X.509互联网公钥基础设施
（PKIX）在传输层的语境证书
安全（TLS）“，RFC6125，2011年3月。
[USASCII]美国国家标准协会，“编码字符
集 - 7位ASCII码信息
交换“，ANSI X3.4，1986。
[W3C.REC-html401-19991224]
Raggett，D.，乐餐前，A.，和一雅各布，“HTML 4.01
规范“，万维网联盟
建议REC-html401-19991224，1999年12月，
<http://www.w3.org/TR/1999/REC-html401-19991224>。
[W3C.REC-XML-20081126]
布雷，T.，保利，J.，Sperberg - 麦奎因，C.，MALER，E.，
和F Yergeau，“可扩展标记语言（XML）1.0
（第五版）“，万维网联盟
建议REC-XML-20081126，2008年11月，
<http://www.w3.org/TR/2008/REC-xml-20081126>。
12.2。参考信息
[OAuth的-HTTP-MAC]
锤Lahav，E.，爱德，“HTTP验证：MAC访问
身份验证“，在进步，2012年2月工作。
[OAuth的SAML2]
坎贝尔B.和C. Mortimore，“SAML2.0断言承载
对于OAuth的2.0“配置文件，在进步，2012年9月的工作。
[OAuth的THREATMODEL]
Lodderstedt，T。编，McGloin，M。，和P.亨特“的OAuth2.0
威胁模型和安全注意事项“，工作
进展，2012年10月。
[OAuth的WRAP]
哈特，D.，版，汤姆，A.，伊顿，B.，和Y的Goland“的OAuth
网络资源授权配置文件“，在工作中奋进，
2010年1月。
[RFC5849]锤Lahav，E.，“的的OAuth1.0协议”，RFC5849，
2010年4月。
[RFC6750]琼斯，M和D哈特“的的OAuth2.0授权
框架：承载令牌的使用“，RFC6750，2012年10月。
【rfc6749】机翻 The OAuth 2.0 Authorization Framework