html5 微信网站 源码,怎样通过阿里巴巴网站开发客户,怎样策划一个营销型网站,网络推广销售是做什么的#xff08;一#xff09;背景知识 OAuth 2.0很可能是下一代的“用户验证和授权”标准#xff0c;目前在国内还没有很靠谱的技术资料。为了弘扬“开放精神”#xff0c;让业内的人更容易理解“开放平台”相关技术#xff0c;进而长远地促进国内开放平台领域的发展#xf… 一背景知识 OAuth 2.0很可能是下一代的“用户验证和授权”标准目前在国内还没有很靠谱的技术资料。为了弘扬“开放精神”让业内的人更容易理解“开放平台”相关技术进而长远地促进国内开放平台领域的发展笔者特意将 OAuth 2.0协议翻译成中文。 目前 OAuth 2.0还没有最后定稿最新的修改版是第 11个版本本文下面的翻译即基于这个第 11版本。原文见 http://tools.ietf.org/html/draft-ietf-oauth-v2-11。 二术语中英对照表由于 OAuth协议版本较多1.0,1.0a,2.0等并且各个版本中的技术术语也各不相同关于英文技术术语与中文的对应关系我们以 OAuth 2.0的第 11版本中的描述为准。另外有一些情况一些英文术语不容易找到普遍接受的汉语释义翻译过来反而可能引起误解而英文术语本身可能更容易理解因此就不考虑对这部分词汇做翻译了。比如“web service”、“endpoint”、“user-agent”、“URI”、“cookie”等你只需要知道它是什么就好了。还有一些特别难于翻译的词汇比如“profile”这个词用在协议里大概表示协议功能的某个剖面、子集、子视图或轮廓。如果翻译成“视图”容易让人想到“view”这个词产生冲突最后我在这里创造了一个新词汇“子态”。下面是整理出来的重要技术术语的中英对照表云计算 —— cloud computing 第三方 —— third-party应用/程序 —— application私有证书 —— credential身份验证 —— authentication授权 —— authorization明文 —— clear-text客户端 —— client {译者注本文中的客户端与平常所说的“客户端”并不相同是相对资源服务器和授权服务器来说的它可能指第三方应用的服务器程序或客户端程序}服务器 —— server资源拥有者 —— resource owner受保护资源 —— protected resource资源服务器 —— resource server访问令牌 —— access token授权服务器 —— authorization server访问许可 —— access grant实体 —— entity签名 —— signature刷新令牌 —— refresh token作用域 —— scope授权码 —— authorization code标识符 —— identifier密钥 —— secret断言 —— assertion原生程序 —— native application子态 —— profile同源策略 —— same-origin policy回调 —— callback自治的 —— autonomous查询参数部分 —— query component分段参数部分 —— fragment component媒体类型 —— media type厂商特性的 —— vendor-specific增强型巴科斯范式 —— ABNF互联网编号分配机构 —— IANA互联网工程指导组 —— IESG标准轨道 —— standards-track 三中文译本 1.引言随着分布式 web service和云计算的使用越来越多第三方应用需要能访问到一些服务器托管资源。这些资源通常都是受保护的并且要求使用资源拥有者的私有证书典型的证书是用户名和密码进行身份验证。在传统的基于客户端-服务器的身份验证模型中客户端为了访问服务器的受保护资源是使用资源拥有者的私有证书来做身份验证的。为了让第三方应用能够访问受保护资源资源拥有者必需将他/她/它的私有证书透露给第三方。这引出了很多问题并存在很多局限性 •第三方应用需要用明文保存资源拥有者的私有证书一般是密码留作以后再次使用。 •虽然密码验证会造成安全隐患服务器仍然需要支持用密码做身份验证对称的密码验证。 •第三方应用对资源拥有者的受保护资源获得过多的使用权限而资源拥有者没有能力限制访问到某个资源子集限制持续时间或限制这些资源所能支持的访问方式。 •资源拥有者无法在不影响所有第三方的前提下单独撤销某个第三方的访问权限他/她/它只能通过修改密码来回收所有权限。 OAuth通过将客户端和资源拥有者的角色进行分离来解决这些问题。在 OAuth中客户端通常不是资源拥有者而是代表资源拥有者来操作提出请求来访问由资源拥有者控制并由资源服务器托管的资源然后得到与资源拥有者不同的一套私有证书。 客户端并不是直接使用资源拥有者的私有证书来访问受保护资源而是得到一个访问令牌——一个代表某一特定作用域、持续时间和其它属性的字符串{译者注非常重要的一个概念英文叫 accesstoken}。访问令牌由授权服务器在资源拥有者的授意下分发给第三方客户端。客户端使用访问令牌来访问由资源服务器托管的受保护资源。 例如一个 web用户资源拥有者能够准许一个打印服务客户端访问她存储在另一个照片共享服务资源服务器中的照片而不用将她的用户名和密码透露给这个打印服务。她在一个被该照片分享服务信任的身份验证服务授权服务器上完成验证而这个验证服务会将特定于委托服务的私有证书令牌分发给原打印服务。 基于资源服务器对安全的需求访问令牌可以有不同的格式、结构和使用方式例如密码学特性。访问令牌的属性和用以访问受保护资源的方式不在本规范的规定范围之内而是由相关的其它规范来定义。授权服务器和资源服务器之间的交互方式不在本规范的规定范围之内。 1.1.符号规范这篇文档中的关键词“必须”、“一定不能”、“要求”、“会”、“不会”、“应该”、“不应该”、“建议”、“可以”、“可选的”遵从[RFC2119]中的解释。 这篇文档使用出自[I-D.ietf-httpbis-p1-messaging]的增强型巴科斯范式ABNF标记法。另外介绍一些规则定义的出处URI-Reference出自[RFC3986]OWS、RWS和 quoted-string出自[I-D.ietf-httpbis-p1-messaging]。除非特别提到否则所有协议参数的名字和值都是大小写敏感的。 1.2.专业术语解释受保护资源能够使用 OAuth请求获取的访问限制性资源。 资源服务器能够接受和响应受保护资源请求的服务器。 客户端获取授权和发送受保护资源请求的应用。 资源拥有者能够对受保护资源进行访问许可控制的实体。 终端用户起到资源拥有者角色的用户。 令牌分发给客户端的代表访问授权的字符串。通常这个字符串对客户端来说是不透明的。令牌代表资源拥有者许可的访问作用域和持续时间并由资源服务器和授权服务器强制保证。这个令牌可以代表一个标识符用于检索授权信息或以一种可验证的方式自包含授权信息即一个包含数据和签名的令牌字符串。令牌可能只代表纯粹的访问能力。而为了让客户端使用令牌也可能需要一些多余的特定验证证书。 访问令牌被客户端用来代表资源拥有者发送验证请求的令牌。 刷新令牌被客户端用来获取新的访问令牌的令牌而不用资源拥有者的参与。 授权码一个短期令牌代表终端用户的授权。授权码用于获取一个访问令牌和一个刷新令牌。 访问许可用于描述中间形式的私有证书如终端用户的密码或授权码的一个通用词汇代表资源拥有者的授权。客户端使用访问许可来获取访问令牌。通过将各种形式的访问许可都交换成访问令牌资源服务器只需要支持一种验证机制。 授权服务器能够成功验证资源拥有者和获取授权并在此之后分发令牌的服务器。授权服务器可以和资源服务器是同一个服务器也可以是不同的实体。单独一个授权服务器可以为多个资源服务器分发令牌。 终端用户授权 endpoint授权服务器上能够验证终端用户并获取授权的 HTTP endpoint。终端用户授权 endpoint在第 4节详细描述。 令牌 endpoint授权服务器上能够分发令牌和刷新过期令牌的 HTTP endpoint。令牌 endpoint在第 5节详细描述。 客户端标识符分发给客户端的唯一标识用于客户端向授权服务器标识自己。客户端标识符可以有一个对应的密钥。客户端标识符在第 3节详细描述。 1.3.概述OAuth为客户端提供了一种代表资源拥有者访问受保护资源的方法。在客户端访问受保护资源之前它必须先从资源拥有者获取授权访问许可然后用访问许可交换访问令牌代表许可的作用域、持续时间和其它属性。客户端通过向资源服务器出示访问令牌来访问受保护资源。 访问令牌提供了一个抽象层将不同的授权结构如用户名密码、断言替换成资源服务器可以理解的单一令牌。这种抽象使得分发短期有效的访问令牌成为可能也使得资源服务器不必理解多种多样的授权机制。 图 1:抽象的协议流程 图 1所示的抽象流程协议的总体架构它包含下列步骤(A)客户端从资源拥有者那里请求授权。授权请求能够直接发送给资源拥有者或者间接地通过授权服务器这样的中介而后者更为可取。(B)客户端收到一个访问许可它代表由资源服务器提供的授权。(C)客户端使用它自己的私有证书到授权服务器上验证并出示访问许可来请求一个访问令牌。(D)授权服务器验证客户端私有证书和访问许可的有效性如果验证通过则分发一个访问令牌。(E)客户端通过出示访问令牌向资源服务器请求受保护资源。(F)资源服务器验证访问令牌的有效性如果验证通过则响应这个资源请求。 1.4访问许可访问许可代表资源拥有者提供的授权。访问许可的类型取决于客户端使用的获取方式和授权服务器所支持的方式。 1.4.1授权码授权码是通过将终端用户引导到授权服务器而获得的一种访问许可。授权服务器验证终端用户获得授权然后向客户端分发一个授权码。因为终端用户只在授权服务器上进行验证所以终端用户的密码从来不用分享给客户端。 当客户端通过一个 user-agent同终端用户进行交互的时候授权码这种访问许可是很合适的。 图 2:获取授权码 图 2所示的授权码获取流程包含下列步骤 (A)客户端通过将终端用户的 user-agent引导到授权服务器的终端用户授权 endpoint来发起这个流程。客户端传入标识符、请求作用域、本地状态和一个重定向 URI在访问被许可或被拒绝后授权服务器会重新将 user-agent引导回这个 URI。 (B)授权服务器验证终端用户的身份通过 user-agent并且确定终端用户是许可还是拒绝了客户端的访问请求。 (C)如果访问被许可授权服务器会使用重定向 URI将 user-agent引导回客户端。授权服务器传回一个授权码给客户端用于进一步获取访问令牌。 一旦客户端获得了授权码它会到授权服务器上去做验证使用客户端私有证书并出示授权码访问许可以借此请求一个访问令牌。在客户端无法维护它自己的私有证书的情况下如原生程序或用某种user-agent脚本实现的程序授权服务器在(C)步直接给客户端分发一个访问令牌而不再分发一个授权码。获得授权码的过程在第 4节详述。 1.4.2资源拥有者密码证书资源拥有者密码证书例如用户名和密码可以直接用作访问许可来获取访问令牌。这种私有证书只应该在以下两种情况下使用当在资源拥有者和客户端之间有很强的信任关系的时候例如资源拥有者的计算机操作系统或具有很高特权的程序以及当其它访问许可类型如授权码不可用的时候。 即使这种许可类型需要客户端直接访问资源拥有者的私有证书资源拥有者的私有证书也只是在一个请求中使用并交换成访问令牌。与[RFC2617]定义的 HTTP Basic验证机制不同这种许可类型不再需要客户端存储资源拥有者的私有证书以备日后使用。 图 3:获取资源拥有者密码证书 在图 3中客户端直接从资源拥有者请求授权。当资源拥有者是一个终端用户时客户端通常的做法是提示终端用户输入用户名和密码。 1.4.3客户端私有证书当授权作用域限制在客户端所控制的受保护资源或之前与授权服务器约定好的受保护资源时客户端本身的私有证书可被用作访问许可。客户端私有证书用作访问许可的典型例子是当客户端代表它自己执行操作时客户端同时也是资源拥有者。 1.4.4刷新令牌访问令牌的生命周期通常比资源拥有者授予的要短一些。当分发一个访问令牌时授权服务器可以同时传回一个刷新令牌在当前访问令牌超时后客户端可以用这个刷新令牌重新获取一个访问令牌。当请求新的访问令牌时刷新令牌担当起访问许可的角色。使用刷新令牌不再需要再次与资源拥有者交互也不需要存储原始的访问许可来获得访问令牌和刷新令牌。 图 4:刷新访问令牌 图 4所示的刷新令牌流程包含下列步骤 (A)客户端通过使用它自己的私有证书在授权服务器上验证并出示一个访问许可。 (B)授权服务器验证客户端私有证书和访问许可的有效性如果通过则分发一个访问令牌和刷新令牌。 (C)客户端通过出示访问令牌向资源服务器请求受保护资源。 (D)资源服务器验证访问令牌的有效性如果通过则相应这个请求。 (E)步骤(C)(D)不停重复直到访问令牌过期。如果客户端不知道访问令牌过期它会再请求一次受保护资源。否则跳到步骤(G)。 (F)因为访问令牌是无效的过期了资源服务器返回一个无效令牌错误。 (G)客户端通过使用它的私有证书在授权服务器上验证并出示刷新令牌用作访问许可来请求一个新的访问令牌。 (H)授权服务器验证客户端私有证书的有效性如果通过则分发一个新的访问令牌也可能还有一个刷新令牌。 1.4.5断言断言在 OAuth和其它信任框架之间架起一座桥梁。它们允许客户端利用现成的信任关系来获取访问令牌。一个断言所代表的访问许可取决于断言类型、断言内容以及断言被分发的方式而这些内容不在本规范的规定范围之内。断言可以用在协议扩展模型的部分它为授权服务器提供了一种支持其它访问许可类型的方式。 2.客户端的各种子态 2.1 Web Server子态Web Server子态适用于有能力与终端用户的 user-agent通常是浏览器交互并能够从授权服务器接收通过重定向请求即有能力担当 HTTP服务器的角色的客户端。 图 5: Web Server流程 图 5所示的 web server流程包含下列步骤 (A)如第 4节所述web客户端通过将终端用户的 user-agent重定向到授权服务器来发起这个流程。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向 URI在访问被许可或被拒绝后授权服务器会重新将终端用户引导回这个 URI。 (B)授权服务器验证终端用户借助于 user-agent并确定终端用户是否许可客户端的访问请求。 (C)假定终端用户许可了这次访问授权服务器会将 user-agent重定向到之前提供的重定向 URI上去。授权服务器为客户端传回一个授权码做获取访问令牌之用。 (D)如第 5节所述客户端通过验证并传入上一步取得的授权码从授权服务器请求一个访问令牌。 (E)授权服务器验证客户端私有证书和授权码的有效性并返回访问令牌。 2.2 User-Agent子态User-Agent子态适用于常驻 user-agent的客户端应用典型的例子是用诸如 JavaScript语言编写并运行在浏览器的程序。这些客户端不能保存客户端私有证书并且客户端的验证基于 user-agent的同源策略。 在其它子态中客户端对于终端用户的授权和访问令牌使用分开的不同请求来完成而与之不同的是在 user-agent子态中客户端以 HTTP重定向的方式在终端用户授权请求的结果中获取到访问令牌。客户端请求授权服务器将user-agent重定向到另一个web服务器或user-agent能访问到的本地资源而且 user-agent有能力从响应信息中提取出访问令牌并传给客户端。 这种 user-agent子态并不使用客户端密钥因为客户端执行程序常驻于终端用户的计算机或设备上这使得客户端密钥可以被访问或收集到。因为访问令牌被编码到重定向 URI中所以它可能会暴露给终端用户和常驻计算机或设备上的其它应用。 图 6: User-Agent流程 图 6所示的 user-agent流程包含下列步骤 (A)如第 5节所述客户端将 user-agent引导到终端用户授权 endpoint。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向 URI在访问被许可或被拒绝后授权服务器会重新将终端用户引导回这个 URI。 (B)授权服务器验证终端用户通过 user-agent并确认终端用户是许可还是拒绝了客户端的访问请求。 (C)如果终端用户许可了这次访问那么授权服务器会将 user-agent引导到之前提供的重定向 URI。重定向 URI会在 URI片断{译者注URI片断是指 URI中#号之后的内容}中包含访问令牌。 (D) user-agent响应重定向指令向 web服务器发送不包含 URI片断的请求。user-agent在本地保存 URI片断。 (E) web服务器返回一个 web页面通常是嵌入了脚本的 HTML网页这个页面能够访问完整的重定向 URI它包含了由 user-agent保存的 URI片断同时这个页面能够将包含在 URI片断中的访问令牌和其它参数提取出来。 (F) user-agent在本地执行由 web服务器提供的脚本该脚本提取出访问令牌并将它传递给客户端。 2.3原生程序原生程序是作为原生代码运行在终端用户计算机或设备上的客户端即在 user-agent之外运行或作为一个桌面程序。这些客户端通常有能力与终端用户的 user-agent交互或嵌入 user-agent但是在这些交互如何影响终端用户体验的方式上受到限制。在很多情况下原生程序无法直接从服务器接收回调请求例如防火墙、操作系统限制。 基于不同的需求和期望的终端用户体验原生程序客户端可以用不同的方式实现。原生程序客户端可以如第 4节所述通过启动一个外部 user-agent来访问终端用户授权 endpoint。客户端可以通过下面的方式捕获响应文本提供一个具有自定义 URI scheme{译者注URI scheme就是一个 URI里面的第一部分即冒号前面的部分}的重定向 URI在操作系统上注册过以便调用客户端应用或者提供一个指向在客户端控制下的服务器资源的重定向 URI这使得响应文本对客户端可见例如使用窗口标题或在 user-agent外面可以访问到的其它位置。 如第 4节所述通过嵌入一个 user-agent来访问终端用户授权 endpoint。客户端通过与嵌入的 user-agent直接通信获取到响应文本。提示终端用户输入密码使用密码直接获得一个访问令牌。通常来讲这是一种不推荐的方式因为它将终端用户的密码直接交给了第三方客户端而客户端不得不用明文存储密码。它还要求服务器支持基于密码的身份验证。当在启动外部浏览器和嵌入的 user-agent之间进行选择时开发者应该考虑下列因素外部浏览器可能会提高完成比率因为终端用户可能已经登录过了而不需要重新进行身份验证。嵌入的 user-agent通常能提供更好的用户流程因为它不必切换上下文并打开新窗口。嵌入的 user-agent对安全提出了挑战因为用户在一个无法辨别的窗口之中进行身份验证而不像很多 user-agent那样能提供可视化的保护。 2.4自治态 自治客户端使用现成的信任关系或框架来建立授权。基于自治客户端的需求和他们所依赖的现存信任框架自治客户端可以用不同的方式实现。自治客户端可以 •通过使用客户端私有证书与授权服务器进行验证从而获得访问令牌。访问令牌的作用域局限于受客户端控制的受保护资源或者其它资源拥有者与授权服务器预先约定的资源。 •使用现存的某种访问许可它被表达成授权服务器所支持的某种断言格式。使用断言需要客户端从一个断言发行方获得一个断言如 SAML[OASIS.saml-core-2.0-os]断言或自己分发一个断言。断言的格式、获得断言的过程以及验证断言的方法由断言发行方和授权服务器定义不在本规范的规定范围之内。3.客户端私有证书当与授权服务器进行交互时客户端使用一个私有证书集合来标识自己这个证书集合包含一个客户端标识符和用于客户端身份验证的其它一些属性。客户端获得私有证书的方式不在本规范的规定范围之内不过这通常都包含一个在授权服务器上注册的过程。 考虑到一些客户端的本质特性在与客户端没有确立信任关系的前提下授权服务器不应该对客户端密钥的私密性做出任何假设。授权服务器不应该向没有能力对密钥进行秘密保存的客户端分发密钥。 授权服务器可以使用任一合适的私有证书集合和验证机制来对客户端进行身份验证。客户端一定不能在一个请求中使用多个私有证书集合和验证机制。 3.1客户端密码证书客户端密码证书使用一个共享的对称密钥来验证客户端。客户端标识符和密码被包含在请求当中使用[RFC2617]定义的 HTTP Basic验证机制将客户端标识符作为用户名username并将客户端密码作为密码password来传送。例如换行符只用于显示目的 POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_typeauthorization_codecodei1WsRn1uB1
redirect_urihttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb作为可选方式客户端可以使用下列参数将密码包含在请求体request body中 client_id 必需参数。客户端标识符。 client_secret 必需参数。客户端密钥。 例如换行符只用于显示目的 POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_typeauthorization_codeclient_ids6BhdRkqt3
client_secretgX1fBat3bVcodei1WsRn1uB1
redirect_urihttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb授权服务器必须能够使用请求参数和 HTTP Basic验证协议两种方式接受客户端私有证书。授权服务器可以支持更多适合于密码证书传输的验证机制 3.2客户端断言证书客户端断言证书用于不宜使用密码明文共享对称密钥或密码无法为客户端验证提供足够安全性的情况。在这样的情况下常见的做法是使用诸如 HMAC或数字签名之类不需要发送明文密钥的其它机制。客户端断言证书提供了一种扩展机制能够使用被授权服务器所支持的某种断言格式进行客户端身份验证。 使用断言需要客户端从一个断言发行方获得一个断言如 SAML[OASIS.saml-core-2.0-os]断言或自己分发一个断言。断言的格式、获得断言的过程以及验证断言的方法由断言发行方和授权服务器定义不在本规范的规定范围之内。 当使用客户端断言时客户端传送下列参数 client_assertion_type 必需参数。由授权服务器定义的断言格式。这个值必须是一个绝对 URI。client_assertion 必需参数。客户端断言。 例如客户端使用一个 SAML 2.0断言发送如下访问令牌请求来验证自己换行符只用于显示目的 POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_typeauthorization_codecodei1WsRn1uB1
client_assertionPHNhbWxwOl[...omitted for brevity...]ZT4%3D
client_assertion_type
urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion
redirect_urihttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb当使用一个客户端断言和一个授权码获得一个访问令牌的时候需要一个机制在用于获取授权码的“client_id”参数值和客户端断言之间完成映射。这个机制不在本规范的规定范围之内但对于与授权码结合使用的任何客户端断言类型都必须明确指明。 对于那些使用客户端断言证书但不包含能够提供下列信息的 HMAC或签名值的访问令牌请求授权服务器必须拒绝响应•指明这个断言是专门分发给当前接收 endpoint来处理的一般是通过一个包含接收 endpoint标识符的 audience或 recipient值。 •标识出分发断言的实体一般是通过一个 issuer值。 •用一个绝对时间标识出断言在何时过期一般是通过一个包含 UTC日期/时间值的过期值。授权服务器必须拒绝过期的断言。4.获得终端用户授权在客户端能够访问一个受保护资源之前它必须首先从终端用户那里获取授权。为了获得终端用户授权客户端需要将终端用户引导到终端用户授权 endpoint。一旦获得授权终端用户的访问许可会被表示成一个授权码客户端能够使用它去获取一个访问令牌。 在终端用户授权 endpoint上终端用户首先在授权服务器上完成身份验证然后允许或者拒绝当前访问请求。授权服务器验证用户的方式例如用户名和密码登录OpenID会话 cookie和授权服务器获取终端用户授权的方式以及是否使用诸如 TSL之类的安全通道不在本规范的规定范围之内。然而授权服务器必须要首先验证终端用户的身份。 终端用户授权 endpoint的位置能够在服务器文档中找到。终端用户授权 endpoint的 URI可以按照[RFC3986]第 3节的定义包含一个查询参数部分它们在添加其它参数时必须被保留。 既然对于终端用户授权 endpoint的请求会导致用户身份验证和敏感信息的传输授权服务器应该要求在向终端用户授权 endpoint发送请求的时候使用诸如 TLS之类的传输层安全机制。 转载于:https://www.cnblogs.com/mrbug/p/6923006.html
