Seven Two Blog

（一）背景知识 OAuth 2.0很可能是下一代的“用户验证和授权”标准，目前在国内还没有很靠谱的技术资料。为了弘扬“开放精神”，让业内的人更容易理解“开放平台”相关技术，进而长远地促进国内开放平台领域的发展，笔者特意将OAuth 2.0协议翻译成中文。 目前OAuth 2.0还没有最后定稿，最新的修改版是第11个版本，本文下面的翻译即基于这个第11版本。原文见http://tools.ietf.org/html/draft-ietf-oauth-v2-11。 关于OAuth 2.0的更多背景知识，请参考我的另一篇文章：http://itgeeker.com/mathml/readpaper?pid=65 （二）术语中英对照表 由于OAuth协议版本较多（1.0,1.0a,2.0等），并且各个版本中的技术术语也各不相同，关于英文技术术语与中文的对应关系，我们以OAuth 2.0的第11版本中的描述为准。 另 外有一些情况，一些英文术语不容易找到普遍接受的汉语释义，翻译过来反而可能引起误解，而英文术语本身可能更容易理解，因此就不考虑对这部分词汇做翻译 了。比如，“web service”、“endpoint”、“user-agent”、“URI”、“cookie”等，你只需要知道它是什么就好了。 还有一些特别难于翻译的词汇，比如“profile”，这个词用在协议里，大概表示：协议功能的某个剖面、子集、子视图或轮廓。如果翻译成“视图”，容易让人想到“view”这个词，产生冲突，最后，我在这里创造了一个新词汇：“子态”。

前言： 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 [...]

终端用户在使用第三方软件访问用户受保护的资源时，都需要终端用户授权给第三方软件。如用户在使用第三方软件需要访问或者操作用户在Google上注册的服务（Gmail服务，Calendar服务等）时，就需要用户将相关资源的权限授权给该软件。Google除了提供了很多个性化的服务外，同时提供了一套完整的服务授权体系。Google的服务认证体系包含了多种认证授权的方式，如AuthSub授权认证服务、OAUTH授权认证服务与ClientLogin授权认证服务等。软件开发商可以根据自己软件的特点来选择合适的认证方式。本文将简要的介绍这三种认证服务。 一、Google授权认证体系 Google的服务认证体系包含了多种认证授权的方式，到目前为止，Google提供了以下四种授权认证方式：AuthSub授权认证服务、OAUTH授权认证服务、ClientLogin授权认证服务与Gadgets授权认证服务等(ref:http://code.google.com/intl/zh-CN/apis/gdata/auth.html)。如下图所示： 软件开发商可以根据自己软件的类型来选择合适的认证方式。如果你的软件是单机版的应用（如单机版的桌面应用）时，你应该选择ClientLogin授权认证服务；如果你的软件是基于BS多用户使用的WEB应用时，你可以考虑选择AuthSub授权认证服务或者OAUTH授权认证服务；如果你的应用是小工具（小工具是简单的HTML和JavaScript应用程序，可以嵌入到网页中或其他应用程序中，比如为iGoogle或者Open Social容器开发的小工具）类型的软件时，就应该是用Gadgets授权认证服务。 在对Google Open API授权认证体系有了基本了解后，我们就逐一认识下每种授权认证方式的业务流程。

在前面已经介绍过 OAuth 与 OpenID ，这两种服务，Google都实现了。我们可以通过Google OAuth服务为Google 用户的资源进行授权，如用户通过第三方软件调用Google Open API操作用户的资源时，就需要用户对第三方软件授权；通过Google OpenID服务可以打通Google与其他支持OpenID服务网站之间的用户体系。现在假如有另外一个网站，也想开放自己的Open API服务，但是又不想实现OAuth服务（毕竟实现OAUTH服务还是需要一些成本的），那该怎么办？它可不可以使用Google提供的OAuth服务，授权认证交给Google来处理？可以！但是OAuth授权也是基于用户登录来实现的，Google OAuth用户体系只是Google的用户体系，那又怎么办了？OpenID！对，将网站的用户体系与Google用户体系打通，并且使用Google OAuth服务来实现授权，即Google提出的OpenID + OAUTH的解决方案。 一、 OAUTH 与 OpenID 前面两篇文章对 OAuth 与 OpenID 均做过介绍，且Google均提供了这两种服务，在此我们先简要的回顾这两种服务，具体介绍请参见相关文章。 OAUTH是一种开放的，基于用户登录的授权认证方式。如当用户使用第三方软件调用Google Open API去操作自己的Google服务资源时，用户就要先对该软件授权。授权过程中，第三方软件会引导用户登录Google，进行用户鉴权，用户通过Google身份鉴权后才能对第三方软件授权。显然，Google OAUTH只能对Google用户进行鉴权，其他用户体系的用户不能直接鉴权。 OpenID是一种开放的，去用户中心的，用于打通各网站之间的用户体系的服务。在支持OpenID的网站间，你可以使用任何一个网站的帐号或者Open ID去登录任何一个网站。OpenID提供了类似单点登录的用户体验，并且用户无需在各个网站上注册就可以使用该网站的资源，将用户从繁重的帐号注册与管理工作中解脱出来。当用户使用OpenID登录没注册的网站过程中，网站会引导用户登录OP（用户OpenID注册的网站），请求OP对用户身份鉴权，用户通过OP鉴权，网站才会容许用户登录。

也许大家都有这样的经历与烦恼：当你为了使用某个网站的服务时（若你还没在该网站上注册过），你不得不先注册一个帐号。当你在一堆的网站上注册帐号后，你必需面临管理这些帐号的烦恼。也许你会这样考虑，不同网站注册的帐号信息都用同一个用户名与密码，这样也许会减轻你的烦恼，但是却给你带来的安全隐患，一旦你的帐号在某个网站泄漏后。OpenID正式基于解决这类问题而提出的一个国际标准，用于打通各大网站之间的用户体系。你可以使用某一网站的帐号去登录另一网站，只要这些网站都是实现了OpenID的服务。目前Google，Yahoo，Flickr，AOL等都支持OpenId服务。2009年2月初，Facebook也宣布加入OpenId基金会。 一、OpenID简介 OpenID官方网站http://openid.net首页对OpenID的介绍如下：OpenID is a free and easy way to use a single digital identity across the Internet. With one OpenID you can login to all your favorite websites and forget about online paperwork! 其大概意思就是说：OpenID是一个单一的、免费的数字身份标识，使用它，你就可以登录你经常登录的网站。

OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。同时，任何第三方都可以使用OAUTH认证服务，任何服务提供商都可以实现自身的OAUTH认证服务，因而OAUTH是开放的。业界提供了OAUTH的多种实现如PHP，JavaScript，Java，Ruby等各种语言开发包，大大节约了程序员的时间，因而OAUTH是简易的。目前互联网很多服务如Open API，很多大头公司如Google，Yahoo，Microsoft等都提供了OAUTH认证服务，这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。 一、OAUTH产生的背景 典型案例：如果一个用户拥有两项服务：一项服务是图片在线存储服务A，另一个是图片在线打印服务B。如下图所示。由于服务A与服务B是由两家不同的服务提供商提供的，所以用户在这两家服务提供商的网站上各自注册了两个用户，假设这两个用户名各不相同，密码也各不相同。当用户要使用服务B打印存储在服务A上的图片时，用户该如何处理？法一：用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印，这种方式安全但处理比较繁琐，效率低下；法二：用户将在服务A上注册的用户名与密码提供给服务B，服务B使用用户的帐号再去服务A处下载待打印的图片，这种方式效率是提高了，但是安全性大大降低了，服务B可以使用用户的用户名与密码去服务A上查看甚至篡改用户的资源。