开放OAuth20cnWord格式.docx
《开放OAuth20cnWord格式.docx》由会员分享，可在线阅读，更多相关《开放OAuth20cnWord格式.docx（50页珍藏版）》请在冰豆网上搜索。
4.3资源所有者密码凭据28
4.3.1授权请求和应答29
4.3.2访问令牌请求29
4.3.3访问令牌应答31
4.4客户端凭证32
4.4.1授权请求和应答32
4.4.2访问令牌请求32
4.4.3访问令牌响应33
4.5扩展34
5分发访问令牌35
5.1成功的响应35
5.2错误响应36
6刷新访问令牌38
7访问受保护资源40
7.1访问令牌类型40
8可扩展性41
8.1定义访问令牌类型41
8.2定义新端点参数41
8.3定义新的权限授予类型42
8.4定义新的授权端点响应类型42
8.5定义额外的错误码42
9本地应用43
10安全注意事项44
10.1客户端认证44
10.2客户端模拟45
10.3访问令牌45
10.4刷新令牌45
10.5授权码46
10.6授权码重定向URI的操作46
10.7资源所有者密码保密47
10.8请求保密47
10.9端点授权47
10.10凭证猜测攻击47
10.11钓鱼攻击47
10.12夸站点请求伪造48
10.13Clickjacking（跨浏览器攻击）48
10.14代码注入和输入验证49
11IANA事项49
11.1OAuth
访问令牌类型注册表49
11.1.1注册模板49
11.2TheOAuthParametersRegistry50
11.2.1注册模板50
11.2.2初始登记册的类容51
11.3OAuth
授权端点响应类型注册表54
11.3.1注册模板55
11.3.2初始注册表内容55
11.4OAuth
扩展错误注册表56
11.4.1注册模板56
12CSRF（cross-siterequestforgery）57
12.1示例和特性57
12.2防范措施57
12.3影响CSRF的因素57
13共享session58
13.1问题58
13.1.1网站存在多个子域名的情况下如何共享session58
13.1.2同一个主域名不同服务器之间如何共享session58
13.2方案58
13.2.1创建数据库表58
13.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的定义四个角色：
resourceowner资源的所有者：
可以获得授权去访问受保护的资源的实体。
这句很绕口，简单来说就是资源的所
有者，这个所有者是指当初上传或生成的那个所有者，并不是指服务器的所有者。
resourceserver资源服务器：
承载受保护资源的服务器，可以接收和响应使用accesstoken（访问令牌）请求
受保护资源。
cilent客户端：
一个产生受保护资源请求的应用，该应用代表resourceowner，并且已经获得其
授权。
所以其实客户就是指前面说道的这种特性的应用，是种application。
authorizationserver授权服务器：
在成功验证资源所有者和获得授权后，服务器发行访问令牌给客户端。
授权服务器和资源服务器之间的相互作用超出本规范的范围。
授权服务器可能是同一台服务器作为资源的服务器或一个独立的实体。
单一授权服务器发出访问令牌可能被多个资源服务器接受。
1.2协议流
如图1所示的抽象流描述的四种角色之间的互动还包括了一下步骤:
（A）client（就是application）向resourceowner请求授权。
可以直接向resourceowner请求，但更好的是通过authorizationserver作为中间物间接获得。
（比如新浪微博的是否允许授权的页面）
（B）client获得了resourceowner的授权认可（authorizationgrant），此授权认可是四种标准授权认可类型中的一种，也可以是其中一种的扩展类型。
获得的授权认可的类型由client请求授权所使用的函数和authorizationserver支持的类型决定。
（比如采用特定的请求授权的url，但是传入不同的参数，或者使用的method不同，当然一切都至少服务器要支持）
（C）client提供授权认可，以请求一个accesstoken，该token是可以被authorizationserver验证的。
（D）authorizationserver验证client，并且核实授权认可，如果是有效，就发放accesstoken。
注意这里是两个验证，1验证client是不是被承认的，2验证resourceowner是不是真的授权了。
（E）clent提供accesstoken给resourceserver验证，判断此client是否可以获取受保护的资源。
（F）resourceserver核实accesstoken，如果有效则响应请求
1.3权限授予（AuthorizationGrant）
权限授予是一个凭证，代表着资源所有者的授权（访问它的受保护资源），它被客户端用来获得一个访问令牌。
此规范定义了四种授予类型：
的授权金是代表资源的凭据由所有者的授权（访问受保护的资源）客户端获得一个访问令牌。
此规范定义了四种授予类型：
授权码，隐式，资源所有者密码凭据，客户端凭据，以及一个扩展定义其他类型的机制。
1.3.1授权码
授权码是通过使用授权服务器作为客户端和资源所有者之间的中介被获取的。
客户端请求授权指示资源所有者的授权服务器，这样服务器反过来又指导资源所有者将授权码返回客户端。
而不是直接向资源的所有者申请授权。
在引导资源所有者将授权码返回客户端之前，授权服务器验证资源的所有者并获得授权。
由于资源的所有者只跟授权服务器认证，资源所有者的凭证不会与客户端分享。
授权码提供了一些重要的安全优势如验证客户端的能力，和不通过资源所有者的用户代理而直接给客户端的访问令牌传输，可能暴露给他人，包括资源的所有者。
1.3.2隐式
隐式授予是一个简化的授权码流，为了优化客户端实现在浏览器中使用例如JAVAScript的脚本语言。
在隐流中，客户端直接发出一个访问令牌（作为资源的所有者授权的结果），而不是给客户端发出一个授权码。
授予类型是隐式的就像没有中间的凭据（如授权码）被发出（后来被用来获得一个访问令牌）。
当发出一个隐含的授予，授权服务器不验证客户端。
在某些情况下，可以通过用来给客户端提供的访问令牌的重定向URI，来验证客户端的身份。
访问令牌可能会被暴露给资源的所有者或者其它要访问资源所有者的用户代理的应用程序。
隐式授权提高了某些客户端的响应速度和效率（如实现在浏览器应用程序的客户端），因为它降低了获得所需的往返访问令牌的数量。
然而，这种便利应权衡使用隐式授权的安全隐患，尤其是当授权码授予类型是可用的。
1.3.3资源所有者密码凭据
资源所有者密码凭据（即用户名和密码）可直接作为一个权限授予获得访问令牌。
凭证只有在资源所有者和客户端之间存在一个高等级的信任的时候使用（如设备的操作系统或一个高特权的应用程序），或者当其它权限授予类型不可用时（如授权码）凭据才被使用。
尽管这种授权类型需要引导客户端访问资源所有者凭证，资源所有者凭证被用于一个单一的请求，并交换一个访问令牌。
这种授予类型用持久的访问令牌或刷新令牌来交换凭据，这样可以消除客户端必须存储以供将来使用的资源所有者凭证的需要。
1.3.4ClientCredentials
客户凭证（或其他形式的客户端身份验证）可被用作一个权限授予当授权范围被限制在保护资源在客户端控制下，或者授权资源先前被安排给授权服务器。
当客户端正以自己的名义行事（客户端也是资源所有者），或者客户端正在请求访问根据一个授权先前安排的授权服务器的受保护资源时，客户端凭证被典型被用来作为一种权限授予。
1.4访问令牌
访问令牌是用于访问受保护的资源的凭据。
一个访问令牌是一个字符串，代表发送给客户端的授权。
字符串通常是对客户端不透明的。
令牌代表访问的具体范围和持续时间，由资源所有者授予，被资源的服务器和授权执行服务器强行执行。
令牌可以表示用于检索授权信息的标识符，或用一种可核查的方式自我包含在授权信息中（即一个令牌字符串的一些数据组成和签名）。
超过了本规范范围的额外的身份验证凭据，可能为了客户端使用令牌而被需要。
访问令牌提供了一个抽象层，用一个简单的被资源服务器理解的令牌来更换不同单一授权结构（如用户名和密码）。
这种抽象使发出的访问令牌比用来接收他们的权限授予更具有限制性，以及删除资源服务器的需要去了解一个广泛的验证方法。
访问令牌可以有不同的格式，结构和基于资源服务安全性需求的方法利用率（如加密属性）。
访问令牌的属性和用于访问受保护资源的方法超出了本规范和同伴规范定义的范围。
1.5刷新令牌
刷新令牌是用来获取访问令牌的凭据。
在当前的访问令牌变成无效或过期，或获得额外的访问令牌具有相同或更窄的范围（访问令牌可能有较短期少于资源授权的权限所有者）时，刷新令牌被授权服务器发送给客户端用于获取一个新的访问令牌。
分发刷新标记是可选的。
如果authorizationserver分发可刷新令牌，那么当分发accesstoken的时候就会将可刷新令牌包括进去。
刷新令牌是一个字符串，代表权限被资源所有者授予给客户端。
字符串通常对客户端是透明的。
令牌表示用于检索授权信息的标示符。
与访问令牌不同的是，可刷新令牌只被用于授权服务器，而不会发送给资源服务器。
发送给资源服务器的始终是访问令牌。
下面看一个关于可刷新令牌的处理流程图。
该流程图包括以下步骤：
（A）
客户端访问授权服务器进行验证，通过提供授权认可，以请求访问令牌。
（B）
授权服务器验证客户端并且验证授权认可（四种类型中的一种），如果有效则分发一个访问令牌和一个可刷新令牌
（C）
通过提供访问令牌，客户端可向资源服务器请求受保护资源。
（D）
资源服务器验证验证访问令牌，如果有效，就响应请求。
（E）
步骤（C）和（D）重复进行，直到访问令牌过期。
如果client知道访问令牌过期，就直接跳到步骤（G），否则它还会请求受保护资源。
（F）
由于访问令牌失效，资源服务器返回无效令牌错误。
（G）
client请求一个新的访问令牌，通过向授权服务器提供可刷新令牌并进行验证。
对client的验证条件是基于client的类型和authorizationserver的策略。
（H）
authorizationserver验证client和可刷新令牌，如果有效就分发一个新的访问令牌（你也可以再发送一个新的可刷新令牌）
2ClientRegistration 客户注册
发起协议之前，客户端注册授权服务器。
在客户端注册透过何种途径与授
服务器超出此范围规范，但通常涉及与最终用户互动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
客户secret。
客户端可以省略参数如果客户secret是空字符串。
客户端凭证包括在请求正文中使用两个客参数不被推荐，并应限于客户端无法直接利用HTTP基本身份验证计划（或其他基于密码的HTTP认证方案）。
例如，请求刷新一个访问令牌（第6章）使用正文参数（额外的换行符仅用于显示目的）：
POST/tokenHTTP/1.1
Host:
Content-Type:
application/x-www-form-urlencoded;
charset=UTF-8
grant_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响应）的传输，授权服务器必须要求在授权端点发送请求时使用的传输层安全机制。
授权服务器必须支持TLS1.0,应该支持TLS1.2和它的以后的版本，可以支持额外的传输层机制以满足它的安全性需要。
授权服务器必须支持对授权断点的HTTP“GET”方法的使用，也可以支持“POST”方法的使用。
没有赋值的参数必须当做它们是从请求中被忽略的。
授权服务器必须忽视无法识别的请求参数。
请求和回应参数必须不能被包含超过一次。
3.1.1响应类型
是被授权码授权类型和隐式授权类型流使用的。
客户端通知需要授权类型的授权端点使用以下参数。
response_type
REQUIRED.
它的值必须是请求授权码中一个码就像4.1.1结所描述，令牌就如4.2.1结描述的请求一个访问令牌（隐式授予），或者一个如8.4结描述的注册扩展值。
如果响应类型包括一个或者更多空格字符（%x20）,它被解释为一个空格分隔列表值，值的顺序没有关系（例如“ab”跟“ba”是一样的）
如果一个授权响应丢失了“response_type”参数，授权服务器必须返回一个错误回复，就如4.1.2.1结所述。
3.1.2重定向端点
与资源的所有者完成互动后，授权服务器指示资源所有者的用户代理返回客户端。
授权服务器重定向用户代理到客户端的重定向终点，重定向终点是先前客户端注册进程或者发出授权请求时由授权服务器建立的。
重定向端点URI必须是一个绝对的URI，如4.3所述。
终点URI可能包含an
"
application/x-www-form-urlencoded"
格式化查询组件，加入额外的查询参数时，必须保留。
3.1.2.1端点要求保密
如果一个重定向请求将导致授权码的传输或者访问令牌通过一个开放网络
（在资源所有者的用户代理和客户端之间），客户端应需要使用传输层安全机
制。
传输层安全性的缺乏可能对客户端的安全和受保护资源授权访问造成严重
影响。
当客户端将授权过程当做一种委派最终用户身份验证时，传输层安全机制
的使用变得尤为关键。
3.1.2.2注册要求
授权服务器应要求所有client用授权终端登记他们先前的重定向URI，并且
必须要求以下的client登记他们的重定向URI：
a）
publi
升级会员 