开放OAuth20cnWord格式.docx

1、4.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

2、安全注意事项 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.13 Clickjacking（跨浏览器攻击） 4810.14 代码注入和输入验证 4911 IANA事项 4911.1 OAuth访问令牌类型注册表 4911.1.1 注册模板 4911.2 The OAuth Parameters Regi

3、stry 5011.2.1 注册模板 5011.2.2 初始登记册的类容 5111.3 OAuth授权端点响应类型注册表 5411.3.1 注册模板 5511.3.2 初始注册表内容 5511.4 OAuth扩展错误注册表 5611.4.1 注册模板 5612 CSRF（cross-site request forgery） 5712.1 示例和特性 5712.2 防范措施 5712.3 影响CSRF的因素 5713 共享session 5813.1 问题 5813.1.1 网站存在多个子域名的情况下如何共享session 5813.1.2 同一个主域名不同服务器之间如何共享session 5

4、813.2 方案 5813.2.1 创建数据库表 5813.2.2 Session数据库操作 58OAuth的2.0授权协议草案-IETF-OAuth - V2 22摘要：OAuth的2.0授权协议允许第三方应用程序获取机会有限的HTTP服务，无论是以资源所有者的名义通过协调的批准资源所有者和HTTP服务互动，或通过允许第三方应用程序，以自己的名义获得的访问。1 简介在传统的客户端 - 服务器的身份验证模型中，客户端使用资源所有者服务器上凭据（credentials） 进行身份验证来申请访问受限资源（受保护的资源）。 为了提供第三方应用程序访问受限制的资源，资源的所有者分享其凭据给第三方。 这

5、将产生几个问题和限制：a. 第三方的应用程序需要存储资源业主的凭据，以备将来使用，通常是一个明确的密码文本。b. 服务器都必须支持密码认证，尽管创建密码是安全薄弱环节。c. 第三方应用程序获得对资源所有者的受保护的资源过大的权限，让资源所有者没有能力限制周期或访问一个有限子集资源。d. 资源所有者不能在没有撤销所有的第三方访问的情况下，撤销个别第三方的访问，而且必须改变自己的密码来做这样的事。e. 折中的任何第三方的应用程序导致折中的最终用户的密码和所有的数据被该密码保护。OAuth 定位这些问题是通过引入授权层和从资源所有者那里分离客户端的角色。 在OAuth中，客户端请求访问被资源所有者控

6、制和资源服务器托管的资源，并发出了跟资源所有者不同的凭据集合。客户端获得一个访问令牌，即一个一个字符串，表示一个具体范围，寿命和其他访问属性，而不是使用资源所有者的凭据来访问受保护资源。访问令牌被授权服务器批准资源的所有者颁发给第三方客户端。 客户端使用访问令牌访问资源服务器托管的受保护资源。例如，最终用户（资源所有者）可以授予一个打印服务（客户端）访问她的存储在共享服务（资源服务器）里受保护相片，而不共享与打印服务相关的用户名和密码。相反，她直接用照片共享服务（授权服务器）验证信任的服务器，这些照片共享服务产生打印服务的特定代表的凭据（访问令牌）。本规范是专为使用HTTP设计的。使用HTTP

7、之外的其他任何传输协议的OAuth的是不确定的。1.1 角色OAuth的定义四个角色：resource owner资源的所有者：可以获得授权去访问受保护的资源的实体。这句很绕口，简单来说就是资源的所有者，这个所有者是指当初上传或生成的那个所有者，并不是指服务器的所有者。resource server资源服务器：承载受保护资源的服务器，可以接收和响应使用access token（访问令牌）请求受保护资源。cilent客户端：一个产生受保护资源请求的应用，该应用代表resource owner，并且已经获得其授权。所以其实客户就是指前面说道的这种特性的应用，是种application。author

8、ization server授权服务器：在成功验证资源所有者和获得授权后，服务器发行访问令牌给客户端。授权服务器和资源服务器之间的相互作用超出本规范的范围。 授权服务器可能是同一台服务器作为资源的服务器或一个独立的实体。单一授权服务器发出访问令牌可能被多个资源服务器接受。1.2 协议流如图1所示的抽象流描述的四种角色之间的互动还包括了一下步骤:（A）client（就是application）向resource owner请求授权。可以直接向resource owner请求，但更好的是通过authorization server作为中间物间接获得。（比如新浪微博的是否允许授权的页面）（B）cli

9、ent获得了resource owner的授权认可（authorization grant），此授权认可是四种标准授权认可类型中的一种，也可以是其中一种的扩展类型。获得的授权认可的类型由client请求授权所使用的函数和authorization server支持的类型决定。（比如采用特定的请求授权的url，但是传入不同的参数，或者使用的method不同，当然一切都至少服务器要支持）（C）client提供授权认可，以请求一个access token，该token是可以被authorization server验证的。（D）authorization server验证client，并且核实授权认

10、可，如果是有效，就发放access token。注意这里是两个验证，1验证client是不是被承认的，2验证resource owner是不是真的授权了。（E） clent提供access token给resource server验证，判断此client是否可以获取受保护的资源。（F） resource server核实access token，如果有效则响应请求1.3 权限授予（AuthorizationGrant）权限授予是一个凭证，代表着资源所有者的授权（访问它的受保护资源），它被客户端用来获得一个访问令牌。此规范定义了四种授予类型：的授权金是代表资源的凭据由所有者的授权（访问受保护的

11、资源）客户端获得一个访问令牌。 此规范定义了四种授予类型：授权码，隐式，资源所有者密码凭据，客户端凭据，以及一个扩展定义其他类型的机制。1.3.1 授权码授权码是通过使用授权服务器作为客户端和资源所有者之间的中介被获取的。客户端请求授权指示资源所有者的授权服务器，这样服务器反过来又指导资源所有者将授权码返回客户端。而不是直接向资源的所有者申请授权。在引导资源所有者将授权码返回客户端之前，授权服务器验证资源的所有者并获得授权。由于资源的所有者只跟授权服务器认证，资源所有者的凭证不会与客户端分享。授权码提供了一些重要的安全优势如验证客户端的能力，和不通过资源所有者的用户代理而直接给客户端的访问令牌

12、传输，可能暴露给他人，包括资源的所有者。1.3.2 隐式隐式授予是一个简化的授权码流，为了优化客户端实现在浏览器中使用例如JAVAScript的脚本语言。在隐流中，客户端直接发出一个访问令牌（作为资源的所有者授权的结果），而不是给客户端发出一个授权码。授予类型是隐式的就像没有中间的凭据（如授权码）被发出（后来被用来获得一个访问令牌）。 当发出一个隐含的授予，授权服务器不验证客户端。在某些情况下，可以通过用来给客户端提供的访问令牌的重定向URI，来验证客户端的身份。访问令牌可能会被暴露给资源的所有者或者其它要访问资源所有者的用户代理的应用程序。隐式授权提高了某些客户端的响应速度和效率（如实现在浏

13、览器应用程序的客户端），因为它降低了获得所需的往返访问令牌的数量。然而，这种便利应权衡使用隐式授权的安全隐患，尤其是当授权码授予类型是可用的。1.3.3 资源所有者密码凭据资源所有者密码凭据（即用户名和密码）可直接作为一个权限授予获得访问令牌。凭证只有在资源所有者和客户端之间存在一个高等级的信任的时候使用（如设备的操作系统或一个高特权的应用程序），或者当其它权限授予类型不可用时（如授权码）凭据才被使用。尽管这种授权类型需要引导客户端访问资源所有者凭证，资源所有者凭证被用于一个单一的请求，并交换一个访问令牌。这种授予类型用持久的访问令牌或刷新令牌来交换凭据，这样可以消除客户端必须存储以供将来使用

14、的资源所有者凭证的需要。1.3.4 ClientCredentials客户凭证（或其他形式的客户端身份验证）可被用作一个权限授予当授权范围被限制在保护资源在客户端控制下，或者 授权资源先前被安排给授权服务器。当客户端正以自己的名义行事（客户端也是资源所有者），或者客户端正在请求访问根据一个授权先前安排的授权服务器的受保护资源时，客户端凭证被典型被用来作为一种权限授予。1.4 访问令牌访问令牌是用于访问受保护的资源的凭据。 一个访问令牌是一个字符串，代表发送给客户端的授权。字符串通常是对客户端不透明的。令牌代表访问的具体范围和持续时间，由资源所有者授予，被资源的服务器和授权执行服务器强行执行。令

15、牌可以表示用于检索授权信息的标识符，或用一种可核查的方式自我包含在授权信息中（即一个令牌字符串的一些数据组成和签名）。 超过了本规范范围的额外的身份验证凭据，可能为了客户端使用令牌而被需要。访问令牌提供了一个抽象层，用一个简单的被资源服务器理解的令牌来更换不同单一授权结构（如用户名和密码）。 这种抽象使发出的访问令牌比用来接收他们的权限授予更具有限制性，以及删除资源服务器的需要去了解一个广泛的验证方法。访问令牌可以有不同的格式，结构和基于资源服务安全性需求的方法利用率（如加密属性）。访问令牌的属性和用于访问受保护资源的方法超出了本规范和同伴规范定义的范围。1.5 刷新令牌刷新令牌是用来获取访问

16、令牌的凭据。在当前的访问令牌变成无效或过期，或获得额外的访问令牌具有相同或更窄的范围（访问令牌可能有较短期少于资源授权的权限所有者）时，刷新令牌被授权服务器发送给客户端用于获取一个新的访问令牌。分发刷新标记是可选的。如果authorization server分发可刷新令牌，那么当分发access token的时候就会将可刷新令牌包括进去。刷新令牌是一个字符串，代表权限被资源所有者授予给客户端。字符串通常对客户端是透明的。令牌表示用于检索授权信息的标示符。与访问令牌不同的是，可刷新令牌只被用于授权服务器，而不会发送给资源服务器。发送给资源服务器的始终是访问令牌。下面看一个关于可刷新令牌的处理流

17、程图。该流程图包括以下步骤：（A）客户端访问授权服务器进行验证，通过提供授权认可，以请求访问令牌。（B）授权服务器验证客户端并且验证授权认可（四种类型中的一种），如果有效则分发一个访问令牌和一个可刷新令牌（C）通过提供访问令牌，客户端可向资源服务器请求受保护资源。（D）资源服务器验证验证访问令牌，如果有效，就响应请求。（E）步骤（C）和（D）重复进行，直到访问令牌过期。如果client知道访问令牌过期，就直接跳到步骤（G），否则它还会请求受保护资源。（F）由于访问令牌失效，资源服务器返回无效令牌错误。（G）client请求一个新的访问令牌，通过向授权服务器提供可刷新令牌并进行验证。对clien

18、t的验证条件是基于client的类型和authorization server的策略。（H）authorization server验证client和可刷新令牌，如果有效就分发一个新的访问令牌（你也可以再发送一个新的可刷新令牌）2 ClientRegistration客户注册发起协议之前，客户端注册授权服务器。在客户端注册透过何种途径与授服务器超出此范围规范，但通常涉及与最终用户互动HTML登记表。客户端注册不需要客户端和授权服务器之间的直接互动。当支持授权服务器时，注册可以依靠其他手段建立信任和获取所需的客户端属性（例如：重定向的URI，客户端类型）。例如，可以注册使用自发行或第三方发行的主

19、张来实现，或授权服务器执行客户端发现使用信任的渠道。2.1 客户端类型OAuth的定义了两种客户端类型，在授权服务器下根据自己的能力验证安全性（即保持他们的客户端凭据的保密的能力）：保密性：客户能够保持其凭据机密性（如客户端一个安全的服务器与实施限制访问的客户端凭据），或使用其他手段保证客户端身份验证安全的能力。公开性：客户无法维持其保密凭据（如客户资源所有者的设备上执行如安装本地应用程序或基于Web浏览器应用程序），无法通过任何其他手段确保客户端身份验证安全。客户类型的制定是基于授权服务器安全认证的定义和它可接受的风险级别的客户端凭据。此规范已经围绕以下客户端设计配置文件：Web应用程序We

20、b应用程序是一个网络服务器上运行的机密的客户端。资源所有者通过一个HTML用户界面呈现在资源所有者的设备上的用户代理来访问客户端。客户端凭据，以及任何分发给客户端的访问令牌被存储在Web服务器上，并没有暴露或由资源的所有者访问。用户代理为基础的应用用户代理为基础的应用是一个公共的客户端，客户端代码是从Web服务器下载，并在资源所有者的设备（如Web浏览器）上的用户代理执行。“协议”的相关数据和凭证能方便（而且往往可见）资源的所有者访问。 由于这些应用程序驻留在用户代理上，他们可以在请求权限时无缝使用用户代理能力。本机应用程序本机应用程序是在公共的客户端上安装和资源所有者的设备上执行的。“协议”

21、的相关数据和凭据可被资源的所有者访问。据推测，任何包含在应用程序内的客户端身份验证凭据可以被提取。另一方面，动态分发的凭据，例如访问令牌或刷新令牌可以得到一个可接受的水平保护。在最低限度，隔离这些凭据与该应用程序可能交互的敌对服务器之外。在某些平台，这些凭据可能被保护，使之与驻留在同一设备上的其它应用程序隔离。2.2 客户端标识符授权服务器分发给登记客户端一个客户标识符一个唯一的字符串代表由客户提供的登记信息。客户端标识符是不是公开的秘密，它暴露给资源所有者，绝不能单独适用于客户端身份验证。2.3 客户端身份验证如果客户端类型是保密的，客户端和授权服务器建立适合授权服务器的安全需求的一个客户端

22、验证方法。授权服务器可以接受任何形式的客户端认证，满足其安全要求。保密客户通常使用授权服务器发出（或建立）一套用于授权的客户凭证（如密码，公钥/私钥对）的客户端凭据。授权服务器不应该对客户端的类型做假设，或者接受没有与客户或者开发者建立信任所提供的类型信息。授权服务器可能用公共客户建立一个客户授权方法。但是，授权服务器决不能为了认证客户的目的而依靠公共客户端认证。客户端不得使用多个验证方法在每个请求。2.3.1 客户端的密码私有一个客户端密码的客户端可以使用HTTP基本验证计划。客户端标识符用作用户名，客户端的密码是用来作为密码。例如（额外的换行符仅用于显示目的）：授权：基本czZCaGRSa

23、3F0MzpnWDFmQmF0M2JW另外，授权服务器可能允许客户端凭证包括在请求体使用如下的参数：Client_id REQUIRED. 在登记过程中客户端标示符分发给客户端 Client-secret 客户 secret。客户端可以省略参数如果客户secret是空字符串。客户端凭证包括在请求正文中使用两个客参数不被推荐，并应限于客户端无法直接利用HTTP基本身份验证计划（或其他基于密码的HTTP认证方案）。例如，请求刷新一个访问令牌（第6章）使用正文参数（额外的换行符仅用于显示目的）： POST /token HTTP/1.1 Host: Content-Type:application/

24、x-www-form-urlencoded;charset=UTF-8grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw当将请求发送到令牌端点时，授权服务器必须要求使用传输层安全机制，这样请求使用此认证方法的导致明文凭据的传输。由于这个客户端的身份验证方法包括密码，授权服务器必须保护任何终端利用它对抗端点蛮力攻击。2.3.2 其他身份验证方法授权服务器可能支持任何合适的HTTP认证计划匹配其安全性要求。当用其

25、他的身份验证方法，授权服务器必须在客户端标识符（登记备案）和身份验证方案之间定义一个映射。2.4 未注册的客户端本规范不排除使用未经注册的客户。但是，这样的客户使用超出此范围规范，并且需要额外的安全分析和审查其互操作性的影响。3 协议的端点授权过程中利用两个端点（HTTP资源）：授权端点-用于向通过用户代理重定向的资源所有者获取授权。令牌终点 -用来交换权限授予访问令牌，通常随着客户端身份验证。并非每个授权授予类型采用两个端点。如有需要，扩展授予类型可以定义额外的端点。3.1 授权端点授权端点用来与资源所有者交互,获得权限的授予。授权服务器必须首先验证资源的所有者的身份。方式授权服务器验证资源

26、所有者（如用户名和密码登录，会话cookies）超出范围本规范。客户端透过何种途径获得授权端点的位置超出本规范的范围，但位置通常在服务文档里被提供。端点URI可能包括一个“application/x-www-form-urlencoded”格式化的查询组件，加入额外的查询参数时，必须保留。端点URI不能包含片段组件。由于请求授权端点导致用户身份验证和明文凭据（HTTP响应）的传输，授权服务器必须要求在授权端点发送请求时使用的传输层安全机制。授权服务器必须支持TLS 1.0,应该支持TLS 1.2和它的以后的版本，可以支持额外的传输层机制以满足它的安全性需要。授权服务器必须支持对授权断点的HTT

27、P “GET” 方法的使用，也可以支持“POST”方法的使用。没有赋值的参数必须当做它们是从请求中被忽略的。授权服务器必须忽视无法识别的请求参数。请求和回应参数必须不能被包含超过一次。3.1.1 响应类型 是被授权码授权类型和隐式授权类型流使用的。客户端通知需要授权类型的授权端点使用以下参数。response_typeREQUIRED. 它的值必须是请求授权码中一个码就像4.1.1结所描述，令牌就如4.2.1结描述的请求一个访问令牌（隐式授予），或者一个如8.4结描述的注册扩展值。如果响应类型包括一个或者更多空格字符（%x20）, 它被解释为一个空格分隔列表值，值的顺序没有关系（例如“a b”

28、跟“b a”是一样的） 如果一个授权响应丢失了“response_type”参数，授权服务器必须返回一个错误回复，就如4.1.2.1结所述。3.1.2 重定向端点与资源的所有者完成互动后，授权服务器指示资源所有者的用户代理返回客户端。授权服务器重定向用户代理到客户端的重定向终点，重定向终点是先前客户端注册进程或者发出授权请求时由授权服务器建立的。 重定向端点URI必须是一个绝对的URI，如4.3所述。终点 URI可能包含anapplication/x-www-form-urlencoded格式化查询组件，加入额外的查询参数时，必须保留。3.1.2.1 端点要求保密如果一个重定向请求将导致授权码的传输或者访问令牌通过一个开放网络（在资源所有者的用户代理和客户端之间），客户端应需要使用传输层安全机制。 传输层安全性的缺乏可能对客户端的安全和受保护资源授权访问造成严重影响。当客户端将授权过程当做一种委派最终用户身份验证时，传输层安全机制的使用变得尤为关键。3.1.2.2 注册要求授权服务器应要求所有client用授权终端登记他们先前的重定向URI，并且必须要求以下的client登记他们的重定向URI：a） publi