RESTful API架构和oauth2.0认证机制（概念版）
1. 什么是REST
REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。" 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。
REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。
2. 理解RESTful
要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。
下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。
- 资源与URI
- 统一资源接口
- 资源的表述
- 资源的链接
- 状态的转移
2. 1 资源与URI
REST全称是表述性状态转移，那究竟指的是什么的表述? 其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：
- 某用户的手机号码
- 某用户的个人信息
- 最多用户订购的GPRS套餐
- 两个产品之间的依赖关系
- 某用户可以办理的优惠套餐
- 某手机号码的潜在价值
要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。
URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。这里以github网站为例，给出一些还算不错的URI：
- https://github.com/git
- https://github.com/git/git
- https://github.com/git/git/blob/master/block-sha1/sha1.h
- https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
- https://github.com/git/git/pulls
- https://github.com/git/git/pulls?state=closed
- https://github.com/git/git/compare/master…next
下面让我们来看看URI设计上的一些技巧:
- 使用_或-来让URI可读性更好
曾经Web上的URI都是冰冷的数字或者无意义的字符串，但现在越来越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。 例如国内比较出名的开源中国社区，它上面的新闻地址就采用这种风格， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。
- 使用/来表示资源的层级关系
例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一个多级的资源， 指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。
- 使用?用来过滤资源
很多人只是把?简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把?用于对资源的过滤， 例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求， 这种URL通常对应的是一些特定条件的查询结果或算法运算结果。
- ,或;可以用来表示同级资源的关系
有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作为URI。 不过，现在github是使用…来做这个事情的，例如/git/git/compare/master…next。
2. 2 统一资源接口
RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。
如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响。
下面列出了GET，DELETE，PUT和POST的典型用法:
GET
- 安全且幂等
- 获取表示
- 变更时获取表示（缓存）
- 200（OK） - 表示已在响应中发出
- 204（无内容） - 资源有空表示
- 301（Moved Permanently） - 资源的URI已被更新
- 303（See Other） - 其他（如，负载均衡）
- 304（not modified）- 资源未更改（缓存）
- 400 （bad request）- 指代坏请求（如，参数错误）
- 404 （not found）- 资源不存在
- 406 （not acceptable）- 服务端不支持所需表示
- 500 （internal server error）- 通用错误响应
- 503 （Service Unavailable）- 服务端当前无法处理请求
POST
- 不安全且不幂等
- 使用服务端管理的（自动产生）的实例号创建资源
- 创建子资源
- 部分更新资源
- 如果没有被修改，则不过更新资源（乐观锁）
- 200（OK）- 如果现有资源已被更改
- 201（created）- 如果新资源被创建
- 202（accepted）- 已接受处理请求但尚未完成（异步处理）
- 301（Moved Permanently）- 资源的URI被更新
- 303（See Other）- 其他（如，负载均衡）
- 400（bad request）- 指代坏请求
- 404 （not found）- 资源不存在
- 406 （not acceptable）- 服务端不支持所需表示
- 409 （conflict）- 通用冲突
- 412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
- 415 （unsupported media type）- 接受到的表示不受支持
- 500 （internal server error）- 通用错误响应
- 503 （Service Unavailable）- 服务当前无法处理请求
PUT
- 不安全但幂等
- 用客户端管理的实例号创建一个资源
- 通过替换的方式更新资源
- 如果未被修改，则更新资源（乐观锁）
- 200 （OK）- 如果已存在资源被更改
- 201 （created）- 如果新资源被创建
- 301（Moved Permanently）- 资源的URI已更改
- 303 （See Other）- 其他（如，负载均衡）
- 400 （bad request）- 指代坏请求
- 404 （not found）- 资源不存在
- 406 （not acceptable）- 服务端不支持所需表示
- 409 （conflict）- 通用冲突
- 412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
- 415 （unsupported media type）- 接受到的表示不受支持
- 500 （internal server error）- 通用错误响应
- 503 （Service Unavailable）- 服务当前无法处理请求
DELETE
- 不安全但幂等
- 删除资源
- 200 （OK）- 资源已被删除
- 301 （Moved Permanently）- 资源的URI已更改
- 303 （See Other）- 其他，如负载均衡
- 400 （bad request）- 指代坏请求
- 404 （not found）- 资源不存在
- 409 （conflict）- 通用冲突
- 500 （internal server error）- 通用错误响应
- 503 （Service Unavailable）- 服务端当前无法处理请求
下面我们来看一些实践中常见的问题:
- POST和PUT用于创建资源时有什么区别?
POST和PUT在创建资源的区别在于，所创建的资源的名称(URI)是否由客户端决定。 例如为我的博文增加一个java的分类，生成的路径就是分类名/categories/java，那么就可以采用PUT方法。不过很多人直接把POST、GET、PUT、DELETE直接对应上CRUD，例如在一个典型的rails实现的RESTful应用中就是这么做的。
我认为，这是因为rails默认使用服务端生成的ID作为URI的缘故，而不少人就是通过rails实践REST的，所以很容易造成这种误解。
- 客户端不一定都支持这些HTTP方法吧?
的确有这种情况，特别是一些比较古老的基于浏览器的客户端，只能支持GET和POST两种方法。
在实践上，客户端和服务端都可能需要做一些妥协。例如rails框架就支持通过隐藏参数_method=DELETE来传递真实的请求方法， 而像Backbone这样的客户端MVC框架则允许传递_method传输和设置X-HTTP-Method-Override头来规避这个问题。
- 统一接口是否意味着不能扩展带特殊语义的方法?
统一接口并不阻止你扩展方法，只要方法对资源的操作有着具体的、可识别的语义即可，并能够保持整个接口的统一性。
像WebDAV就对HTTP方法进行了扩展，增加了LOCK、UPLOCK等方法。而github的API则支持使用PATCH方法来进行issue的更新，例如:
PATCH /repos/:owner/:repo/issues/:number
不过，需要注意的是，像PATCH这种不是HTTP标准方法的，服务端需要考虑客户端是否能够支持的问题。
- 统一资源接口对URI有什么指导意义?
统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。
通俗来说，URI不应该使用动作来描述。例如，下面是一些不符合统一接口要求的URI:
- GET /getUser/1
- POST /createUser
- PUT /updateUser/1
- DELETE /deleteUser/1
如果GET请求增加计数器，这是否违反安全性?
安全性不代表请求不产生副作用，例如像很多API开发平台，都对请求流量做限制。像github，就会限制没有认证的请求每小时只能请求60次。
但客户端不是为了追求副作用而发出这些GET或HEAD请求的，产生副作用是服务端"自作主张"的。
另外，服务端在设计时，也不应该让副作用太大，因为客户端认为这些请求是不会产生副作用的。
- 直接忽视缓存可取吗?
即使你按各个动词的原本意图来使用它们，你仍可以轻易禁止缓存机制。 最简单的做法就是在你的HTTP响应里增加这样一个报头： Cache-control: no-cache。 但是，同时你也对失去了高效的缓存与再验证的支持(使用Etag等机制)。
对于客户端来说，在为一个REST式服务实现程序客户端时，也应该充分利用现有的缓存机制，以免每次都重新获取表示。
- 响应代码的处理有必要吗?
HTTP的响应代码可用于应付不同场合，正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上进行沟通。
例如，201（"Created"）响应代码表明已经创建了一个新的资源，其URI在Location响应报头里。
假如你不利用HTTP状态代码丰富的应用语义，那么你将错失提高重用性、增强互操作性和提升松耦合性的机会。
如果这些所谓的RESTful应用必须通过响应实体才能给出错误信息，那么SOAP就是这样的了，它就能够满足了。
2. 3 资源的表述
上面提到，客户端通过HTTP方法可以获取资源，是吧? 不，确切的说，客户端获取的只是资源的表述而已。 资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。 例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。
资源的表述包括数据和描述数据的元数据，例如，HTTP头"Content-Type" 就是这样一个元数据属性。
那么客户端如何知道服务端提供哪种表述形式呢?
答案是可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。
以github为例，请求某组织资源的json格式的表述形式:
假如github也能够支持xml格式的表述格式，那么结果就是这样的:
下面我们来看一些实践上常见的设计:
在URI里边带上版本号
有些API在URI里边带上版本号，例如:
- http://api.example.com/1.0/foo
- http://api.example.com/1.2/foo
- http://api.example.com/2.0/foo
如果我们把版本号理解成资源的不同表述形式的话，就应该只是用一个URL，并通过Accept头部来区分，还是以github为例，它的Accept的完整格式是:application/vnd.github[.version].param[+json]
对于v3版本的话，就是Accept: application/vnd.github.v3。对于上面的例子，同理可以使用使用下面的头部:
- Accept: vnd.example-com.foo+json; version=1.0
- Accept: vnd.example-com.foo+json; version=1.2
- Accept: vnd.example-com.foo+json; version=2.0
使用URI后缀来区分表述格式
像rails框架，就支持使用/users.xml或/users.json来区分不同的格式。 这样的方式对于客户端来说，无疑是更为直观，但混淆了资源的名称和资源的表述形式。 我个人认为，还是应该优先使用内容协商来区分表述格式。
如何处理不支持的表述格式
当服务器不支持所请求的表述格式，那么应该怎么办？若服务器不支持，它应该返回一个HTTP 406响应，表示拒绝处理该请求。下面以github为例，展示了一个请求XML表述资源的结果：
2. 4 资源的链接
我们知道REST是使用标准的HTTP方法来操作资源的，但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。
这种反模式忽略了一个核心概念："超媒体即应用状态引擎（hypermedia as the engine of application state）"。 超媒体是什么?
当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来.
要达到这个目的，就要求在表述格式里边加入链接来引导客户端。在《RESTful Web Services》一书中，作者把这种具有链接的特性成为连通性。下面我们具体来看一些例子。
下面展示的是github获取某个组织下的项目列表的请求，可以看到在响应头里边增加Link头告诉客户端怎么访问下一页和最后一页的记录。 而在响应体里边，用url来链接项目所有者和项目地址。
又例如下面这个例子，创建订单后通过链接引导客户端如何去付款。
上面的例子展示了如何使用超媒体来增强资源的连通性。很多人在设计RESTful架构时，使用很多时间来寻找漂亮的URI，而忽略了超媒体。所以，应该多花一些时间来给资源的表述提供链接，而不是专注于"资源的CRUD"。
2. 5 状态的转移
有了上面的铺垫，再讨论REST里边的状态转移就会很容易理解了。
不过，我们先来讨论一下REST原则中的无状态通信原则。初看一下，好像自相矛盾了，既然无状态，何来状态转移一说?
其实，这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。
2. 5.1 应用状态与资源状态
实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。
客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。
服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。
这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。
在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。
但有时候我们会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。
这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。
当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。
2. 5.2 应用状态的转移
状态转移到这里已经很好理解了， "会话"状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。
这些类似"下一页"之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。
3. 总结
现在广东XXX版本、XXX等项目中均使用传统的RPC、SOAP方式的Web服务，而移动南方基地XXXX项目的后台， 虽然采用了JSON格式进行交互，但还是属于RPC风格的。本文从资源的定义、获取、表述、关联、状态变迁等角度， 试图快速理解RESTful架构背后的概念。RESTful架构与传统的RPC、SOAP等方式在理念上有很大的不同，希望本文能对各位理解REST有所帮助。
RESTfulAPI架构转载于 http://www.runoob.com/w3cnote/restful-architecture.html
在传统的客户端 - 服务器认证模型中，客户端 请求访问受限资源（受保护资源） 服务器通过使用资源所有者的服务器进行身份验证 证书。为了提供第三方应用程序访问权限 受限资源，资源所有者与其共享凭证 第三方。这造成了几个问题和局限性： o第三方应用程序需要存储资源 所有者的凭据供将来使用，通常是密码 明文。 o尽管如此，服务器仍然需要支持密码认证 密码固有的安全弱点。 o第三方应用程序获得对资源的过度广泛访问 所有者的受保护资源，使资源所有者无任何责任 限制持续时间或访问有限子集的能力 资源。 o资源所有者不能撤销对个人第三方的访问权限 而不会取消所有第三方的访问权限，并且必须通过 更改第三方的密码。o妥协的任何第三方应用程序导致妥协 最终用户的密码以及所有受其保护的数据 密码。 OAuth通过引入授权层来解决这些问题 并将客户的角色与资源的角色分开 所有者。在OAuth中，客户端请求访问受控资源 由资源所有者和资源服务器托管，并且是 发布了不同于该资源的凭证 所有者。 而不是使用资源所有者的凭据来访问受保护的 资源，客户端获得一个访问令牌 - 一个表示一个字符串的字符串 特定范围，生命周期和其他访问属性。访问令牌 由授权服务器向第三方客户发放 资源所有者的批准。客户端使用访问令牌 访问由资源服务器托管的受保护资源。 例如，最终用户（资源所有者）可以授予打印 服务（客户端）访问存储在照片上的受保护照片， 共享服务（资源服务器），而不共享她的用户名和密码 密码与打印服务。相反，她认证 直接与照片共享服务所信任的服务器直接相连 （授权服务器），它发布打印服务委托 - 特定凭证（访问令牌）。 本规范旨在与HTTP（[ RFC2616 ]）一起使用。该 通过除HTTP以外的任何协议使用OAuth超出范围。 OAuth 1.0协议（[ RFC5849 ]），作为信息发布 文件，是小型特别社区努力的结果。这个 Standards Track规范基于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应该在不做任何假设的情况下处理本文档 其结构和细节。OAuth定义了四个角色： 资源所有者 一个能够授权访问受保护资源的实体。 当资源所有者是一个人时，它被称为一个人 最终用户。 资源服务器 承载受保护资源的服务器，能够接受 并使用访问令牌响应受保护的资源请求。 客户 一个应用程序代表 资源所有者和授权。术语“客户”的确如此 并不意味着任何特定的实施特征（例如， 应用程序是否在服务器，桌面或其他应用程序上执行 设备）。 授权服务器 服务器成功后向客户端发放访问令牌 验证资源所有者并获得授权。 授权服务器和资源服务器之间的交互 超出了本规范的范围。授权服务器 可以是与资源服务器相同的服务器或单独的实体。 一个授权服务器可能会发出接受的访问令牌 多个资源服务器。+ -------- + + --------------- + | | - （A） - 授权请求 - > | 资源| | | | 所有者| | | < - （B） - 授权许可 - | | | | + --------------- + | | | | + --------------- + | | - （C） - 授权许可 - > | 授权| | 客户端| | 服务器| | | < - （D）-----访问令牌------- | | | | + --------------- + | | | | + --------------- + | | - （E）-----访问令牌------> | 资源| | | | 服务器| | | < - （F）---受保护的资源--- | | + -------- + + --------------- + 图1：抽象协议流程 图1中所示的抽象OAuth 2.0流程描述了 四个角色之间的交互，并包括以下步骤： （A）客户端请求来自资源所有者的授权。该 可以直接向资源所有者授权请求 （如图所示），或者优选间接通过授权 服务器作为中介。 （B）客户收到授权许可，这是一个 代表资源所有者授权的凭证， 用本文定义的四种授权类型之一表示 规范或使用扩展授权类型。该 授权授予类型取决于使用的方法 客户端请求授权和类型支持的类型 授权服务器。 （C）客户通过使用身份验证来请求访问令牌 授权服务器并提交授权许可。 （D）授权服务器验证客户端并验证 授权许可，如果有效，则发出访问令牌。（E）客户端从资源请求受保护的资源 服务器并通过呈现访问令牌进行身份验证。 （F）资源服务器验证访问令牌，如果有效， 服务于请求。 客户获得授权许可的首选方法 来自资源所有者（在步骤（A）和（B）中描述）是使用 授权服务器作为中介，如图所示第4.1节中的 图3 。 授权许可是代表资源的凭证 所有者授权（访问其受保护的资源） 客户端来获取访问令牌。这个规范定义了四个 授予类型 - 授权码，隐式，资源所有者密码 凭据和客户端凭据 - 以及可扩展性 定义附加类型的机制。 授权码是使用授权服务器获得的 作为客户和资源所有者之间的中介。代替 直接从资源所有者，客户端请求授权 将资源所有者引导至授权服务器（通过其授权服务器） 用户代理，如[ RFC2616 ]中所定义的），这反过来指导着 资源所有者用授权码返回给客户端。 在将资源所有者重定向到客户端之前 授权码，授权服务器验证 资源所有者并获得授权。因为资源所有者 只与授权服务器，资源进行身份验证 所有者的凭证永远不会与客户共享。 授权代码提供了一些重要的安全优势， 如验证客户端的能力，以及 无需将访问令牌直接传输到客户端 将其传递给资源所有者的用户代理和潜在的用户代理 将其展示给其他人，包括资源所有者。 隐式授权是优化的简化授权码流 对于使用脚本语言等在浏览器中实现的客户端 作为JavaScript。在隐式流程中，而不是发布客户端 一个授权码，客户端直接发出访问令牌（作为资源所有者授权的结果）。授予类型 是隐含的，因为没有中间凭据（例如授权 代码）被发布（并且随后用于获得访问令牌）。 在隐式授权流程期间发出访问令牌时， 授权服务器不认证客户端。在一些 情况下，客户端身份可以通过重定向URI进行验证 用于将访问令牌传递给客户端。访问令牌可能 暴露给资源所有者或其他有权访问的应用程序 资源所有者的用户代理。 隐性赠款可以提高某些人的反应速度和效率 客户端（例如作为浏览器内应用程序实现的客户端）， 因为它减少了获得一个所需的往返次数 访问令牌。但是，这种便利应该权衡 使用隐含授权的安全影响，如那些 在10.3节和10.16节中介绍，特别是当 授权码授权类型可用。 。 资源所有者密码凭证（即用户名和密码） 可以直接用作授权许可来获得访问权限 令牌。这些凭据只能在高价时使用 资源所有者与客户之间的信任度（例如， 客户端是设备操作系统的一部分或高度特权 应用程序），以及其他授权授权类型不适用时 可用（例如授权码）。 即使这种授予类型需要直接客户端访问 资源所有者凭证，则使用资源所有者凭证 对于单个请求并交换访问令牌。这个 授予类型可以消除客户端存储的需要 资源所有者凭据以供将来使用，通过交换 具有长期访问令牌或刷新令牌的凭证。 。 客户端凭据（或其他形式的客户端身份验证）可以 作为授权范围时的授权许可 限于受客户控制的受保护资源， 或先前安排授权的受保护资源 服务器。客户端凭证用作授权许可 通常当客户以自己的名义行事时（客户是 也是资源所有者）或正在请求访问受保护的资源 资源基于先前安排的授权 授权服务器。访问令牌是用于访问受保护资源的凭证。一个 访问令牌是一个字符串，表示授予该授权的授权 客户。该字符串通常对客户端不透明。令牌 代表访问的具体范围和持续时间，由授予 资源所有者，并由资源服务器和授权执行 服务器。 令牌可以表示用于检索授权的标识符 信息或者可以自行包含授权信息 可验证的方式（即由一些数据和a组成的标记字符串 签名）。额外的认证证书，超越 本规范的范围，可能需要为了 客户端使用令牌。 访问令牌提供了一个抽象层，取代了不同的层 授权构造（例如，用户名和密码）与单一 令牌可以被资源服务器理解。这种抽象使能 发放比授权授权更具限制性的访问令牌 用于获取它们，以及删除资源服务器的需求 了解广泛的认证方法。 访问令牌可以具有不同的格式，结构和方法 基于资源的利用（例如，密码特性） 服务器安全要求。访问令牌属性和 用于访问受保护资源的方法超出了范围 这个规范是由相关规范等定义的 作为[ RFC6750 ]。 。 刷新令牌是用于获取访问令牌的凭证。刷新 令牌是由授权服务器发给客户端的 用于获取当前访问令牌的新访问令牌 变为无效或到期，或获得额外的访问令牌 具有相同或更窄的范围（访问令牌可能更短 终身和更少的权限比资源授权 所有者）。发布刷新令牌是可选的，可以自行决定 授权服务器。如果授权服务器发出刷新 令牌，它包含在发出访问令牌时（即步骤（D）） 图1）。 刷新令牌是表示授予的授权的字符串 客户端由资源所有者。该字符串通常是不透明的 客户端。令牌表示用于检索的标识符授权信息。与访问令牌不同，刷新令牌是 打算只用于授权服务器，并且从不发送 到资源服务器。 + -------- + + --------------- + | | - （A）-------授权津贴---------> | | | | | | | | < - （B）-----------访问令牌------------- | | | | 刷新令牌| | | | | | | | + ---------- + | | | | - （C）----访问令牌----> | | | | | | | | | | | | < - （D） - 受保护的资源 - | 资源| | 授权| | 客户端| | 服务器| | 服务器| | | - （E）----访问令牌----> | | | | | | | | | | | | < - （F） - 令牌错误无效 - | | | | | | + ---------- + | | | | | | | | - （G）-----------刷新令牌-----------> | | | | | | | | < - （H）-----------访问令牌------------- | | + -------- +＆可选刷新令牌+ --------------- + 图2：刷新过期的访问令牌 图2所示的流程包括以下步骤： （A）客户通过使用身份验证来请求访问令牌 授权服务器并提交授权许可。 （B）授权服务器认证客户端并验证 授权许可，如果有效，则发出访问令牌 和一个刷新令牌。 （C）客户端向资源发出受保护的资源请求 服务器通过提供访问令牌。 （D）资源服务器验证访问令牌，如果有效， 服务于请求。 （E）重复步骤（C）和（D），直到访问令牌到期。如果 客户端知道访问令牌已过期，跳到步骤（G）; 否则，它会发出另一个受保护资源请求。 （F）由于访问令牌无效，资源服务器返回 无效的令牌错误。（G）客户端通过身份验证请求新的访问令牌 授权服务器并呈现刷新令牌。该 客户端身份验证要求基于客户端类型 和授权服务器策略。 （H）授权服务器认证客户端并验证 刷新令牌，如果有效，则发出新的访问令牌（并且， 可选地，新的刷新令牌）。 步骤（C），（D），（E）和（F）不在此范围内 规范，如第7节所述。 。 无论何时使用传输层安全性（TLS） 规范，TLS的适当版本（或多个版本）会有所不同 随着时间的推移，基于广泛的部署和已知的安全性 漏洞。在撰写本文时，TLS版本1.2 [ RFC5246 ]是最新的版本，但有一个非常有限的 部署基地，并且可能不容易获得 实现。TLS版本1.0 [ RFC2246 ]是最广泛的 部署版本并将提供最广泛的互操作性。 实现也可以支持额外的传输层安全 满足其安全要求的机制。 。 该规范广泛使用HTTP重定向，其中 客户端或授权服务器指导资源所有者 用户代理到另一个目的地。虽然在这个例子 规范显示使用HTTP 302状态码，任何其他 方法可通过用户代理完成此重定向 被允许并且被认为是实现细节。 。 OAuth 2.0提供了一个具有明确定义的丰富的授权框架 安全属性。但是，作为一个富有和高度可扩展的 这个框架包含许多可选组件 规范很可能会产生大范围的非互操作性 实现。 另外，这个规范留下了一些必需的组件 部分或完全未定义（例如，客户注册， 授权服务器功能，端点发现）。没有这些组件，客户端必须手动和专门 针对特定授权服务器和资源进行配置 服务器以便互操作。 这个框架的设计有着明确的未来 工作将定义必要的规定性配置文件和扩展 实现全面的网络规模互操作性。 。 关键词“必须”，“不得”，“需要”，“应该”，“不应该”， “应该”，“不应该”，“推荐”，“可能”和“可选” 规范应按 [ RFC2119 ]中的描述进行解释。 本规范使用增强的Backus-Naur表单（ABNF） [ RFC5234 ]的符号。另外，规则URI引用是 从“统一资源标识符（URI）：通用语法” [ RFC3986 ]。 某些安全相关的术语在某种意义上应该被理解 在[ RFC4949 ]中定义。这些条款包括但不限于， “攻击”，“认证”，“授权”，“证书”， “机密性”，“凭证”，“加密”，“身份”，“标志”， “签名”，“信任”，“验证”和“验证”。 除非另有说明，否则所有协议参数名称和值 区分大小写。 。 在启动协议之前，客户端使用 授权服务器。客户注册的手段 与授权服务器不在此范围之内 规范，但通常涉及最终用户与HTML的交互 报名表格。 客户注册不需要直接互动 客户端和授权服务器。当被支持的时候 授权服务器，注册可以依靠其他手段进行 建立信任并获得所需的客户属性 （例如，重定向URI，客户端类型）。例如，注册可以 通过自发或第三方发布的断言来完成， 或者由授权服务器使用a执行客户端发现 可信渠道。在注册客户端时，客户端开发者应该： o按2.1节所述指定客户端类型， o按3.1.2节所述提供其客户端重定向URI ， 和 o包括授权服务器要求的任何其他信息 （例如，应用程序名称，网站，说明，徽标图像， 接受法律条款）。 。 OAuth根据他们的能力定义了两种客户端类型 使用授权服务器进行安全认证（例如， 保持其客户证书的机密性）： 机密 有能力维护他们的隐私的客户 凭证（例如，在安全服务器上实施的客户端 对客户端证书的访问受限）或安全 客户认证使用其他手段。 上市 无法维护其客户机密的客户 凭据（例如，在设备上使用的客户端上执行的客户端） 资源所有者，例如已安装的本机应用程序或Web 基于浏览器的应用程序），并且不具备安全的客户端 通过任何其他方式进行认证 客户端类型指定基于授权服务器 安全认证的定义及其可接受的暴露 客户端凭证级别。授权服务器不应该 对客户类型做出假设。 客户可以作为分布式组件来实现，每个组件都可以实现 与不同的客户端类型和安全上下文（例如，a 分布式客户端同时拥有一个基于服务器的机密组件 和一个基于浏览器的公共组件）。如果授权服务器 不为这些客户提供支持或不提供 有关其注册的指导，客户应该 将每个组件注册为单独的客户端。本规范是围绕以下客户设计的 简介： Web应用程序 Web应用程序是在网络上运行的机密客户端 服务器。资源所有者通过HTML用户访问客户端 界面呈现在用户代理上使用的设备上 资源所有者。客户端凭证以及任何访问权限 发给客户端的令牌存储在Web服务器上并且是 没有暴露给资源所有者或可被资源所有者访问 基于用户代理的应用程序 基于用户代理的应用程序是一个公共客户， 客户端代码从Web服务器下载并在一个 用户代理（例如，网络浏览器）在资源使用的设备上 所有者。协议数据和证书很容易访问（和 经常可见）给资源所有者。自此类应用程序 驻留在用户代理中，他们可以无缝地使用该用户代理 用户代理功能请求授权时。 原生应用程序 本地应用程序是在其上安装并执行的公共客户端 资源所有者使用的设备。协议数据和 资源所有者可以访问证书。假定 包含在任何客户端身份验证凭证中 应用程序可以被提取。另一方面，动态地 颁发证书，如访问令牌或刷新令牌可以 获得可接受的保护水平。至少，这些 证书被保护免受敌方服务器的攻击 应用程序可能会交互 在某些平台上，这些凭据 可能会受到其他应用程序的保护 设备。 。 授权服务器向注册客户端发出客户端 标识符 - 表示注册的唯一字符串 客户提供的信息。客户端标识符不是 秘密; 它暴露给资源所有者，不得使用 单独用于客户端认证。客户端标识符是唯一的 授权服务器。 客户端标识符字符串大小由此未定义 规范。客户应该避免对此做出假设 标识符大小。授权服务器应该记录大小 它发布的任何标识符。如果客户类型是保密的，客户和授权 服务器建立适合于客户端的认证方法 授权服务器的安全要求。授权 服务器可以接受任何形式的客户端认证 安全要求。 机密客户通常发布（或建立）一组 客户端凭证，用于与授权进行身份验证 服务器（例如，密码，公钥/私钥对）。 授权服务器可以建立客户端认证方法 与公共客户。但是，授权服务器不能依赖 在公共客户端身份验证上进行识别 客户。 客户端不得在每个中使用多个身份验证方法 请求。 。 拥有客户密码的客户可以使用HTTP Basic 认证方案在[ RFC2617 ]中进行了认证 授权服务器。客户端标识符使用 “application / x-www-form-urlencoded”编码算法 附录B，编码值用作用户名; 客户端 密码使用相同的算法进行编码并用作 密码。授权服务器必须支持HTTP Basic 身份验证方案，用于身份验证客户端已颁发a 客户密码。 例如（仅用于显示目的的额外换行符）： 授权：基本czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 或者，授权服务器可以支持包括 请求主体中的客户端凭证使用以下内容 参数： CLIENT_ID 需要。客户端标识符在发送给客户端的过程中第2.2节 所述的注册过程。 client_secret 需要。客户的秘密。客户可以忽略 参数如果客户端密码是空字符串。使用这两者在请求主体中包含客户端凭证 不推荐使用参数，并且应该仅限于无法使用的客户端 直接利用HTTP基本认证方案（或其他） 基于密码的HTTP认证方案）。参数只能 在请求主体中传送，不得包含在请求主体中 请求URI。 例如，使用一个请求刷新访问令牌（第6节） 身体参数（带有用于显示目的的额外换行符 只要）： POST /令牌HTTP / 1.1 主机：server.example.com 内容类型：application / x-www-form-urlencoded grant_type = refresh_token＆refresh_token = tGzv3JOkF0XG5Qx2TlKWIA ＆CLIENT_ID = s6BhdRkqt3＆client_secret = 7Fjfp0ZBr1KtDRbnfVdmIw 授权服务器必须按要求使用TLS 使用密码认证发送请求时，请参见1.6节。 由于此客户端身份验证方法涉及密码，因此 授权服务器必须保护任何使用它的端点 蛮力攻击。 。 授权服务器可以支持任何合适的HTTP认证 方案符合其安全要求。当使用其他 认证方法，授权服务器必须定义一个 客户端标识符（注册记录）与之间的映射 认证方案。 。 本规范不排除使用未注册的客户端。 但是，这种客户的使用超出了这个范围 规范并需要额外的安全分析和审查 其互操作性的影响。授权过程使用两个授权服务器端点 （HTTP资源）： o授权端点 - 客户端用来获取 通过用户代理重定向从资源所有者获得授权。 o令牌端点 - 由客户端用来交换授权 授予访问令牌，通常使用客户端验证。 以及一个客户端端点： o重定向端点 - 授权服务器用于返回 包含授权凭证的响应通过客户端 资源所有者用户代理。 并非每个授权许可类型都使用两个端点。 扩展授权类型可以根据需要定义附加端点。 。 授权端点用于与资源进行交互 所有者并获得授权许可。授权服务器 必须首先验证资源所有者的身份。在中的方式 授权服务器认证资源所有者 （例如，用户名和密码登录，会话cookie）超出了 本规范的范围。 客户通过哪种方式获得该地点的手段 授权端点超出了本规范的范围， 但该位置通常在服务文档中提供。 端点URI可以包含“application / x-www-form-urlencoded” 格式化（按附录B）查询组件（[RFC3986]第3.4节）， 当添加额外的查询参数时必须保留这些参数。该 端点URI不能包含片段组件。 由于对授权端点的请求导致用户 身份验证和传输明文凭证（在 HTTP响应），授权服务器必须要求使用TLS 如第1.6节所述向请求发送请求时 授权端点。 授权服务器必须支持使用HTTP“GET” 方法[ RFC2616 ]授权端点，并可以支持 也使用“POST”方法。不带值的发送参数必须被视为是 从请求中省略。授权服务器必须忽略 无法识别的请求参数。请求和响应参数 不得多于一次。 。 授权代码授权使用授权端点 类型和隐式授权类型流程。客户通知 使用以下方式获得期望授权类型的授权服务器 参数： RESPONSE_TYPE 需要。该值必须是用于请求的“代码”之一 授权码，如第4.1.1节 “token”所述 请求访问令牌（隐式授权），如所述 第4.2.1节或8.4节所述的注册扩展值 。 扩展响应类型可能包含空格分隔的（％x20）列表 值，其中值的顺序无关紧要（例如，响应 类型“a b”与“b a”相同）。这种复合材料的含义 响应类型由其各自的规格定义。 如果授权请求缺少“response_type”参数， 或者如果响应类型不理解，授权服务器 必须按4.1.2.1节所述返回错误响应。 。 在完成与资源所有者的交互之后， 授权服务器将资源所有者的用户代理引导回 客户端。授权服务器将用户代理重定向到 客户端的重定向端点以前与 授权服务器在客户端注册过程中或何时进行 作出授权请求。 重定向端点URI必须是由定义的绝对URI [RFC3986]第4.3节。端点URI可以包含一个 “application / x-www-form-urlencoded”格式化（按附录B）查询 组件（[RFC3986] 3.4节），它必须在添加时保留 额外的查询参数。端点URI不能包含a 片段组件。重定向端点应该按照描述的要求使用TLS 在第1.6节中，当请求的响应类型是“代码”或“令牌”时， 或者当重定向请求将导致传输时 敏感的凭据通过开放的网络。本规范确实如此 不要求使用TLS，因为在撰写本文时， 要求客户部署TLS对许多人来说是一个重大障碍 客户开发者。如果TLS不可用，则授权服务器 应该在之前警告资源所有者有关不安全的端点 重定向（例如，在授权期间显示消息 请求）。 传输层安全性的缺乏可能会对系统造成严重影响 客户端的安全性以及授权的受保护资源 访问。特别是使用传输层安全性 批准过程作为一种形式使用时很关键 由客户（例如，第三方）委托最终用户认证 登录服务）。 。 授权服务器必须要求以下客户端 注册他们的重定向端点： o公共客户。 o使用隐式授权类型的机密客户端。 授权服务器应该要求所有客户端注册它们 重定向端点在使用授权端点之前。 授权服务器应该要求客户端提供 完整的重定向URI（客户端可以使用“状态”请求 参数来实现每个请求的定制）。如果需要的话 完整的重定向URI的注册是不可能的， 授权服务器应该要求注册URI 方案，权限和路径（允许客户动态变化 请求时只有重定向URI的查询组件 授权）。 授权服务器可以允许客户端注册多个 重定向端点。 没有重定向URI注册要求可以启用一个 攻击者使用授权端点作为开放重定向器 如10.15节所述。如果多个重定向URI已被注册，则只有部分 重定向URI已被注册，或者没有重定向URI 已被注册，客户端必须包含重定向URI 授权请求使用“redirect_uri”请求参数。 当重定向URI包含在授权请求中时， 授权服务器必须比较并匹配收到的值 针对至少一个注册的重定向URI（或URI） 组件），如第6节中所定义，如果有任何重定向 URI已注册。如果客户注册包括全部 重定向URI，授权服务器必须比较这两个URI 使用第6.2.1节中定义的简单字符串比较。 。 如果授权请求由于缺失而未通过验证， 无效的或不匹配的重定向URI，即授权服务器 应该通知资源所有者该错误，并且不应该 自动将用户代理重定向到无效的重定向URI。 。 对客户端端点的重定向请求通常会导致 一个HTML文档响应，由用户代理处理。如果HTML 响应直接作为重定向请求的结果提供， 包含在HTML文档中的任何脚本都将完整地执行 访问重定向URI及其包含的凭证。 客户端不应该包含任何第三方脚本（例如， 第三方分析，社交插件，广告网络） 端点响应。相反，它应该从中提取证书 该URI并将用户代理重新定向到另一个没有的端点 公开凭证（在URI或其他地方）。如果是第三方 包含脚本，客户端必须确保自己的脚本 （用于从URI中提取和删除证书）将会 先执行。 。 令牌端点由客户端用来获取访问令牌 呈现其授权许可或刷新令牌。令牌 端点与每个授权许可一起使用，除了 隐式授权类型（因为访问令牌直接发布）。客户端通过其获取令牌位置的方式 终点不在本规范的范围内，而是位置 通常在服务文档中提供。 端点URI可以包含“application / x-www-form-urlencoded” 格式化（按附录B）查询组件（[RFC3986]第3.4节）， 当添加额外的查询参数时必须保留这些参数。该 端点URI不能包含片段组件。 由于对令牌端点的请求导致传输 明文凭证（在HTTP请求和响应中）， 授权服务器必须按要求使用TLS 向令牌端点发送请求时的第1.6节。 客户端在创建访问令牌时必须使用HTTP“POST”方法 要求。 不带值的发送参数必须被视为是 从请求中省略。授权服务器必须忽略 无法识别的请求参数。请求和响应参数 不得多于一次。 。 机密客户端或其他客户端必须发布客户端凭证 如授权服务器所述进行验证 在向令牌端点发出请求时的第2.3节。客户 身份验证用于： o强制刷新令牌和授权代码绑定到 他们发给的客户。客户端身份验证很关键 当授权码被发送到重定向时 端点通过不安全的通道或重定向URI时 未完全注册。 o通过禁用客户端或服务器从受损客户端恢复 更改凭据，从而防止攻击者滥用 被盗的刷新令牌。更改一组客户端 凭证要比撤销整套凭证要快得多 刷新令牌。 o实施认证管理最佳实践， 需要定期凭证轮换。旋转整个集合 的刷新令牌可能具有挑战性，而旋转一个单一的 客户端凭据集非常容易。客户端可以使用“client_id”请求参数来标识自己 向令牌端点发送请求时。在里面 对授权端点的“authorization_code”“grant_type”请求， 未经身份验证的客户端必须发送其“client_id”以防止其本身 从无意中接受用于客户端的代码 不同的“client_id”。这可以保护客户免受替代 认证码。（它不提供额外的安全性 受保护的资源。） 。 授权和令牌端点允许客户端指定 访问请求的范围使用“范围”请求参数。在 转，授权服务器使用“范围”响应参数 通知客户端发出的访问令牌的范围。 scope参数的值表示为空间 - 分隔的，区分大小写的字符串。字符串由 授权服务器。如果该值包含多个由空格分隔的值 字符串，它们的顺序无关紧要，每个字符串都会添加一个 请求范围的额外访问范围。 scope = scope-token *（SP scope-token） scope-token = 1 *（％x21 /％x23-5B /％x5D-7E） 授权服务器可以完全或部分地忽略范围 由客户端根据授权服务器策略或 资源所有者的指示。如果发出访问令牌的范围 与客户请求的授权不同 服务器必须包含“范围”响应参数来通知 授予实际范围的客户。 如果客户请求时忽略范围参数 授权，授权服务器必须或者处理 请求使用预定义的默认值或请求失败 表明无效范围。授权服务器应该 记录其范围要求和默认值（如果已定义）。 。 要请求访问令牌，客户端会从中获得授权 资源所有者。授权以表格形式表示 授权许可，客户用来请求访问 令牌。OAuth定义了四种授权类型：授权代码，隐式， 资源所有者密码凭证和客户端凭证。它也是 提供了一个定义附加授权类型的扩展机制。授权码授权类型用于获取两个访问权限 令牌和刷新令牌，并针对机密客户进行了优化。 由于这是一个基于重定向的流程，因此客户端必须有能力 与资源所有者的用户代理（通常是web）进行交互 浏览器）并且能够接收传入请求（通过重定向） 来自授权服务器。 + ---------- + | 资源| | 所有者| | | + ---------- + ^ | （B） + ---- | ----- +客户端标识符+ --------------- + | - + ----（A） - ＆重定向URI ----> | | | User- | | 授权| | 代理 - + ----（B） - 用户认证---> | 服务器| | | | | | - + ----（C） - 授权码--- <| | + - | ---- | --- + + --------------- + | | ^ v （A）（C）| | | | | | ^ v | | + --------- + | | | |> ---（D） - 授权码---------'| | 客户端| ＆重定向URI | | | | | | <---（E）-----访问令牌-------------------' + --------- +（w /可选刷新令牌） 注：说明步骤（A），（B）和（C）的线条被分解为 两部分通过用户代理。 图3：授权码流程图3所示的流程包括以下步骤： （A）客户通过指导资源所有者来启动流程 用户代理到授权端点。客户包括 其客户端标识符，请求范围，本地状态和a 重定向URI，授权服务器将发送该URI 一旦访问被授予（或拒绝），用户代理回来。 （B）授权服务器认证资源所有者（通过 用户代理）并建立资源所有者 授予或拒绝客户的访问请求。 （C）假设资源所有者授予访问权限，授权 服务器将用户代理重定向回客户端使用 重定向URI先前提供（在请求中或在 客户注册）。重定向URI包含一个 授权码和客户提供的任何本地状态 早。 （D）客户端从授权中请求访问令牌 服务器的令牌端点包含授权码 在上一步中收到。在提出请求时， 客户端与授权服务器进行身份验证。客户端 包括用于获取授权的重定向URI 代码验证。 （E）授权服务器认证客户端，验证 授权码，并确保重定向URI 收到的匹配用于重定向客户端的URI 步骤（C）。如果有效，授权服务器回应 访问令牌和可选的刷新令牌。 。 客户端通过添加以下内容来构造请求URI 参数传递给授权端点URI的查询组件 使用“application / x-www-form-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 主机：server.example.com 授权服务器验证请求以确保全部 所需参数存在且有效。如果请求有效， 授权服务器认证资源所有者并获得 授权决定（通过询问资源所有者或通过 通过其他方式建立批准）。 当决定建立时，授权服务器指示 用户代理使用HTTP提供的客户端重定向URI 重定向响应，或通过其他可用的方式 用户代理。 。 如果资源所有者授予访问请求，授权 服务器发出一个授权码，并通过它传递给客户端 将以下参数添加到。的查询组件 使用“application / x-www-form-urlencoded”格式的重定向URI， 根据附录B： 码 需要。由生成的授权码 授权服务器。授权码必须过期 发布后不久，以减少泄漏的风险。一个 最长授权码的使用寿命为10分钟 推荐的。客户端不得使用授权码不止一次。如果使用授权码超过 一旦授权服务器必须拒绝该请求并应该 撤销（如果可能）基于以前发布的所有令牌 该授权码。授权码绑定到 客户端标识符和重定向URI。 州 如果客户端中存在“状态”参数，则需要 授权请求。收到的确切价值 客户。 例如，授权服务器通过重定向用户代理 发送以下HTTP响应： HTTP / 1.1 302找到 位置：https：//client.example.com/cb？code = SplxlOBeZQQYbYS6WxSbIA ＆状态= XYZ 客户端必须忽略无法识别的响应参数。该 授权码字符串大小由此未定义 规范。客户应该避免对代码做出假设 值大小。授权服务器应该记录文件的大小 它发布的任何价值。 。 如果请求由于缺失，无效或不匹配而失败 重定向URI，或者如果客户端标识符丢失或无效， 授权服务器应该通知资源所有者 错误，并且不能自动将用户代理重定向到 无效的重定向URI。 如果资源所有者拒绝访问请求或请求 除了丢失或无效的重定向URI以外的原因失败， 授权服务器通过添加以下内容来通知客户端 使用参数到重定向URI的查询组件 “application / x-www-form-urlencoded”格式，根据附录B： 错误 需要。单个ASCII码[ USASCII ]错误代码 以下： 无效的请求 该请求缺少必需的参数，包括一个 无效的参数值，包含多个参数 一次或以其他方式变形unauthorized_client 客户无权请求授权 代码使用这种方法。 拒绝访问 资源所有者或授权服务器拒绝 请求。 unsupported_response_type 授权服务器不支持获取 使用此方法的授权码。 invalid_scope 请求的范围无效，未知或格式错误。 服务器错误 授权服务器遇到意外情况 条件阻止它履行请求。 （由于500内部服务器，需要此错误代码 错误HTTP状态码无法返回给客户端 通过HTTP重定向。） 暂时不可用 授权服务器当前无法处理 该请求由于临时超载或维护而发生 的服务器。（这个错误代码是需要的，因为503 服务不可用HTTP状态码无法返回 通过HTTP重定向到客户端。） “error”参数的值不能包含字符 超出设定值％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.1 302找到 位置：https://client.example.com/cb?error=access_denied&state=xyz 。 客户端通过发送请求给令牌端点 以下参数使用“application / x-www-form-urlencoded” 格式，每个附录B在HTTP中使用UTF-8字符编码 请求实体主体： grant_type 需要。值必须设置为“authorization_code”。 码 需要。从收到的授权码 授权服务器。 REDIRECT_URI 要求，如果“redirect_uri”参数包含在 如第4.1.1节所述的授权请求，以及它们的 值必须相同。 CLIENT_ID 要求，如果客户端没有通过身份验证 授权服务器，如第3.2.1节所述。 如果客户端类型是保密的或者客户端是客户端 凭证（或分配其他认证要求）， 客户端必须按照描述向授权服务器进行认证 在3.2.1节中。例如，客户端使用TLS发出以下HTTP请求 （仅用于显示目的额外换行符）： POST /令牌HTTP / 1.1 主机：server.example.com 授权：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW 内容类型：application / x-www-form-urlencoded grant_type = authorization_code＆代码= SplxlOBeZQQYbYS6WxSbIA ＆REDIRECT_URI = HTTPS％3A％2F％2Fclient％2Eexample％2Ecom％2Fcb 授权服务器必须： o要求机密客户或任何客户进行客户认证 客户端颁发了客户端证书（或与其他客户端 认证要求）， o如果包含客户端认证，则认证客户端， o确保授权代码已颁发给经过身份验证的代码 保密的客户，或者如果客户是公开的，确保 代码被发送到请求中的“client_id” o验证授权码是否有效，并且 o确保“redirect_uri”参数存在 “redirect_uri”参数包含在初始授权中 请求，如4.1.1节所述，并且如果包含的话确保 它们的值是相同的。 如果访问令牌请求是有效和授权的， 授权服务器发出访问令牌和可选刷新 令牌，如5.1节所述。如果请求客户端 认证失败或无效，授权服务器返回 如第5.2节所述的错误响应。一个成功的例子： HTTP / 1.1 200 OK Content-Type：application / json; charset = UTF-8 缓存控制：无存储 Pragma：无缓存 { “ACCESS_TOKEN”： “2YotnFZFEjr1zCsicMWpAA” “token_type”： “例如”， “expires_in”：3600， “refresh_token”： “tGzv3JOkF0XG5Qx2TlKWIA” “example_parameter”： “example_value” } 隐式授权类型用于获取访问令牌（它不会 支持刷新令牌的发行）并且为公众优化 已知可以操作特定重定向URI的客户端。这些客户 通常使用脚本语言在浏览器中实现 如JavaScript。 由于这是一个基于重定向的流程，因此客户端必须有能力 与资源所有者的用户代理（通常是web）进行交互 浏览器）并且能够接收传入请求（通过重定向） 来自授权服务器。 不同于客户制作的授权代码授权类型 单独的授权请求和访问令牌 客户端根据授权接收访问令牌 请求。 隐式授权类型不包括客户端认证，并且 依赖资源所有者的存在和注册 重定向URI。因为访问令牌被编码为 重定向URI，它可能会暴露给资源所有者和其他人 应用程序驻留在同一设备上。+ ---------- + | 资源| | 所有者| | | + ---------- + ^ | （B） + ---- | ----- +客户端标识符+ --------------- + | - + ----（A） - ＆重定向URI ---> | | | User- | | 授权| | 代理 - | ----（B） - 用户认证 - > | 服务器| | | | | | | <---（C）---重定向URI ---- <| | | | 使用Access Token + --------------- + | | 在片段 | | + --------------- + | | ----（D）---重定向URI ----> | 网络托管| | | 没有片段| 客户端| | | | 资源| | （F）| <---（E）-------脚本--------- <| | | | + --------------- + + - | -------- + | | （A）（G）访问令牌 | | ^ v + --------- + | | | 客户端| | | + --------- + 注：说明步骤（A）和（B）的线条被分成两部分 部分，因为他们通过用户代理。 图4：隐式授权流程图4中所示的流程包括以下步骤： （A）客户通过指导资源所有者来启动流程 用户代理到授权端点。客户包括 其客户端标识符，请求范围，本地状态和a 重定向URI，授权服务器将发送该URI 一旦访问被授予（或拒绝），用户代理回来。 （B）授权服务器认证资源所有者（通过 用户代理）并建立资源所有者 授予或拒绝客户的访问请求。 （C）假设资源所有者授予访问权限，授权 服务器将用户代理重定向回客户端使用 之前提供的重定向URI。重定向URI包括 URI片段中的访问令牌。 （D）用户代理通过制作a来遵循重定向指示 请求到网络托管的客户端资源（不 包括每个[ RFC2616 ] 的片段）。用户代理保留 片段信息在本地。 （五）网络托管的客户端资源返回一个网页（通常是 带有嵌入脚本的HTML文档）能够访问 完整的重定向URI，包括由。保留的片段 用户代理，并提取访问令牌（和其他 参数）包含在片段中。 （F）用户代理执行由网站托管的脚本 本地客户端资源，它提取访问令牌。 （G）用户代理将访问令牌传递给客户端。 有关使用隐式授权的背景，请参见第1.3.2和第9节。出于重要的安全考虑， 请参阅第10.3和10.16节 当使用隐式授权时。 。 客户端通过添加以下内容来构造请求URI 参数传递给授权端点URI的查询组件 使用“application / x-www-form-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 主机：server.example.com 授权服务器验证请求以确保全部 所需参数存在且有效。授权服务器 必须验证它将重定向到的重定向URI 访问令牌与由客户端注册的重定向URI相匹配 如3.1.2节所述。 如果请求有效，授权服务器将认证该请求 资源所有者并获得授权决定（通过询问 资源所有者或通过其他方式建立批准）。 当决定建立时，授权服务器指示 用户代理使用HTTP提供的客户端重定向URI 重定向响应，或通过其他可用的方式 用户代理。如果资源所有者授予访问请求，授权 服务器发出访问令牌并通过添加将其传递给客户端 以下参数用于重定向的片段组件 使用“application / x-www-form-urlencoded”格式的URI 附录B： 的access_token 需要。访问令牌由授权服务器发出。 token_type 需要。按照中所述发放令牌的类型 第7.1节。值不区分大小写。 过期日期在 推荐的。访问令牌的生存时间（秒）。对于 例如，值“3600”表示访问令牌将会 从响应生成的一小时内到期。 如果省略，授权服务器应该提供 通过其他方式的到期时间或记录默认值。 范围 可选，如果与客户要求的范围相同; 否则，需要。访问令牌的范围为 由第3.3节描述。 州 如果客户端中存在“状态”参数，则需要 授权请求。收到的确切价值 客户。 授权服务器不得发布刷新令牌。 例如，授权服务器通过重定向用户代理 发送以下HTTP响应（带有额外的换行符） 仅用于显示目的）： HTTP / 1.1 302找到 地点：http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA ＆状态= XYZ＆token_type =示例＆expires_in = 3600 开发人员应该注意到一些用户代理不支持 在HTTP“位置”响应中包含碎片组件 标题字段。这些客户需要使用其他方法 重定向客户端比3xx重定向响应 - for 例如，返回包含“继续”按钮的HTML页面 通过链接到重定向URI的操作。客户端必须忽略无法识别的响应参数。访问 标记字符串的大小在本规范中未定义。该 客户应该避免对价值规模做出假设。该 授权服务器应该记录它发布的任何值的大小。 如果请求由于缺失，无效或不匹配而失败 重定向URI，或者如果客户端标识符丢失或无效， 授权服务器应该通知资源所有者 错误，并且不能自动将用户代理重定向到 无效的重定向URI。 如果资源所有者拒绝访问请求或请求 除了丢失或无效的重定向URI以外的原因失败， 授权服务器通过添加以下内容来通知客户端 使用参数指向重定向URI的片段组件 “application / x-www-form-urlencoded”格式，根据附录B： 错误 需要。单个ASCII码[ USASCII ]错误代码 以下： 无效的请求 该请求缺少必需的参数，包括一个 无效的参数值，包含多个参数 一次或以其他方式变形。 unauthorized_client 客户端无权请求访问令牌 使用这种方法。 拒绝访问 资源所有者或授权服务器拒绝 请求。 unsupported_response_type 授权服务器不支持获取 使用此方法访问令牌。 invalid_scope 请求的范围无效，未知或格式错误。服务器错误 授权服务器遇到意外情况 条件阻止它履行请求。 （由于500内部服务器，需要此错误代码 错误HTTP状态码无法返回给客户端 通过HTTP重定向。） 暂时不可用 授权服务器当前无法处理 该请求由于临时超载或维护而发生 的服务器。（这个错误代码是需要的，因为503 服务不可用HTTP状态码无法返回 通过HTTP重定向到客户端。） “error”参数的值不能包含字符 超出设定值％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.1 302找到 位置：https：//client.example.com/cb#error=access_denied&state=xyz 资源所有者密码凭据授权类型适用于 资源所有者与信任关系的情况 客户端，例如设备操作系统或高度特权的客户端应用。授权服务器应特别小心 启用此授权类型并仅在其他流程不允许时才允许 可行的。 这种授予类型适用于能够获得该授权的客户 资源所有者的凭据（用户名和密码，通常使用 一个交互式表单）。它也用于迁移现有的客户端 使用直接认证方案，如HTTP Basic或Digest 通过将存储的凭证转换为OAuth来验证OAuth 访问令牌。 + ---------- + | 资源| | 所有者| | | + ---------- + v | 资源所有者 （A）密码凭证 | v + --------- + + --------------- + | |> - （B）----资源所有者-------> | | | | 密码凭证| 授权| | 客户端| | 服务器| | | < - （C）----访问令牌--------- <| | | | （w /可选刷新令牌）| | + --------- + + --------------- + 图5：资源所有者密码凭证流程 图5中所示的流程包括以下步骤： （A）资源所有者向客户提供其用户名和密码 密码。 （B）客户端从授权中请求访问令牌 服务器的令牌端点通过包括收到的凭证 来自资源所有者。当提出请求时，客户端 与授权服务器进行身份验证。 （C）授权服务器认证客户端并验证 资源所有者凭据，如果有效，则发出访问 令牌。客户端获取资源所有者的方法 凭证超出了本规范的范围。客户端 必须在获得访问令牌后丢弃凭证。 客户端通过添加该请求来向令牌端点发出请求 以下参数使用“application / x-www-form-urlencoded” 格式，每个附录B在HTTP中使用UTF-8字符编码 请求实体主体： grant_type 需要。值必须设置为“密码”。 用户名 需要。资源所有者用户名。 密码 需要。资源所有者密码。 范围 可选的。访问请求的范围如所描述 第3.3节。 如果客户端类型是保密的或者客户端是客户端 凭证（或分配其他认证要求）， 客户端必须按照描述向授权服务器进行认证 在3.2.1节中。 例如，客户端使用以下HTTP请求 传输层安全性（用于显示目的的额外换行符 只要）： POST /令牌HTTP / 1.1 主机：server.example.com 授权：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW 内容类型：application / x-www-form-urlencoded grant_type =密码＆用户名=输入johndoe＆密码= A3ddj3w授权服务器必须： o要求机密客户或任何客户进行客户认证 客户端颁发了客户端证书（或与其他客户端 认证要求）， o如果客户端认证包含在内，则认证客户端 o使用其验证资源所有者密码凭证 现有的密码验证算法。 由于此访问令牌请求使用资源所有者的请求 密码，授权服务器必须保护端点 蛮力攻击（例如，使用限速或生成 警报）。 如果访问令牌请求是有效和授权的， 授权服务器发出访问令牌和可选刷新 令牌，如5.1节所述。如果请求失败的客户端 认证或无效，授权服务器返回一个 错误响应如第5.2节所述。 一个成功的例子： HTTP / 1.1 200 OK Content-Type：application / json; charset = UTF-8 缓存控制：无存储 Pragma：无缓存 { “ACCESS_TOKEN”： “2YotnFZFEjr1zCsicMWpAA” “token_type”： “例如”， “expires_in”：3600， “refresh_token”： “tGzv3JOkF0XG5Qx2TlKWIA” “example_parameter”： “example_value” } 。 客户端可以仅使用其客户端请求访问令牌 凭证（或其他支持的认证方式） 客户端正在请求访问其下的受保护资源 控制，或其他资源所有者以前的控制权 与授权服务器一起安排（其方法超越 本规范的范围）。客户机证书授权类型只能用于保密 客户端。 + --------- + + --------------- + | | | | | |> - （A） - 客户端身份验证---> | 授权| | 客户端| | 服务器| | | < - （B）----访问令牌--------- <| | | | | | + --------- + + --------------- + 图6：客户端凭证流程 图6所示的流程包括以下步骤： （A）客户端与授权服务器进行身份验证 从令牌端点请求访问令牌。 （B）授权服务器认证客户端，如果有效， 发出访问令牌。 由于客户端认证被用作授权许可， 不需要额外的授权请求。 客户端通过添加该请求来向令牌端点发出请求 以下参数使用“application / x-www-form-urlencoded” 格式，每个附录B在HTTP中使用UTF-8字符编码 请求实体主体： grant_type 需要。值必须设置为“client_credentials”。 范围 可选的。访问请求的范围如所描述 第3.3节。 客户端必须与授权服务器进行身份验证 如3.2.1节所述。例如，客户端使用以下HTTP请求 传输层安全性（用于显示目的的额外换行符 只要）： POST /令牌HTTP / 1.1 主机：server.example.com 授权：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW 内容类型：application / x-www-form-urlencoded grant_type = client_credentials 授权服务器必须验证客户端。 如果访问令牌请求是有效和授权的， 授权服务器按照中所述发布访问令牌 第5.1节。刷新令牌不应包含在内。如果请求 失败的客户端身份验证或无效的授权服务器 返回第5.2节所述的错误响应。 一个成功的例子： HTTP / 1.1 200 OK Content-Type：application / json; charset = UTF-8 缓存控制：无存储 Pragma：无缓存 { “ACCESS_TOKEN”： “2YotnFZFEjr1zCsicMWpAA” “token_type”： “例如”， “expires_in”：3600， “example_parameter”： “example_value” } 。 客户端通过指定授予类型来使用扩展授权类型 使用绝对URI（由授权服务器定义）作为 令牌端点的“grant_type”参数的值，以及 添加必要的任何附加参数。例如，使用安全声明请求访问令牌 标记语言（SAML）2.0断言授权类型，如定义的 [ OAuth-SAML2 ]，客户端可以使用下面的HTTP请求 TLS（仅用于显示目的附加换行符）： POST /令牌HTTP / 1.1 主机：server.example.com 内容类型：application / x-www-form-urlencoded grant_type =瓮％3Aietf％3Aparams％3Aoauth％3Agrant型％3Asaml2- 承载＆断言= PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...为简洁起见省略...] aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 如果访问令牌请求是有效和授权的， 授权服务器发出访问令牌和可选刷新 令牌，如5.1节所述。如果请求失败的客户端 认证或无效，授权服务器返回一个 错误响应如第5.2节所述。 。 如果访问令牌请求是有效和授权的， 授权服务器发出访问令牌和可选刷新 令牌，如5.1节所述。如果请求失败的客户端 认证或无效，授权服务器返回一个 错误响应如第5.2节所述。 。 授权服务器发出访问令牌和可选的刷新 令牌，并通过添加以下参数来构建响应 到200（OK）状态码的HTTP响应的实体主体： 的access_token 需要。访问令牌由授权服务器发出。 token_type 需要。按照中所述发放令牌的类型 第7.1节。值不区分大小写。 过期日期在 推荐的。访问令牌的生存时间（秒）。对于 例如，值“3600”表示访问令牌将会 从响应生成的一小时内到期。 如果省略，授权服务器应该提供 通过其他方式的到期时间或记录默认值。refresh_token 可选的。刷新令牌，可用于获取新的 使用与描述相同的授权许可访问令牌 在第6节。 范围 可选，如果与客户要求的范围相同; 否则，需要。访问令牌的范围为 由第3.3节描述。 这些参数包含在HTTP响应的实体主体中 使用[ RFC4627 ] 定义的“application / json”媒体类型。该 参数被序列化为JavaScript对象表示法（JSON） 结构通过在最高结构级别添加每个参数。 JSON字符串包含参数名称和字符串值。 数字值包含为JSON数字。的顺序 参数无关紧要，可以改变。 授权服务器必须包含HTTP“Cache-Control” 响应头字段[ RFC2616 ]，其值为“no-store” 包含令牌，凭证或其他敏感信息的响应 信息以及“Pragma”响应标题字段[ RFC2616 ] 值为“no-cache”。 例如： HTTP / 1.1 200 OK Content-Type：application / json; charset = UTF-8 缓存控制：无存储 Pragma：无缓存 { “ACCESS_TOKEN”： “2YotnFZFEjr1zCsicMWpAA” “token_type”： “例如”， “expires_in”：3600， “refresh_token”： “tGzv3JOkF0XG5Qx2TlKWIA” “example_parameter”： “example_value” } 客户端必须忽略响应中无法识别的值名称。该 从授权接收的令牌和其他值的大小 服务器未定义。客户应该避免制作 关于价值规模的假设。授权服务器应该 记录它发布的任何价值的大小。授权服务器响应一个HTTP 400（错误请求） 状态码（除非另有规定）并包括以下内容 参数与响应： 错误 需要。单个ASCII码[ USASCII ]错误代码 以下： 无效的请求 该请求缺少必需的参数，包括一个 不受支持的参数值（授予类型除外）， 重复一个参数，包括多个凭证， 利用多种机制来认证 客户端，或以其他方式格式不正确。 invalid_client 客户端身份验证失败（例如，未知客户端， 包含客户端身份验证，或不受支持 身份验证方法）。授权服务器可以 返回一个HTTP 401（未授权）状态码来表示 哪些HTTP认证方案被支持。如果 客户端尝试通过“授权”进行身份验证 请求头字段，授权服务器必须 使用HTTP 401（未授权）状态码进行响应 包括“WWW-Authenticate”响应标题字段 匹配客户端使用的认证方案。 invalid_grant 提供的授权许可（例如，授权 代码，资源所有者凭据）或刷新令牌 无效，过期，已撤销，与重定向不匹配 授权请求中使用的URI，或发布给的URI 另一个客户。 unauthorized_client 经过身份验证的客户端无权使用此功能 授权许可类型。 unsupported_grant_type 该授权许可类型不受支持 授权服务器。invalid_scope 请求的范围无效，未知，格式不正确或 超出资源所有者授予的范围。 “error”参数的值不能包含字符 超出设定值％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响应的实体主体中 使用[ RFC4627 ] 定义的“application / json”媒体类型。该 通过添加每个参数将参数序列化为JSON结构 参数在最高结构级别。参数名称和字符串 值包含为JSON字符串。包括数值 作为JSON数字。参数的顺序并不重要，可以 变化。 例如： HTTP / 1.1 400错误请求 Content-Type：application / json; charset = UTF-8 缓存控制：无存储 Pragma：无缓存 { “错误”： “INVALID_REQUEST” }如果授权服务器向客户端发出刷新令牌，则 客户端通过添加一个对令牌端点进行刷新请求 以下参数使用“application / x-www-form-urlencoded” 格式 grant_type 需要。值必须设置为“refresh_token”。 refresh_token 需要。刷新令牌发布给客户端。 范围 可选的。访问请求的范围如所描述 第3.3节。请求的范围不得包含任何范围 最初不是由资源所有者授予的，如果省略的话 视为等同于最初授予的范围 资源所有者。 因为刷新令牌通常是持久的凭证 请求额外的访问令牌，刷新令牌绑定到 它发布的客户。如果客户类型是保密的或 客户端被颁发了客户端证书（或分配给他人） 认证要求），客户端必须通过认证 授权服务器，如第3.2.1节所述。 例如，客户端使用以下HTTP请求 传输层安全性（用于显示目的的额外换行符 只要）： POST /令牌HTTP / 1.1 主机：server.example.com 授权：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW 内容类型：application / x-www-form-urlencoded grant_type = refresh_token＆refresh_token = tGzv3JOkF0XG5Qx2TlKWIA授权服务器必须： o要求机密客户或任何客户进行客户认证 客户端颁发了客户端证书（或与其他客户端 认证要求）， o如果包含客户端认证，则认证客户端 确保刷新令牌已颁发给已认证的用户 客户端和 o验证刷新令牌。 如果有效且授权，则授权服务器发出访问 令牌，如5.1节所述。如果请求失败 验证或无效，授权服务器返回错误 如第5.2节所述。 在这种情况下，授权服务器可以发出新的刷新令牌 客户端必须丢弃旧的刷新令牌并用它替换它 新的刷新令牌。授权服务器可以撤销旧的 在向客户端发出新的刷新令牌后刷新令牌。如果一个 新的刷新令牌被发出，刷新令牌范围必须是 与客户端包含的刷新令牌相同 请求。 客户端通过呈现访问来访问受保护的资源 令牌给资源服务器。资源服务器必须验证 访问令牌并确保它没有过期并且它的范围 涵盖了所请求的资源。资源使用的方法 服务器验证访问令牌（以及任何错误响应） 超出了本规范的范围，但通常涉及到一个 资源服务器和服务器之间的交互或协调 授权服务器。 客户端使用访问令牌的方法 使用资源服务器进行身份验证取决于访问类型 令牌由授权服务器发出。通常情况下，它涉及 使用HTTP“Authorization”请求头域[ RFC2617 ]和 认证方案由访问规范定义 使用的令牌类型，如[ RFC6750 ]。访问令牌类型向客户端提供信息 要求成功使用访问令牌来进行保护 资源请求（以及类型特定的属性）。客户端 如果不了解令牌，则不能使用访问令牌 类型。 例如，使用[ RFC6750 ]中定义的“承载”令牌类型 只需在请求中包含访问令牌字符串即可： GET / resource / 1 HTTP / 1.1 主持人：example.com 授权：持票人mF_9.B5f-4.1JqM 而[ OAuth-HTTP-MAC ]中定义的“mac”令牌类型则被使用 一起发送消息认证码（MAC）密钥 访问令牌，用于签署HTTP的某些组件 要求： GET / resource / 1 HTTP / 1.1 主持人：example.com 授权：MAC id =“h480djs93hd8”， 随机数= “274312：dj83hs9s”， MAC = “kDZvddkndxvhGRXZhvuDjEWhGeE =” 上述例子仅用于说明目的。 建议开发者参考[ RFC6750 ]和[ OAuth-HTTP-MAC ] 使用前的规格。 每个访问令牌类型定义都指定了其他属性 （如果有）与“access_token”响应一起发送给客户端 参数。它还定义了用于的HTTP认证方法 在进行受保护的资源请求时包括访问令牌。 如果资源访问请求失败，资源服务器应该通知 错误的客户端。尽管这些错误反应的细节 超出了本规范的范围，本文件规定第11.4节中的 一个共同注册表，用于共享错误值 OAuth令牌认证方案。 新的身份验证方案主要针对OAuth令牌设计 认证应该定义一个提供错误的机制 状态码给客户端，其中允许的错误值是 注册在本规范建立的错误注册表中。这样的方案可以将有效的错误代码集合限制为一个子集 注册值。如果错误代码是使用named返回的 参数，参数名称应该是“错误”。 其他能够用于OAuth令牌认证的方案， 但不是主要为此目的设计的，可以约束他们的错误 值以相同的方式注册到注册表。 新的认证方案可以选择也指定使用 “error_description”和“error_uri”参数返回错误 信息的方式与它们在此的使用方式相平行 规范。 访问令牌类型可以通过以下两种方式之一进行定义：注册 访问令牌类型注册表（按照步骤中的步骤） 部分11.1），或者通过使用唯一的绝对URI作为它的名字。 使用URI名称的类型应该仅限于供应商特定的 不常用的实现，并且是特定的 资源服务器的实现细节在哪里 用过的。 所有其他类型必须注册。类型名称必须符合 键入名称ABNF。如果类型定义包含新的HTTP 认证方案，类型名称应该与HTTP相同 认证方案名称（由[ RFC2617 ]）。令牌类型 “示例”保留用于示例。 type-name = 1 * name-char name-char =“ - ”/“。” /“_”/ DIGIT / ALPHA 。 用于授权的新请求或响应参数 端点或令牌端点被定义并注册在 OAuth参数注册表遵循第11.2节中的过程。 参数名称必须符合参数名称ABNF和参数 值语法必须是明确定义的（例如，使用ABNF或引用 到现有参数的语法）。 param-name = 1 * name-char name-char =“ - ”/“。” /“_”/ DIGIT / ALPHA未注册的特定于供应商的参数扩展名不是 通常适用并且特定于实施 使用它们的授权服务器的详细信息应该 利用不太可能与供应商相关的前缀 其他注册值（例如，以'companyname_'开头）。 新的授权授权类型可以通过分配给他们定义 用于“grant_type”参数的唯一绝对URI。如果 扩展授权类型需要额外的令牌端点参数， 它们必须按照所述在OAuth参数注册表中进行注册 由第11.2节。 。 用于授权端点的新响应类型是 定义并注册在授权端点响应类型中 按照第11.3节中的程序进行注册。响应类型 名称必须符合响应型ABNF。 response-type = response-name *（SP响应名称） response-name = 1 * response-char response-char =“_”/ DIGIT / ALPHA 如果响应类型包含一个或多个空格字符（％x20），则该字符为空 被比较为空格分隔的值的列表，其中的顺序为 值并不重要。只有一个值的顺序可以被注册， 其中涵盖了同一组值的所有其他安排。 例如，响应类型“令牌代码”由此未定义 规范。但是，扩展可以定义和注册 “令牌代码”响应类型。一旦注册，相同的组合 不能注册为“代码令牌”，但两个值都可以用于 表示相同的响应类型。 在协议扩展（即访问令牌类型， 扩展参数或扩展授权类型）需要额外的 与授权码授权错误一起使用的错误代码 响应，隐式授予错误响应 ，令牌错误响应（或者 资源访问错误响应，这样的错误代码可能是 定义。扩展错误代码必须注册（按照中的步骤） 如果他们与之一起使用的扩展名是 注册的访问令牌类型，注册的端点参数或者 扩展授权类型。用于未注册的扩展的错误代码 可以注册。 错误代码必须符合错误ABNF并且应该以前缀 一个可能的识别名称。例如，错误标识 对扩展参数“example”设置的无效值应该是 命名为“example_invalid”。 错误= 1 *错误 - 字符 error-char =％x20-21 /％x23-5B /％x5D-7E 本机应用程序是在设备上安装并执行的客户端 由资源所有者使用（即桌面应用程序，本地移动 应用）。本机应用程序需要特殊考虑 与安全性，平台功能和总体最终用户有关 经验。 授权端点需要客户端之间的交互 和资源所有者的用户代理。本地应用程序可以调用 外部用户代理或在应用程序中嵌入用户代理。 例如： o外部用户代理 - 本机应用程序可以捕获 来自授权服务器的使用重定向URI的响应 用在操作系统上注册的方案来调用 客户端作为处理程序，手动复制并粘贴凭证， 运行本地Web服务器，安装用户代理扩展或 通过提供标识服务器托管的重定向URI 资源在客户的控制之下，这反过来又使得这些资源得以实现 对本地应用程序可用的响应。 o嵌入式用户代理 - 本地应用程序获取响应 通过直接与嵌入式用户代理进行通信 监视资源加载期间发出的状态变化，或者 访问用户代理的Cookie存储。 在外部或嵌入式用户代理之间进行选择时，开发人员 应该考虑以下几点： o外部用户代理可能会提高完成率，因为 资源所有者可能已经有一个活动会话 授权服务器，无需重新进行身份验证。它 提供了熟悉的最终用户体验和功能。该资源所有者也可能依赖用户代理功能或扩展 以协助认证（例如，密码管理器，双因素 设备读取器）。 o嵌入式用户代理可以提供改进的可用性，因为它被删除 需要切换上下文并打开新窗口。 o嵌入式用户代理由于资源而构成安全挑战 业主在没有通行证的不明身份的窗户中进行身份验证 到大多数外部用户代理中的视觉保护。一个 嵌入式用户代理教育最终用户信任不明身份 请求认证（使钓鱼攻击更容易 执行）。 在隐式授权类型和授权之间进行选择时 代码授予类型，应考虑以下内容： o使用授权代码授权类型的本机应用程序 由于本机的原因，应该不使用客户端凭据 应用程序无法保持客户端证书的机密性。 o使用隐式授权类型流时，刷新令牌不是 返回，这需要重复授权过程一次 访问令牌到期。 作为一种灵活且可扩展的框架，OAuth的安全性 考虑取决于许多因素。以下部分 为实施者提供关于这三者的安全准则：web应用程序， 基于用户代理的应用程序和本地应用程序。 授权服务器使用Web建立客户端凭证 应用程序客户端用于客户端身份验证。该 鼓励授权服务器考虑更强大的客户端 认证意味着不是客户端密码。Web应用程序客户 务必确保客户密码和其他客户的机密性 证书。
授权服务器不得发布客户密码或其他 客户端凭据本地应用程序或基于用户代理 应用程序客户端用于客户端身份验证。该 授权服务器可以发布客户端密码或其他凭证 用于特定安装a。上的本机应用程序客户端 特定设备。 当客户端身份验证不可行时，授权服务器 应该采用其他方式来验证客户的身份 - 因为 例如，通过要求注册客户端重定向URI 或征募资源所有者确认身份。一个有效的 重定向URI不足以验证客户端的身份 当请求资源所有者授权但可用于 防止在将证书交付给伪造的客户端之后 获取资源所有者授权。 授权服务器必须考虑安全影响 与未经认证的客户端进行交互并采取措施进行限制 其他凭证的潜在风险（例如刷新令牌） 发给这些客户。 恶意客户可以模拟另一个客户并获得访问权限 如果被冒充的客户端未能或者未能保护资源 无法保留其客户资料的机密。 每当授权服务器都必须认证客户端 可能。如果授权服务器无法认证客户端 由于客户端的本质，授权服务器必须要求 注册用于接收授权的任何重定向URI 响应和应该利用其他手段来保护资源所有者 来自这些潜在的恶意客户。例如， 授权服务器可以让资源所有者协助 确定客户及其来源。 授权服务器应该强制显式资源所有者 验证并向资源所有者提供有关的信息 客户端和请求的授权范围和生命周期。它是 直至资源所有者在上下文中检查信息 当前客户端并授权或拒绝请求。 授权服务器不应该处理重复授权 自动请求（没有活动的资源所有者交互） 无需认证客户或依靠其他措施 确保重复的请求来自原始客户端和 不是模仿者。访问令牌凭证（以及任何机密访问令牌 属性）必须在运输和存储过程中保密，并且 只在授权服务器，资源服务器之间共享 访问令牌对于以及访问令牌所在的客户端有效 发行。访问令牌凭证只能使用TLS传输 ，服务器认证由定义 [ RFC2818 ]。 当使用隐式授权类型时，传输访问令牌 在URI片段中，它可以将其暴露给未授权方。 授权服务器必须确保访问令牌不可以 生成，修改或猜测来生成有效的访问令牌 未授权方。 客户端应该以最小范围请求访问令牌 必要。授权服务器应该采用客户端身份 在选择如何兑现请求的范围和可能时考虑到 使用比请求更少的权限发布访问令牌。 本规范不提供任何资源的方法 服务器来确保给定的访问令牌提供给它 客户端由授权服务器发布给该客户端。 授权服务器可以向Web应用程序发放刷新令牌 客户和本机应用程序客户端 刷新令牌在运输和存储过程中必须保密，并且 只在授权服务器和客户端共享 刷新令牌被发布。授权服务器必须维护 刷新令牌和它所在的客户端之间的绑定 发行。刷新令牌只能使用TLS作为 ，服务器认证由定义 [ RFC2818 ]。 授权服务器必须验证刷新之间的绑定 令牌和客户端身份 认证。当客户认证不可能时， 授权服务器应该部署其他手段来检测刷新 令牌滥用。 例如，授权服务器可以使用刷新令牌 每次访问都会发出一个新的刷新令牌 令牌刷新响应。之前的刷新令牌无效但由授权服务器保留。如果刷新令牌是 妥协并随后被攻击者和攻击者使用 合法的客户端，其中一个会呈现无效刷新 令牌，它会通知授权服务器违规。 授权服务器必须确保刷新令牌不可以 生成，修改或猜测来生成有效的刷新标记 未授权方。 授权代码的传输应该通过安全的方式进行 频道，并且客户端应该要求使用TLS 如果URI标识网络资源，则重定向URI。以来 授权码通过用户代理重定向传输 可能会通过用户代理历史记录和HTTP进行披露 引荐标题。 授权码作为纯文本承载凭证运行，用于 验证资源所有者是谁授予了授权 授权服务器是相同的资源所有者返回的 客户端完成该过程。因此，如果客户依赖 其自己的资源所有者认证的授权码， 客户端重定向端点必须要求使用TLS。 授权码必须是短暂的和单次使用的。如果 授权服务器观察多次尝试交换一个 访问令牌的授权码，授权服务器 应该尝试撤销已根据授予的所有访问令牌 受损的授权码。 如果客户端可以被认证，授权服务器必须 验证客户端并确保授权码是 发给同一个客户。 使用授权码授权请求授权时 类型，客户端可以通过“redirect_uri”指定重定向URI， 参数。如果攻击者可以操纵该值 重定向URI，它可以导致授权服务器重定向 将资源所有者的用户代理转换为在其控制下的URI 攻击者使用授权码。 攻击者可以在合法客户端创建一个帐户并启动 授权流程。当攻击者的用户代理被发送到 授权服务器授予访问权限，攻击者抓获 授权URI由合法客户端提供并替换客户端的重定向URI与URI控制下的 攻击者。攻击者然后欺骗受害者追踪 操纵的链接授权访问合法的客户端。 一旦进入授权服务器，受害者就会被提示一个 正常，有效的请求代表合法和可信的客户端， 并授权请求。受害者然后被重定向到 在受到攻击者控制的端点上进行授权 码。攻击者通过发送完成授权流程 授权代码使用原始重定向URI给客户端 由客户提供。客户端交换授权码 使用访问令牌并将其链接到攻击者的客户端帐户， 现在它可以访问授权的受保护资源 受害者（通过客户端）。 为了防止这种攻击，授权服务器必须 确保用于获取授权码的重定向URI 与交换时提供的重定向URI相同 访问令牌的授权码。授权服务器 必须要求公共客户，并且应该要求保密的客户 注册他们的重定向URI。如果提供重定向URI 在请求中，授权服务器必须对其进行验证 注册价值。 资源所有者密码凭据授权类型通常用于 遗留或迁移原因。它降低了存储的整体风险 用户名和密码由客户，但并没有消除这种需要 向客户端公开高度特权的证书。 这种授权类型比其他授权类型具有更高的风险，因为 它维护该协议寻求避免的密码反模式。 客户可能会滥用密码，或密码可能 无意中被泄露给攻击者（例如，通过日志文件或 客户保存的其他记录）。 另外，因为资源所有者无法控制 授权过程（资源所有者的参与在什么时候结束 它将其凭据交给客户），客户可以获得 访问具有比资源所期望的范围更广的范围的令牌 所有者。授权服务器应考虑范围和 通过此授予类型发放的访问令牌的生存期。 授权服务器和客户端应该尽量减少对该授权的使用 尽可能地键入和使用其他授权类型。访问令牌，刷新令牌，资源所有者密码和客户端 凭证不得以明文传送。授权 代码不应以明文形式传输。 “状态”和“范围”参数不应包含敏感 客户端或资源所有者信息以纯文本格式显示，因为它们可能是 通过不安全的频道传输或不安全地存储。 为了防止中间人攻击，授权 服务器必须要求使用带有服务器认证的TLS 由[ RFC2818 ]对发送给授权的任何请求进行定义 令牌端点。客户端必须验证授权服务器 TLS证书由[ RFC6125 ] 定义并按照其规定 服务器身份验证的要求。 授权服务器必须防止攻击者猜测访问 令牌，授权码，刷新令牌，资源所有者 密码和客户端凭证。 攻击者猜测产生令牌的可能性（和其他 不打算由最终用户处理的证书）必须小于 或等于2 ^（ - 128）且应该小于或等于2 ^（ - 160）。 授权服务器必须利用其他手段来保护 用于最终用户使用的证书。 这种和类似协议的广泛部署可能会导致最终用户 变得习惯于被重定向到网站的做法 他们被要求输入他们的密码。如果最终用户不是 在进入之前请仔细核实这些网站的真实性 他们的凭据，攻击者可能会利用这一点 练习盗取资源所有者的密码。 服务提供商应该尝试教育最终用户有关风险 网络钓鱼攻击构成，并应提供简单的机制 为最终用户确认其网站的真实性。客户 开发人员应该考虑它们的安全含义 与用户代理（例如，外部的，嵌入的）交互，以及 最终用户的能力验证的真实性 授权服务器。为了降低钓鱼攻击的风险，授权服务器 必须要求在用于最终用户的每个端点上使用TLS 相互作用。 跨站请求伪造（CSRF）是攻击者的一种攻击手段 导致受害最终用户的用户代理跟随恶意URI （例如，作为误导性的链接，图像或者提供给用户代理 重定向）到信任服务器（通常通过 有效会话cookie的存在）。 针对客户端的重定向URI的CSRF攻击允许攻击者 注入自己的授权码或访问令牌，这可以 导致客户端使用与该关联的访问令牌 攻击者的受保护资源而不是受害者的（例如，保存 将受害者的银行账户信息传送给受保护的资源 由攻击者控制）。 客户端必须为其重定向URI实施CSRF保护。 这通常是通过要求发送给任何请求来完成的 重定向URI端点包含绑定请求的值 用户代理的认证状态（例如会话的散列 用于验证用户代理的cookie）。客户端应该 利用“状态”请求参数将此值传递给 授权服务器在进行授权请求时。 一旦从最终用户获得授权， 授权服务器将最终用户的用户代理重定向回 客户端具有包含在“状态”中的所需绑定值 参数。绑定值使客户端能够验证 通过匹配绑定值与请求的有效性 用户代理的身份验证状态。用于CSRF的绑定值 保护必须包含一个不可猜测的值，以及用户代理的认证状态（例如， 会话cookie，HTML5本地存储）必须保存在一个位置 只能由客户端和用户代理访问（即受到 同源政策）。 针对授权服务器授权的CSRF攻击 端点可能导致攻击者获得最终用户授权 针对恶意客户而不涉及或警告最终用户。 授权服务器必须为其实施CSRF保护 授权端点并确保恶意客户端不能 在没有意识和明确同意的情况下获得授权 资源所有者。在点击劫持攻击中，攻击者注册一个合法的客户端 然后构建一个恶意网站，在其中加载该网站 授权服务器的授权端点网页 透明的iframe覆盖在一组虚拟按钮的顶部， 精心构建，直接置于重要位置 授权页面上的按钮。当最终用户点击一个 误导可见按钮，最终用户实际上是点击一个 授权页面上的隐形按钮（例如“授权” 按钮）。这允许攻击者诱骗资源所有者进入 在没有最终用户的知识的情况下授予其客户端访问权限。 为了防止这种形式的攻击，本机应用程序应该使用 外部浏览器，而不是在浏览器中嵌入浏览器 应用程序在请求最终用户授权时。对于大多数更新 浏览器，可以通过授权来强制避免iframe 服务器使用（非标准）“x-frame-options”标题。这个 头可以有两个值，“拒绝”和“sameorigin”，这将阻止 任何取景，或由不同来源的网站构图， 分别。对于较老的浏览器，JavaScript框架破坏 技术可以使用，但可能不适用于所有浏览器。 代码注入攻击发生在输入或其他外部 变量被应用程序unsanitized使用并导致 修改应用程序逻辑。这可能允许攻击者 访问应用程序设备或其数据，导致拒绝 服务或引入各种各样的恶意副作用。 授权服务器和客户端必须清理（并在何时验证） 可能）收到的任何价值 - 特别是价值 “状态”和“redirect_uri”参数。 授权服务器，授权端点和客户端 重定向端点可能配置不正确，并且操作为打开 转向器。开放重定向器是使用参数to的端点 自动将用户代理重定向到由指定的位置 参数值没有任何验证。 开放重定向器可用于网络钓鱼攻击或攻击者 让最终用户通过使用URI权限访问恶意网站 一个熟悉且受信任的目的地组件。另外，如果 授权服务器允许客户端只注册部分 重定向URI，攻击者可以使用由其运行的开放重定向器客户端构造一个重定向的URI将通过 授权服务器验证，但会发送授权码 或者在攻击者的控制下将令牌存取到端点。 对于使用隐式流程的公共客户，本规范没有 为客户端提供任何方法来确定访问哪个客户端 令牌被发给。 资源所有者可能愿意通过委托来访问资源 授予访问令牌给攻击者的恶意客户端。这可能 是由于网络钓鱼或其他借口。攻击者也可能偷盗 通过一些其他机制的令牌。攻击者然后可能会尝试 通过向a提供访问令牌来模拟资源所有者 合法的公共客户。 在隐式流（response_type = token）中，攻击者可以很容易地 在授权服务器的响应中切换令牌， 用先前发放给该用户的令牌取代真正的访问令牌 攻击者。 服务器与依赖于的本地应用程序进行通信 在返回通道中传递访问令牌以标识用户 客户端可能会被攻击者创建一个类似的攻击 妥协的应用程序可以注入任意被盗的访问 令牌。 任何假定只有资源的公共客户 所有者可以为资源提供有效的访问令牌 容易受到这种类型的攻击。 这种类型的攻击可能会暴露有关资源所有者的信息 在攻击者的合法客户端（恶意客户端）。这个 也将允许攻击者在合法的地方执行操作 客户端的权限与最初的资源所有者相同 授予访问令牌或授权码。 为客户验证资源所有者不在此范围内 规范。任何使用授权过程的规范 作为委托给客户的最终用户认证的一种形式（例如， 第三方登录服务）禁止不使用隐式流 额外的安全机制，可以让客户 确定访问令牌是否为其使用而发布（例如，受众 - 限制访问令牌）。该规范建立了OAuth访问令牌类型注册表。 访问令牌类型使用规格要求进行注册 （[ RFC5226 ]）在一个为期两周的审查期后 oauth-ext-review@ietf.org邮件列表，根据一个或多个的建议 指定专家。但是，允许分配值 在公布之前，指定专家可以批准 一旦他们满意这样的规范将会注册 被出版。 注册请求必须发送到oauth-ext-review@ietf.org 邮件列表进行审查和评论，并附有适当的主题 （例如，“请求访问令牌类型：示例”）。 在审查期内，指定专家也可以 批准或拒绝注册请求，传达此决定 到审核名单和IANA。否认应包含解释 以及如果适用的话，关于如何提出请求的建议 成功的。 IANA只能接受来自指定专家的注册表更新， 并且应该将所有的注册请求指引到评论邮件 名单。 HTTP认证方案： HTTP身份验证方案名称（如果有）用于 使用访问令牌对受保护的资源请求进行身份验证 这个类型。 更改控制器： 对于标准跟踪RFC，请注明“IETF”。对于其他人，请给出名称 的责任方。其他细节（例如，邮政地址， 电子邮件地址，主页URI）也可以包括在内。规格文件： 参考指定参数的文档， 最好包括一个可以用来检索副本的URI 文件）。相关部分的说明也可以 被包括但不是必需的。 该规范建立了OAuth参数注册表。 包含在授权端点中的其他参数 请求，授权端点响应，令牌端点 请求或令牌端点响应是使用a注册的 规范要求（[ RFC5226 ]）在两周的审查期后 oauth-ext-review@ietf.org邮件列表，根据一个或多个人的建议 更多指定专家。但是，允许分配 在发布之前，指定专家可以批准 一旦他们满意这样的规范将会注册 被出版。 注册请求必须发送到oauth-ext-review@ietf.org 邮件列表进行审查和评论，并附有适当的主题 （例如，“请求参数：示例”）。 在审查期内，指定专家也可以 批准或拒绝注册请求，传达此决定 到审核名单和IANA。否认应包含解释 以及如果适用的话，关于如何提出请求的建议 成功的。 IANA只能接受来自指定专家的注册表更新， 并且应该将所有的注册请求指引到评论邮件 名单。 。 参数名称： 请求的名称（例如“示例”）。 参数使用位置： 可以使用参数的位置。可能的 位置是授权请求，授权响应，令牌 请求或令牌响应。 更改控制器： 对于标准跟踪RFC，请注明“IETF”。对于其他人，请给出名称 的责任方。其他细节（例如，邮政地址， 电子邮件地址，主页URI）也可以包括在内。规格文件： 参考指定参数的文档， 最好包括一个可以用来检索副本的URI 文件）。相关部分的说明也可以 被包括但不是必需的。 OAuth参数注册表的初始内容是： o参数名称：client_id o参数使用位置：授权请求，令牌请求 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：client_secret o参数使用位置：令牌请求 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：response_type o参数使用位置：授权请求 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：redirect_uri o参数使用位置：授权请求，令牌请求 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：范围 o参数使用位置：授权请求，授权 响应，令牌请求，令牌响应 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：状态 o参数使用位置：授权请求，授权 响应 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：代码 o参数使用位置：授权响应，令牌请求 o更改控制器：IETF o规范文件：RFC 6749o参数名称：error_description o参数使用位置：授权响应，令牌响应 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：error_uri o参数使用位置：授权响应，令牌响应 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：grant_type o参数使用位置：令牌请求 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：access_token o参数使用位置：授权响应，令牌响应 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：token_type o参数使用位置：授权响应，令牌响应 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：expires_in o参数使用位置：授权响应，令牌响应 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：用户名 o参数使用位置：令牌请求 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：密码 o参数使用位置：令牌请求 o更改控制器：IETF o规范文件：RFC 6749 o参数名称：refresh_token o参数使用位置：令牌请求，令牌响应 o更改控制器：IETF o规范文件：RFC 6749该规范建立了OAuth授权端点 响应类型注册表。 用于授权端点的其他响应类型是在两周后 注册了规范要求（[ RFC5226 ]） 审查期间在oauth-ext-review@ietf.org邮件列表上，在 一名或多名指定专家的建议。但是，允许的 在出版前分配价值，指定专家（S） 一旦他们满意这样的情况，可以批准注册 规范将被公布。 注册请求必须发送到oauth-ext-review@ietf.org 邮件列表进行审查和评论，并附有适当的主题 （例如，“请求响应类型：示例”）。 在审查期内，指定专家也可以 批准或拒绝注册请求，传达此决定 到审核名单和IANA。否认应包含解释 以及如果适用的话，关于如何提出请求的建议 成功的。 IANA只能接受来自指定专家的注册表更新， 并且应该将所有的注册请求指引到评论邮件 名单。 响应类型名称： 请求的名称（例如“示例”）。 更改控制器： 对于标准跟踪RFC，请注明“IETF”。对于其他人，请给出名称 的责任方。其他细节（例如，邮政地址， 电子邮件地址，主页URI）也可以包括在内。 规格文件： 参考指定类型的文档，最好 包括一个可用于检索副本的URI 文件（多个）。相关部分的说明也可能是 包括但不是必需的。OAuth授权端点响应类型注册表的初始 内容是： o响应类型名称：代码 o更改控制器：IETF o规范文件：RFC 6749 o响应类型名称：令牌 o更改控制器：IETF o规范文件：RFC 6749 该规范建立了OAuth扩展错误注册表。 与其他协议扩展一起使用的其他错误代码 （即，扩展授权类型，访问令牌类型或扩展 参数）以需要规格（[ RFC5226 ]）注册 在oauth-ext-review@ietf.org进行为期两周的审查期后 邮寄名单，根据一名或多名指定专家的建议。 但是，为了在发布前允许分配值， 指定专家可以一旦批准注册 满意这样的规范将被公布。 注册请求必须发送到oauth-ext-review@ietf.org 邮件列表进行审查和评论，并附有适当的主题 （例如，“请求错误代码：示例”）。 在审查期内，指定专家也可以 批准或拒绝注册请求，传达此决定 到审核名单和IANA。否认应包含解释 以及如果适用的话，关于如何提出请求的建议 成功的。 IANA只能接受来自指定专家的注册表更新， 并且应该将所有的注册请求指引到评论邮件 名单相关协议扩展： 扩展授权类型的名称，访问令牌类型或 与错误代码结合使用的扩展参数 用。 更改控制器： 对于标准跟踪RFC，请注明“IETF”。对于其他人，请给出名称 的责任方。其他细节（例如，邮政地址， 电子邮件地址，主页URI）也可以包括在内。 规格文件： 参考指定错误代码的文档， 最好包括一个可以用来检索副本的URI 文件）。相关部分的说明也可以 被包括但不是必需的。