开放_OAuth2.0_cn.doc

目 录OAuth的2.0授权协议11简介11.1角色21.2协议流31.3权限授予（AuthorizationGrant）41.3.1授权码51.3.2隐式51.3.3资源所有者密码凭据51.3.4ClientCredentials61.4访问令牌61.5刷新令牌622. ClientRegistration客户注册82.1客户端类型82.2客户端标识符92.3客户端身份验证102.3.1客户端的密码102.3.2其他身份验证方法112.4未注册的客户端123协议的端点123.1授权端点123.1.1响应类型133.1.2重定向向端点133.2令牌端点153.2.1客户端身份验证153.3Access Token Scope164Obtaining Authorization164.1授权码164.1.1授权申请174.1.2授权应答194.1.3访问令牌请求214.1.4访问令牌应答224.2隐式授权234.2.1授权请求254.2.2访问令牌应答264.3资源所有者密码凭据284.3.1授权请求和应答294.3.2访问令牌请求294.3.3访问令牌应答314.4客户端凭证324.4.1授权请求和应答324.4.2访问令牌请求324.4.3访问令牌响应334.5扩展345分发访问令牌355.1成功的响应355.2错误响应366刷新访问令牌387访问受保护资源407.1访问令牌类型408可扩展性418.1定义访问令牌类型418.2定义新端点参数418.3定义新的权限授予类型428.4定义新的授权端点响应类型428.5定义额外的错误码429本地应用4310安全注意事项4410.1客户端认证4410.2客户端模拟4510.3访问令牌4510.4刷新令牌4510.5授权码4610.6授权码重定向URI的操作4610.7资源所有者密码保密4710.8请求保密4710.9端点授权4710.10凭证猜测攻击4710.11钓鱼攻击4710.12夸站点请求伪造4810.13Clickjacking（跨浏览器攻击）4810.14代码注入和输入验证4911IANA事项4911.1OAuth访问令牌类型注册表4911.1.1注册模板4911.2The OAuth Parameters Registry5011.2.1注册模板5011.2.2初始登记册的类容5111.3OAuth授权端点响应类型注册表5411.3.1注册模板5511.3.2初始注册表内容5511.4OAuth扩展错误注册表5611.4.1注册模板5612CSRF(cross-site request forgery)5712.1示例和特性5712.2防范措施5712.3影响CSRF的因素5713共享session5813.1问题5813.1.1网站存在多个子域名的情况下如何共享session5813.1.2同一个主域名不同服务器之间如何共享session5813.2方案5813.2.1创建数据库表5813.2.2Session数据库操作58 OAuth的2.0授权协议草案-IETF-OAuth - V2 22摘要：OAuth的2.0授权协议允许第三方应用程序获取机会有限的HTTP服务，无论是以资源所有者的名义通过协调的批准资源所有者和HTTP服务互动，或通过允许第三方应用程序，以自己的名义获得的访问。1 简介在传统的客户端 - 服务器的身份验证模型中，客户端使用资源所有者服务器上凭据（credentials） 进行身份验证来申请访问受限资源（受保护的资源）。 为了提供第三方应用程序访问受限制的资源，资源的所有者分享其凭据给第三方。 这将产生几个问题和限制：a. 第三方的应用程序需要存储资源业主的凭据，以备将来使用，通常是一个明确的密码文本。b. 服务器都必须支持密码认证，尽管创建密码是安全薄弱环节。c. 第三方应用程序获得对资源所有者的受保护的资源过大的权限，让资源所有者没有能力限制周期或访问一个有限子集资源。d. 资源所有者不能在没有撤销所有的第三方访问的情况下，撤销个别第三方的访问，而且必须改变自己的密码来做这样的事。e. 折中的任何第三方的应用程序导致折中的最终用户的密码和所有的数据被该密码保护。OAuth 定位这些问题是通过引入授权层和从资源所有者那里分离客户端的角色。 在OAuth中，客户端请求访问被资源所有者控制和资源服务器托管的资源，并发出了跟资源所有者不同的凭据集合。客户端获得一个访问令牌，即一个一个字符串，表示一个具体范围，寿命和其他访问属性，而不是使用资源所有者的凭据来访问受保护资源。访问令牌被授权服务器批准资源的所有者颁发给第三方客户端。 客户端使用访问令牌访问资源服务器托管的受保护资源。例如，最终用户（资源所有者）可以授予一个打印服务（客户端）访问她的存储在共享服务（资源服务器）里受保护相片，而不共享与打印服务相关的用户名和密码。相反，她直接用照片共享服务（授权服务器）验证信任的服务器，这些照片共享服务产生打印服务的特定代表的凭据（访问令牌）。本规范是专为使用HTTP设计的。使用HTTP之外的其他任何传输协议的OAuth的是不确定的。1.1 角色OAuth的定义四个角色：resource owner资源的所有者：可以获得授权去访问受保护的资源的实体。这句很绕口，简单来说就是资源的所有者，这个所有者是指当初上传或生成的那个所有者，并不是指服务器的所有者。resource server资源服务器：承载受保护资源的服务器，可以接收和响应使用access token（访问令牌）请求受保护资源。cilent客户端：一个产生受保护资源请求的应用，该应用代表resource owner，并且已经获得其授权。所以其实客户就是指前面说道的这种特性的应用，是种application。authorization server授权服务器：在成功验证资源所有者和获得授权后，服务器发行访问令牌给客户端。授权服务器和资源服务器之间的相互作用超出本规范的范围。 授权服务器可能是同一台服务器作为资源的服务器或一个独立的实体。单一授权服务器发出访问令牌可能被多个资源服务器接受。1.2 协议流如图1所示的抽象流描述的四种角色之间的互动还包括了一下步骤:(A)client（就是application）向resource owner请求授权。可以直接向resource owner请求，但更好的是通过authorization server作为中间物间接获得。（比如新浪微博的是否允许授权的页面）(B)client获得了resource owner的授权认可（authorization grant），此授权认可是四种标准授权认可类型中的一种，也可以是其中一种的扩展类型。获得的授权认可的类型由client请求授权所使用的函数和authorization server支持的类型决定。（比如采用特定的请求授权的url，但是传入不同的参数，或者使用的method不同，当然一切都至少服务器要支持）(C)client提供授权认可，以请求一个access token，该token是可以被authorization server验证的。(D)authorization server验证client，并且核实授权认可，如果是有效，就发放access token。注意这里是两个验证，1验证client是不是被承认的，2验证resource owner是不是真的授权了。(E) clent提供access token给resource server验证，判断此client是否可以获取受保护的资源。(F) resource server核实access token，如果有效则响应请求1.3 权限授予（AuthorizationGrant）权限授予是一个凭证，代表着资源所有者的授权（访问它的受保护资源），它被客户端用来获得一个访问令牌。此规范定义了四种授予类型：的授权金是代表资源的凭据由所有者的授权（访问受保护的资源）客户端获得一个访问令牌。 此规范定义了四种授予类型：授权码，隐式，资源所有者密码凭据，客户端凭据，以及一个扩展定义其他类型的机制。1.3.1 授权码授权码是通过使用授权服务器作为客户端和资源所有者之间的中介被获取的。客户端请求授权指示资源所有者的授权服务器，这样服务器反过来又指导资源所有者将授权码返回客户端。而不是直接向资源的所有者申请授权。在引导资源所有者将授权码返回客户端之前，授权服务器验证资源的所有者并获得授权。由于资源的所有者只跟授权服务器认证，资源所有者的凭证不会与客户端分享。授权码提供了一些重要的安全优势如验证客户端的能力，和不通过资源所有者的用户代理而直接给客户端的访问令牌传输，可能暴露给他人，包括资源的所有者。1.3.2 隐式隐式授予是一个简化的授权码流，为了优化客户端实现在浏览器中使用例如JAVAScript的脚本语言。在隐流中，客户端直接发出一个访问令牌（作为资源的所有者授权的结果），而不是给客户端发出一个授权码。授予类型是隐式的就像没有中间的凭据（如授权码）被发出（后来被用来获得一个访问令牌）。 当发出一个隐含的授予，授权服务器不验证客户端。在某些情况下，可以通过用来给客户端提供的访问令牌的重定向URI，来验证客户端的身份。访问令牌可能会被暴露给资源的所有者或者其它要访问资源所有者的用户代理的应用程序。隐式授权提高了某些客户端的响应速度和效率（如实现在浏览器应用程序的客户端），因为它降低了获得所需的往返访问令牌的数量。然而，这种便利应权衡使用隐式授权的安全隐患，尤其是当授权码授予类型是可用的。1.3.3 资源所有者密码凭据资源所有者密码凭据（即用户名和密码）可直接作为一个权限授予获得访问令牌。凭证只有在资源所有者和客户端之间存在一个高等级的信任的时候使用（如设备的操作系统或一个高特权的应用程序），或者当其它权限授予类型不可用时（如授权码）凭据才被使用。尽管这种授权类型需要引导客户端访问资源所有者凭证，资源所有者凭证被用于一个单一的请求，并交换一个访问令牌。这种授予类型用持久的访问令牌或刷新令牌来交换凭据，这样可以消除客户端必须存储以供将来使用的资源所有者凭证的需要。1.3.4 ClientCredentials客户凭证（或其他形式的客户端身份验证）可被用作一个权限授予当授权范围被限制在保护资源在客户端控制下，或者 授权资源先前被安排给授权服务器。当客户端正以自己的名义行事（客户端也是资源所有者），或者客户端正在请求访问根据一个授权先前安排的授权服务器的受保护资源时，客户端凭证被典型被用来作为一种权限授予。1.4 访问令牌访问令牌是用于访问受保护的资源的凭据。 一个访问令牌是一个字符串，代表发送给客户端的授权。字符串通常是对客户端不透明的。令牌代表访问的具体范围和持续时间，由资源所有者授予，被资源的服务器和授权执行服务器强行执行。令牌可以表示用于检索授权信息的标识符，或用一种可核查的方式自我包含在授权信息中（即一个令牌字符串的一些数据组成和签名）。 超过了本规范范围的额外的身份验证凭据，可能为了客户端使用令牌而被需要。访问令牌提供了一个抽象层，用一个简单的被资源服务器理解的令牌来更换不同单一授权结构（如用户名和密码）。 这种抽象使发出的访问令牌比用来接收他们的权限授予更具有限制性，以及删除资源服务器的需要去了解一个广泛的验证方法。访问令牌可以有不同的格式，结构和基于资源服务安全性需求的方法利用率（如加密属性）。访问令牌的属性和用于访问受保护资源的方法超出了本规范和同伴规范定义的范围。1.5 刷新令牌刷新令牌是用来获取访问令牌的凭据。在当前的访问令牌变成无效或过期，或获得额外的访问令牌具有相同或更窄的范围（访问令牌可能有较短期少于资源授权的权限所有者）时，刷新令牌被授权服务器发送给客户端用于获取一个新的访问令牌。分发刷新标记是可选的。如果authorization server分发可刷新令牌，那么当分发access token的时候就会将可刷新令牌包括进去。刷新令牌是一个字符串，代表权限被资源所有者授予给客户端。字符串通常对客户端是透明的。令牌表示用于检索授权信息的标示符。与访问令牌不同的是，可刷新令牌只被用于授权服务器，而不会发送给资源服务器。发送给资源服务器的始终是访问令牌。下面看一个关于可刷新令牌的处理流程图。该流程图包括以下步骤：（A）客户端访问授权服务器进行验证，通过提供授权认可，以请求访问令牌。（B）授权服务器验证客户端并且验证授权认可（四种类型中的一种），如果有效则分发一个访问令牌和一个可刷新令牌（C）通过提供访问令牌，客户端可向资源服务器请求受保护资源。（D）资源服务器验证验证访问令牌，如果有效，就响应请求。（E）步骤（C）和（D）重复进行，直到访问令牌过期。如果client知道访问令牌过期，就直接跳到步骤（G），否则它还会请求受保护资源。（F）由于访问令牌失效，资源服务器返回无效令牌错误。（G）client请求一个新的访问令牌，通过向授权服务器提供可刷新令牌并进行验证。对client的验证条件是基于client的类型和authorization server的策略。（H）authorization server验证client和可刷新令牌，如果有效就分发一个新的访问令牌（你也可以再发送一个新的可刷新令牌）2 2. ClientRegistration客户注册发起协议之前，客户端注册授权服务器。在客户端注册透过何种途径与授服务器超出此范围规范，但通常涉及与最终用户互动HTML登记表。客户端注册不需要客户端和授权服务器之间的直接互动。当支持授权服务器时，注册可以依靠其他手段建立信任和获取所需的客户端属性（例如：重定向的URI，客户端类型）。例如，可以注册使用自发行或第三方发行的主张来实现，或授权服务器执行客户端发现使用信任的渠道。2.1 客户端类型OAuth的定义了两种客户端类型，在授权服务器下根据自己的能力验证安全性（即保持他们的客户端凭据的保密的能力）：保密性：客户能够保持其凭据机密性（如客户端一个安全的服务器与实施限制访问的客户端凭据），或使用其他手段保证客户端身份验证安全的能力。公开性：客户无法维持其保密凭据（如客户资源所有者的设备上执行如安装本地应用程序或基于Web浏览器应用程序），无法通过任何其他手段确保客户端身份验证安全。客户类型的制定是基于授权服务器安全认证的定义和它可接受的风险级别的客户端凭据。此规范已经围绕以下客户端设计配置文件：Web应用程序Web应用程序是一个网络服务器上运行的机密的客户端。资源所有者通过一个HTML用户界面呈现在资源所有者的设备上的用户代理来访问客户端。客户端凭据，以及任何分发给客户端的访问令牌被存储在Web服务器上，并没有暴露或由资源的所有者访问。用户代理为基础的应用用户代理为基础的应用是一个公共的客户端，客户端代码是从Web服务器下载，并在资源所有者的设备（如Web浏览器）上的用户代理执行。“协议”的相关数据和凭证能方便（而且往往可见）资源的所有者访问。 由于这些应用程序驻留在用户代理上，他们可以在请求权限时无缝使用用户代理能力。本机应用程序本机应用程序是在公共的客户端上安装和资源所有者的设备上执行的。“协议”的相关数据和凭据可被资源的所有者访问。据推测，任何包含在应用程序内的客户端身份验证凭据可以被提取。另一方面，动态分发的凭据，例如访问令牌或刷新令牌可以得到一个可接受的水平保护。在最低限度，隔离这些凭据与该应用程序可能交互的敌对服务器之外。在某些平台，这些凭据可能被保护，使之与驻留在同一设备上的其它应用程序隔离。2.2 客户端标识符授权服务器分发给登记客户端一个客户标识符一个唯一的字符串代表由客户提供的登记信息。客户端标识符是不是公开的秘密，它暴露给资源所有者，绝不能单独适用于客户端身份验证。2.3 客户端身份验证如果客户端类型是保密的，客户端和授权服务器建立适合授权服务器的安全需求的一个客户端验证方法。授权服务器可以接受任何形式的客户端认证，满足其安全要求。保密客户通常使用授权服务器发出（或建立）一套用于授权的客户凭证（如密码，公钥/私钥对）的客户端凭据。授权服务器不应该对客户端的类型做假设，或者接受没有与客户或者开发者建立信任所提供的类型信息。授权服务器可能用公共客户建立一个客户授权方法。但是，授权服务器决不能为了认证客户的目的而依靠公共客户端认证。客户端不得使用多个验证方法在每个请求。2.3.1 客户端的密码私有一个客户端密码的客户端可以使用HTTP基本验证计划。客户端标识符用作用户名，客户端的密码是用来作为密码。例如（额外的换行符仅用于显示目的）：授权：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW另外，授权服务器可能允许客户端凭证包括在请求体使用如下的参数：Client_id REQUIRED. 在登记过程中客户端标示符分发给客户端 Client-secret REQUIRED. 客户 secret。客户端可以省略参数如果客户secret是空字符串。客户端凭证包括在请求正文中使用两个客参数不被推荐，并应限于客户端无法直接利用HTTP基本身份验证计划（或其他基于密码的HTTP认证方案）。例如，请求刷新一个访问令牌（第6章）使用正文参数（额外的换行符仅用于显示目的）： POST /token HTTP/1.1 Host: Content-Type:application/x-www-form-urlencoded;charset=UTF-8grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw当将请求发送到令牌端点时，授权服务器必须要求使用传输层安全机制，这样请求使用此认证方法的导致明文凭据的传输。由于这个客户端的身份验证方法包括密码，授权服务器必须保护任何终端利用它对抗端点蛮力攻击。2.3.2 其他身份验证方法授权服务器可能支持任何合适的HTTP认证计划匹配其安全性要求。当用其他的身份验证方法，授权服务器必须在客户端标识符（登记备案）和身份验证方案之间定义一个映射。2.4 未注册的客户端本规范不排除使用未经注册的客户。但是，这样的客户使用超出此范围规范，并且需要额外的安全分析和审查其互操作性的影响。3 协议的端点授权过程中利用两个端点（HTTP资源）：授权端点-用于向通过用户代理重定向的资源所有者获取授权。令牌终点 -用来交换权限授予访问令牌，通常随着客户端身份验证。并非每个授权授予类型采用两个端点。如有需要，扩展授予类型可以定义额外的端点。3.1 授权端点授权端点用来与资源所有者交互,获得权限的授予。授权服务器必须首先验证资源的所有者的身份。方式授权服务器验证资源所有者（如用户名和密码登录，会话cookies）超出范围本规范。客户端透过何种途径获得授权端点的位置超出本规范的范围，但位置通常在服务文档里被提供。端点URI可能包括一个“application/x-www-form-urlencoded”格式化的查询组件，加入额外的查询参数时，必须保留。端点URI不能包含片段组件。由于请求授权端点导致用户身份验证和明文凭据（HTTP响应）的传输，授权服务器必须要求在授权端点发送请求时使用的传输层安全机制。授权服务器必须支持TLS 1.0,应该支持TLS 1.2和它的以后的版本，可以支持额外的传输层机制以满足它的安全性需要。授权服务器必须支持对授权断点的HTTP “GET” 方法的使用，也可以支持“POST”方法的使用。没有赋值的参数必须当做它们是从请求中被忽略的。授权服务器必须忽视无法识别的请求参数。请求和回应参数必须不能被包含超过一次。3.1.1 响应类型 是被授权码授权类型和隐式授权类型流使用的。客户端通知需要授权类型的授权端点使用以下参数。response_typeREQUIRED. 它的值必须是请求授权码中一个码就像4.1.1结所描述，令牌就如4.2.1结描述的请求一个访问令牌（隐式授予），或者一个如8.4结描述的注册扩展值。如果响应类型包括一个或者更多空格字符（%x20）, 它被解释为一个空格分隔列表值，值的顺序没有关系（例如“a b”跟“b a”是一样的） 如果一个授权响应丢失了“response_type”参数，授权服务器必须返回一个错误回复，就如结所述。3.1.2 重定向向端点与资源的所有者完成互动后，授权服务器指示资源所有者的用户代理返回客户端。授权服务器重定向用户代理到客户端的重定向终点，重定向终点是先前客户端注册进程或者发出授权请求时由授权服务器建立的。 重定向端点URI必须是一个绝对的URI，如4.3所述。终点 URI可能包含anapplication/x-www-form-urlencoded格式化查询组件，加入额外的查询参数时，必须保留。端点URI不能包含片段组件。 端点要求保密如果一个重定向请求将导致授权码的传输或者访问令牌通过一个开放网络（在资源所有者的用户代理和客户端之间），客户端应需要使用传输层安全机制。 传输层安全性的缺乏可能对客户端的安全和受保护资源授权访问造成严重影响。当客户端将授权过程当做一种委派最终用户身份验证时，传输层安全机制的使用变得尤为关键。 注册要求授权服务器应要求所有client用授权终端登记他们先前的重定向URI，并且必须要求以下的client登记他们的重定向URI：a) public clientsb) 安全的clients 使用隐式的授权类型授权服务器应要求客户端提供完整的重定向URI（客户端可以使用“state”的请求参数来实现每个请求定制）。授权服务器允许客户端注册多个重定向URI. 如果要求完成重定向的URI注册登记是不可能的，授权服务器应要求URI方案，权限和路径（请求授权时，许客户端动态改变注册重定向URI的查询组件）的注册。 动态配置如果已注册多个重定向的URI，如果只有部分重定向URI已被注册，或如果没有重定向URI已注册，客户端必须包括重定向URI，在授权请求时使用“redirect_uri”请求参数。 当一个重定向URI 被包含在授权请求中时，授权服务器必须比较和匹配最少一个接受到的已注册的重定向URI（或者URI组件）就如第6章定义的，如果任何重定向URI被注册了，授权服务器必须使用简单的字符串比较对比两个URI，就如6.2.1结所述。 如果授权服务器准许client动态的改变重定向URI的查询组件，client 必须确保操作查询组件时不被攻击者滥用重定向终点，就如10.15结所述。.1 无效端点如果授权请求验证失败是由于丢失，无效，或者重定向URI不匹配，授权服务器必须通知资源所有者错误信息，必须不能自动重定向用户代理到无效的重定向URI。授权服务器不应该重定向用户代理到未注册或者不信任的URI ，以防止授权终端被公开的重定向者利用。.2 端点内容到客户端点的重定向请求通常结果是一个HTML的文档响应，被用户代理所有。如果HTML响应被直接服务为重定向响应的结果，任何脚本包括HTML文档会带着全部重定向URI访问和它自带的凭证执行。Client 必须不能包含任何不受信任第三方脚本在重定向端点响应中（比如 第三方分析器，社区插件，网络服务），第三方脚本没有第一次保证 它自己被用来提取和删除在URI的凭证的脚本将首次执行。Client 不应该包含任何第三方脚本在重定向端点响应中。相反的，它应该从URI和重定向用户代理中提取凭证，并在没有凭证的URI里重定向用户代理到另外的端点。3.2 令牌端点令牌端点被client用来接受一个介绍他权限授予或者刷新令牌的访问令牌。令牌端点被每一个权限授予使用，除了隐式授予类型（应为访问令牌被直接分发）。客户端透过何种途径获得令牌的位置端点超出本规范的范围，但通常在服务文档里提供。没有赋值的参数必须当做它们是从请求中被忽略的。授权服务器必须忽视无法识别的请求参数。请求和回应参数必须不能被包含超过一次。3.2.1 客户端身份验证保密的客户，分发客户凭证的客户，或者交办其它授权请求的客户必须被授权服务器验证身份在产生对令牌端点的请求时，就如2.3所述。客户端身份验证被用来：(a) 执行客户端分发的刷新令牌和授权码到客户端的绑定。当一个授权码通过不安全的通道或者当重定向URI还没有被全部注册时，授权码传送到重定向端点的关键是客户端验证。(b) 通过禁用客户端或改变其凭据来从受影响的客户端恢复，从而防止攻击者滥用被盗刷新令牌。改变一个单一的客户端凭据集合显然比撤销整套刷新令牌的更快。(c) 实施认证管理的最佳做法，需要定期凭据轮换。整套刷新令牌的轮换可能是具有挑战性，而一个单一的客户端凭据的轮换显然比较容易。在给令牌端点传送请求时，一个没有被分发客户密码的公共客户可能使用“client_id”请求参数来认证它自己。准许公共客户到令牌端点的未认证访问的安全后果，如同到公共客户的不安全的刷新令牌必须被考虑。3.3 Access Token Scope身份认真和令牌端点准许客户使用“scope”请求参数指定访问请求的范围。反过来，授权服务器使用的“范围”的响应参数通知客户端发出的访问令牌的范围。范围参数值表示为空间分隔，大小写敏感的字符串列表。这个字符串被授权服务器定义。如果值包含过个空间分隔字符串，他们的顺序没关系，每个字符增加一个额外的访问边界给请求边界。授权服务器可能全部或者部分忽视客户端请求的边界，该客户请求时根据授权服务器政策或资源所有者的指。如果分发访问令牌边界与客户端请求的不同，授权服务器应该包括“scope”响应参数去通知客户端实际被授予的边界。4 Obtaining Authorization 4.1 授权码授权码授予类型被用来获得访问令牌和刷新令牌，还被用来优化机密性客户端。作为一个基于重定向的流，客户必须具有与资源所有者的用户代理（通常是是web 浏览器）交互的能力和接受来自授权服务器进入请求（通过重定向）的能力。上面的流程图包括了如下3个步骤：（a） 客户端开始流程，引导资源所有者的用户代理到授权端点。客户端包括其客户端标识符，请求的范围，本地状态和重定向URI，重定向URI是当访问被授权后授权服务器发送回的用户代理的。（b） 授权服务器认证资源所有者（通过用户代理）然后建立客户端的访问请求，不论资源所有者授权或者拒绝。（c） 假如资源所有者授权访问，授权服务器使用先前重定向URI（在请求时或者客户注册期间）将用户代理重定向回客户。重定向URI包括一个授权码和任何早起客户端提供的本地状态。（d） 客户从授权服务器的令牌端点请求一个访问令牌，包括在上一步中收到的授权码。在做出请求时，客户与授权服务器验证。包括重定向URI 的客户用于获得验证授权码。（e） 授权服务器验证客户端身份，验证授权码，保证接收到的重定向URI与步骤（c）中用于重定向客户端的URI向匹配。如果有效，授权服务器回复一个访问令牌和和可选择的刷新令牌。4.1.1 授权申请客户端通过增加下面参数到授权端点URI的查询组件构造请求URI，使用application/x-www-form-urlencoded格式来构造。Response_typeREQUIRED. 必须被赋值。Client_idREQUIRED. 客户身份，2.2结介绍Redirect_uriOPTIONAL , 3.1.2结介绍。ScopeOPTIONAL, 访问请求的范围，如3.3结描述。StateRECOMMENDED, 一个不透明的值，由客户端用来维持请求和回调状态。当重定向用户代理给客户端时，授权服务器包括此值。参数应当用于防止跨站点请求伪造，如10.12结所述。Client使用一个HTTP重定向回答，或者用其它通过用户代理的方法将资源所有者引导到构造好的URI.例如，客户端引导用户代理去做如下HTTP请求，使用传输层安全机制：GET/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2FcbHTTP/1.1Host: 授权服务器验证请求以确保所有必需的参数存在且有效。如果请求是有效的，授权服务器验证资源的所有者，并获得一个授权决定（通过要求资源所有者或通过其他手段建立审批）。当一个决定建立时，使用一个HTTP重定向回答，或者用其它通过用户代理的方法将资源所有者引导到构造好的URI.4.1.2 授权应答如果资源所有者授权给访问请求，授权服务器发布一个授权码然后传送它给客户端，授权码是增加下面的参数到重定向URI查询组件，使用application/x-www-form-urlencoded格式。CodeREQUIRED. 授权服务器产生授权码，授权码必须在分发后不久就到期，以减轻泄露的风险。推荐一个授权码最大的寿命是10分钟。Client必须不能使用授权码超过一次。日过一个授权码被使用超过一次，授权服务器必须拒绝请求，然后尝试撤销前面所有基于那个授权码分发的令牌。授权码是绑定到客户标示符和重定向URI。StateREQUIRED 如果“state“参数存在于客户端授权请求中。从客户端收到确切的值。比如，授权服务器通过发送下面的HTTP应答来重定向用户代理。HTTP/1.1 302 FoundLocation: /cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyzClient应该忽视不认识应答参数。授权码字符串的大小在本规范是未定义的。Client应该避免对码值的大小做假设。授权服务器应该将任何它发布值的大小归档。 错误应答如果由于丢失，失效，或者重定向URI不匹配而请求失败，或者如果所提供的客户端标示符是无效的，授权服务器应该通知资源服务器错误信息，一定不能自动的重定向用户代理到无效的重定向URI。如果资源所有者拒绝访问请求，或者如果请求失败是有别于丢失或者无效重定向URI的原因，授权服务器通过增加下面的参数到重定向URI参训组件，来通知client,使用application/x-www-form-urlencoded格式：errorREQUIRED 来自以下的简单错误码： invalid_request : 请求丢失了必要的参数，包括一个不被支持的参数值，或者格式不正确unauthorized_client : client 没有用这种方法被授权去请求授权码。access_denied ：资源所有者或者授权服务器拒绝请求。Unsupported_response_type ：资源服务器不支持用这种方法获得一个授权码。Invalid_scope ：请求范围无效，位置或者不符合格式。server_error : 授权服务器遇到意外情况无法履行请求。 Temporarily_unavailable: 授权服务器由于暂时过载或者服务器维护现在不能处理请求。error_description OPTIONAL. 一个提供更多信息的人类可读的UTF-8 编码文本，用于帮助客户端开发，使我们了解所发生的错误error_uri OPTIONAL 提供识别有关错误信息，供人参阅的网页URI。提供客户端开发和有关错误的其他信息state REQUIRED 如果一个有效的“state“参数存在于客户授权请求。从客户端接收到一个确切的值例如：授权服务器通过发送下面HTTP应带重定向用户代理：HTTP/1.1 302 FoundLocation: /cb?error=access_denied&state=xyz4.1.3 访问令牌请求Client发出通过在HTTP请求实体文本中增加下面参数来请求令牌端点，使用application/x-www-form-urlencoded格式。grand_type REQUIRED. “authorization_code”必须被赋值。code REQUIRED. 从授权服务器接受的授权码。redirect_uri REQUIRED. 如果“redirect_uri“参数被包含在授权请求中，如4.1.1所述，它的值必须相同。如果client 类型是秘密的或者client 被分发了client 凭证（或者假设另外授权求）， client 必须和授权服务器验证身份，如 3.2.1.节所述。 例如，client 按照传输层安全性做出如下HTTP 请求： POST /token HTTP/1.1 Host: Authorization: BasicczZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type:application/x-www-form-urlencoded;charset=UTF-8grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb授权服务器必须：（a）请求客户验证秘密客户或者每个被分发了凭证（或者其它授权需求）的用户（b）如果client 验证被包括就去验证客户端，然后确保授权码被分发给授权client（c）确认授权码是有效的（d）确保“redirect_uri”参数是存在的，如果“redirect_uri”参数被包括在初始的授权请求（4.1.1所述），如果被包含，确保他们的值是相同的。4.1.4 访问令牌应答如果访问令牌请求是有效的和授权的，授权服务器分发一个访问令牌和可选的刷新令牌（5.1所述）。如果请求客户端授权失败或者失效，授权服务器返回一个错误应答，如5.2所述一个成功应答的例子：HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cacheaccess_token:2YotnFZFEjr1zCsicMWpAA,token_type:example,expires_in:3600,refresh_token:tGzv3JOkF0XG5Qx2TlKWIA,example_parameter:example_value4.2 隐式授权隐式授权类型被用来获得访问令牌（它不支持刷新令牌的发行），隐式授权非常适合懂得操作特定重定向URI的公共客户端。这些客户端通常用一个例如JavaScript的脚本语言在浏览器中实现。作为一个基于重定向的流，client必须具有与资源所有者的用户代理（通常是一个web浏览器）交互的能力，还要具有从授权服务器接受向内请求（通过重定向）的能力。不像授权码授权类型，授权码授权类型中，客户端为了授权和访问令牌做出分隔的请求，但在隐式授权中，client接受访问令牌作为授权请求的结果。隐式授权类型不包括客户身份验证，它依赖于资源所有者和注册过的重定向URI的存在。因为访问令牌被编码到了重定向URI，它可能被曝光给资源所有者和驻留在磁盘的应用程序。上图包括了以下步骤：（A）client启动流程是从引导资源所有者的用户代理到授权端点开始的。Client包括他的客户端标示符，请求的范围，本地的状态和一个重定向RUI，一旦访问被授权（或者决绝）授权服务器将把用户代理送回。（B）授权服务器认证资源所有者（通过用户代理）。无论资源所有者授权或者拒绝，授权服务器建立客户端的访问请求。（C）假设资源所有者授权访问，授权服务器使用早起提供的重定向URI将用户代理重定向回client。重定向URI包含在访问令牌的URI片段里。（D）用户代理通过做出对web托管的客户端资源的请求，跟着重定向的指示。客户端保留本地的片段信息。（E）Web托管客户端资源返回一个web页面（通常是一个嵌入了脚本的HTML文档），能访问全重定向URI包括保留在用户代理的URI，提取片段中的访问令牌（和其它参数）（F）用户代理在本地执行web托管客户端资源的脚本，提取访问指令然后提交给client。4.2.1 授权请求Client通过增加下面的参数到授权端点URI的查询组件来构造请求URI，并使用application/x-www-form-urlencoded格式：Response_typeREQUIRED. “token“必须被赋值。Client_idREQUIRED. 客户端标示符，如2.2所述。Redirect_uriOPTIONAL, 如3.1.2所述。ScopeOPTIONAL, 访问请求的范围，3.3节所述。stateRECOMMENDED. 客户端的一个不透明的值用来保留请求和回叫的状态。授权服务器包括这个值当重定向用户代理回client时。参数应该被用于防止夸站点访问片段。如10.12所述。Client使用一个HTTP重定向应答来引导资源所有者到构造URI，或者通过其他方式提供给他的用户代理。例如,client引导用户代理使用传输层安全性去做出如下HTTP请求：GET/authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1Host: 授权服务器验证请求以确保所有的必须的参数是存在的且有效地。授权服务器必须验证重定向URI，这个URI回重定向访问令牌与一个客户端注册过的重定向URI匹配。如果请求有效，授权服务器认真资源所有者，获得一个授权决定（通过请求资源所有者或者通过其他方法建立审批）。当一个决定建立时，授权服务器定向用户代理到提供的客户重定向URI，这是通过一个HTTP重定向应答或者用其他方法提供给他的用户代理。4.2.2 访问令牌应答如果资源所有者授权一个访问请求，授权服务器分发一个访问令牌然后传送它给客户端，通过增加以下参数到重定向URI的片段组