Notice: register_sidebar的调用方法不正确。“边栏1”侧边栏的参数数组中未设置id,缺省为“sidebar-1”。要消除此通知并保持现有的侧边栏内容,请手动将id设置为“sidebar-1”。 请查阅调试WordPress来获取更多信息。 (这个消息是在4.2.0版本添加的。) in /data/htdocs/seven2_blog/wp-includes/functions.php on line 3853
OAUTH 2.0 介绍 | Seventwo Blog
Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /data/htdocs/seven2_blog/wp-includes/plugin.php on line 601

OAUTH 2.0 介绍

2010-09-04 | 分类: opeo api
前言:

OAuth 1.0已经在IETF尘埃落定,编号是RFC5894
这也标志这OAuth已经正式成为互联网标准协议。
OAuth 2.0也早已经开始讨论和建立的草案
OAuth在OAuth组织的主页
OAuth2.0的草案
协议的创始人和推动者说OAuth 2.0的正式版会在今年年底正式发布,现在的草案还很不完善,有很多东西值得继续推敲。
如果你订阅了OAuth的mailing list,你会发现每天都有关于OAuth 2.0的议题,每天都有各种有深度的讨论。
作为一个学习者,虽然2.0尚未发布,但是此时跟进学习的好处无疑是巨大的。
①:在学习和研究以及思考如何支持OAuth 1.0的时候,我们并没有一个参照物,这是个崭新概念的互联网协议,我们并不能深刻理解协议这么制定的细节原因,OAuth 2.0无疑是个很好的参照物,作者也说,经过3年的OAuth 1.0开发和协议制定的工作,对OAuth有了很多思考,也理解其中的不足,因此才制定OAuth 2.0协议,所以,作为学习者,跟进学习的意义非常大。
②:协议还在细化制定阶段,通过跟进mailing list,也能理解一个协议制定的过程和讨论的方式。对于一昧的只会Follow协议,这种思路是很难形成的,这对我们增进自己的创新能力无疑也是非常有好处。
OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
OAuth 2.0的关注点在于简化客户端程序员的工作,其实是通过细化协议的方式,因为此前的OAuth实际上只提供了一种交换access token的标准机制,并没有针对不同的客户端提供不同的access token交换方式,而OAuth 1.0显然并不是在各种客户端都非常适用的,因此在2.0中,将此细化到各种客户端的flow都有相应的标准,比如web程序,桌面程序,手机或一些设备,都可以通过各自的特点来实现OAuth的flow.
学习的第一步,先看看官网推荐的入门文章
[singlepic id=286 w=494 h=494 float=center]
简单历史回顾
OAuth 1.0在2007年的12月底发布并迅速成为工业标准。
2008年6月,发布了OAuth 1.0 Revision A,这是个稍作修改的修订版本,主要修正一个安全方面的漏洞。
2010年四月,OAuth 1.0的终于在IETF发布了,协议编号RFC 5849。
OAuth 2.0的草案是在今年5月初在IETF发布的。
OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords.
OAuth是个安全相关的协议,作用在于,使用户授权第三方的应用程序访问用户的web资源,并且不需要向第三方应用程序透露自己的密码。
OAuth 2.0是个全新的协议,并且不对之前的版本做向后兼容,然而,OAuth 2.0保留了与之前版本OAuth相同的整体架构。
这个草案是围绕着OAuth2.0的需求和目标,历经了长达一年的讨论,讨论的参与者来自业界的各个知名公司,包括Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google。
OAuth has long been the poster-child of rapid open technology adoption, and 2.0 is no exception – Facebook and Twitter already announced support even before the first draft was officially published.
OAuth长期以来都被视为快速开放技术的典范,OAuth 2.0也不例外。Facebook和Twitter甚至已经宣布在官方发布第一个草案前的就会开始支持OAuth 2.0。
[本人注:事实上已经有支持OAuth 2.0的产品了,服务器端包括facebook的Graph Api,客户端方面,苹果的iPhone和iPad上也已经有具体实现了]
为什么需要新版本
OAuth 1.0的实现主要是基于两个私有的协议:Flickr的 API Auth和Google的AuthSub,因此OAuth是根据具体的实现经验而产生的最佳解决方案。
OAuth面世三年以来,业界积累了无数的基于此协议的实际开发经验,社区积累的经验和知识也足矣重新思考和改进协议,这主要集中在OAuth1.0支持度不够并且会让人困惑的三个方面。
这三方面内容分别是:
1.Authentication and Signatures
2.User Experience and Alternative Token Issuance Options
3.Performance at Scale
[本人注:对于这三个方面,除了Flow的基本思路没提到,不就几乎是OAuth的全部关键点了?]
下面分别对这三个方面进行阐述:
1.Authentication and Signatures
大多数尝试实现OAuth而失败的原因是由于协议规格书中加密需求太过复杂。事实上,初始版本的协议书对此方面的书写非常简陋,帮助不大,即使发布为RFC 5849上的正式版本也是如此。
仅仅使用密码这种方便而简单地方式在OAuth中也是非常缺少的。
举个例子:
开发人员可以可以快速的写出Twitter脚本,并且通过他们的用户名和密码做一些非常实用的操作。而当这些应用迁移到OAuth的方式去做,他们不得不去寻找,安装,配置lib才能完成原先只需写一行脚本就能完成的工作。
2.User Experience and Alternative Token Issuance Options
OAuth主要包括两个方面,通过用户允许的授权方式获取token,使用token获取受保护的资源。
获取access token的方法被称作流程。
OAuth 1.0起初定义了三种流程:基于web的应用程序,桌面客户端,手机等其他设备。然而,随着规范的确立,这三种流程合并成了一种,换句话说,本来应该有所区分的三种不同客户端的流程,最终走的都是一个流程。然而,经过三年的实践,这个流程只在基于web的应用程序时表现出色,对于其他客户端,使用此流程的体验非常差。
随着越来越多的开始使用OAuth,特别对于Twitter,开发人员意识到,OAuth提供的单一流程非常非常受限并且用户体验低劣。另一方面,Facebook的connect提供了一系列的流程来适合不同的客户端,如web程序,移动设备或者游戏主机等。
3.Performance at Scale
随着大型的服务提供商开始使用OAuth,社区意识到协议的扩展性不够好,在OAuth的任何一个步骤,都需要状态管理,临时的身份凭据通常丢弃不用,但是更典型的需求是产生生命期很长的身份凭据,这些身份认证需要保存(安全性差,难以管理,需要在数据中心间同步)。
此外,OAuth 1.0需要受保护资源的endpoint(Data server)访问客户的身份凭据从而验证request的有效性,这将破坏大部分大部分大型服务提供商的架构,即CAS集中认证server(centralized authorization server)来发行身份凭据证,其他单独的server用来处理API call。OAuth 1.0 需要使用者两种身份凭据,客户端的身份凭据和token的身份凭据,将此两者分开将非常困难。
OAuth 2.0的新特性:

6种全新的流程:
User-Agent Flow – 客户端运行于用户代理内(典型如web浏览器)。
Web Server Flow – 客户端是web服务器程序的一部分,通过http request接入,这是OAuth 1.0提供的流程的简化版本。
Device Flow – 适用于客户端在受限设备上执行操作,但是终端用户单独接入另一台电脑或者设备的浏览器
Username and Password Flow – 这个流程的应用场景是,用户信任客户端处理身份凭据,但是仍然不希望客户端储存他们的用户名和密码,这个流程仅在用户高度信任客户端时才适用。
Client Credentials Flow – 客户端适用它的身份凭据去获取access token,这个流程支持2-legged OAuth的场景。
Assertion Flow – 客户端用assertion去换取access token,比如SAML assertion。
可以通过使用以上的多种流程实现Native应用程序对OAuth的支持(程序运行于桌面操作系统或移动折本)
application support (applications running on a desktop or mobile device) can be implemented using many of the flows above.
持信人token OAuth 2.0 提供一种无需加密的认证方式,此方式是基于现存的cookie验证架构,token本身将自己作为secret,通过HTTPS发送,从而替换了通过HMAC和token secret加密并发送的方式,这将允许使用cURL发起APIcall和其他简单的脚本工具而不需遵循原先的request方式并进行签名。
签名简化:
对于签名的支持,签名机制大大简化,不需要特殊的解析处理,编码,和对参数进行排序。使用一个secret替代原先的两个secret。
短期token和长效的身份凭据
原先的OAuth,会发行一个有效期非常长的token(典型的是一年有效期或者无有效期限制),在OAuth 2.0中,server将发行一个短有效期的access token和长生命期的refresh token。这将允许客户端无需用户再次操作而获取一个新的access token,并且也限制了access token的有效期。

角色分开
OAuth 2.0将分为两个角色:
Authorization server负责获取用户的授权并且发布token。
Resource负责处理API calls
OAuth 2.0何时发布
OAuth 2.0 目前正由IETF的OAuth工作组制定中,最新的草案已经稳定了,但是很多特性还需修改和增加。部分可用支持在Facebook和Twitter已经可用。最终的版本可能在年底发布。

标签: