OAuth 2.0 跟进学习: <一>OAuth 2.0概览

前言：

OAuth 1.0已经在IETF尘埃落定，编号是RFC5894

http://tools.ietf.org/html/rfc5849

这也标志这OAuth已经正式成为互联网标准协议。

 

OAuth 2.0也早已经开始讨论和建立的草案

 

OAuth在OAuth组织的主页

http://www.oauth.net/2/

 

OAuth2.0的草案

http://tools.ietf.org/html/draft-ietf-oauth-v2-05

 

协议的创始人和推动者说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.

 

学习的第一步，先看看官网推荐的入门文章

 

Eran Hammer's Introduction to OAuth 2.0

 

 

简单历史回顾

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已经可用。最终的版本可能在年底发布。