提示：这篇文章包含一些过时的或者不正确的内容。最新的更新，可以访问这里：The Authoritative Guide to OAuth 1.0[①]。
OAuth昨晚发布了最终稿（OAuth Core 1.0 Draft 4），对不熟悉此协议的新手来说，是深入学习了解它到底能做什么的时候了。我曾经写过一篇博文来描述OAuth的历史、使用案例、什么时候可用（或者不可用）。大家似乎很喜欢仆从钥匙的比喻[②]，正如John Panzer复述的那样“OAuth：你在Web上的仆从钥匙”。
1. 简介
这一系列指南面向的读者是关注于实现的开发人员。其中一节以最终用户的视角分析问题[③]，我想大家在做原型、用户界面设计、最佳实践指南以及提供服务时都会遇到这个问题。为了最大限度地从这个指南中获益，请准备好相关的文档，因为我们会引用文档中的内容，本指南将会带你深入学习规范文档的内容，在必要的地方我们会标注上颜色。这个指南不能替代规范文档，也不能单独使用，因为它是不完整的。
2. 最终用户受益
OAuth允许你共享一个站点的私有资源（照片、视频、联系人列表、银行帐号）给另一个站点使用，而不用交出你的用户名和密码。有很多原因我们不能共享自己的私有凭证。把你的邮箱帐号密码交给一个社交网络站点，以便于它们可以查找你的朋友信息，就相当于在餐馆付账时把你的ATM卡和PIN密码交给服务员一样。如果有餐馆要求你提供PIN密码，那他们就可以歇业了。但是如果回到Web领域，用户共享自己的私有数据会冒很大的风险。OAuth可以拯救这一切。
无论是仆从钥匙或者ATM卡，从用户角度来看都是对OAuth很好的比喻。不用交出你的ATM卡和PIN密码，只需获得信用卡签名的授权，你就可以使用信用卡。就像用户名和密码可以提供对你私有资源的完全访问，ATM卡和PIN密码可以实现对你银行帐号的完全控制 – 而不仅仅是用来买东西[④]。但是当用签名代替PIN密码时，就只能对信用卡进行有限授权的操作。
用户不会关心协议和标准是什么 – 他们只关心更好的体验以及增强的隐私和安全策略。这正是OAuth的目标所在。随着Web服务的增多，用户希望这些服务能够协同工作来满足新的需求。没有任何一个站点可以完美地满足用户的所有需求，用户可以使用一个站点保存照片，一个存放视频，一个收发邮件等等。为了实现这种整合，一个站点需要访问另一个站点的用户资源，而这些资源经常是受保护的（家庭照片、工作文档、银行记录）。他们需要一个能进入这些站点的授权。
用户的授权一般是用户名和密码的组合。这可以是OpenID或者任何其他的凭证。但是这种授权过于强大而没有任何限制，不适合共享。而一旦共享出去就不能撤销，除非修改这个凭证，而这又会导致此授权在所有站点失效，而不仅仅在那个我们想屏蔽的站点。OAuth通过分发令牌（token）来解决这个问题。每个令牌授权在特定的时间内（比如接下来的2个小时）访问特定站点（视频编辑网站）的特定资源（自上周末以来的视频）。
和OpenID需要用户事先注册不同 – 获取OpenID标识以便登录不同站点 – OAuth对用户完全透明。很多情况下（做得正确的话），最终用户甚至不知道OAuth的存在，更不用说它是什么以及它怎么工作的。最终的用户体验取决于两个站点的实现（一个是需要访问权限的站点，另一个是存储用户资源的站点），以及需要使用的设备（Web浏览器、移动电话、PDA、机顶盒）。
规范文档提供的一个典型应用（在附录A中[⑤]）是用户打印保存在另一个站点的照片。交互的过程如下：用户登录照片打印站点并发出打印照片的指令。打印站点询问需要打印哪些照片，用户选择保存照片的网站（从打印站点提供的网站列表中选择）。打印站点把用户定向到保存照片的站点以便获取授权。在保存照片的站点用户使用用户的帐号登录，并询问用户是否允许打印站点使用她的照片。如果同意的话，用户会被重定向回到打印站点，这样打印站点就能访问她的照片了。在此过程中，用户无需将她的用户名和密码告诉打印站点。
3. 作用域
我们常说的“OAuth”其实指的是“OAuth Core 1.0”规范[⑥]。Core这个名字用来强调这仅仅是一个骨架，可以在此基础上构造其他扩展或协议。OAuth Core 1.0本身不提供很多特性，比如终端的自动发现机制、语言支持、对XML-RPC和SOAP的支持、资源访问的标准定义、OpenID的整合、全面的签名算法、以及提到OAuth讨论组的其他很多好的想法。
这是有意而为之，并且作者认为这会带来很多好处。正如名字暗示的那样，Core处理协议中最根本的方法：
q 建立一种机制，将用户名和密码转换成拥有一定权限的令牌（第6节）。
q 提供方法来保护这些令牌（第9节）。
协议本身不能提供安全和隐私保护，认识到这一点是很重要的。事实上，OAuth本身不提供隐私策略，而是依靠其他协议来完成（比如SSL）。也就是说，OAuth可以以非常安全的方式实现，并且在处理敏感资源时，规范本身提供了很多安全方面的考虑。正如使用用户名和密码来获取访问权限一样，站点使用令牌和密钥（secrets）来获取资源。和密码一样，密钥必须确保安全[⑦]。
4. 规范文档的结果
这一节不翻译了。因为这里描述的文档比较老，最新的文档可以到http://oauth.org/下载。
5. 定义
第3节对协议中使用的基本概念的名字进行了定义。理解这些名词将有助于学习OAuth，这里对它们进行解释如下：
q 服务提供商（Service Provider） – 服务提供商控制了OAuth实现的各个方面。服务提供商用来描述那些拥有受限访问资源的站点或者Web服务。服务提供商可以是照片分享网站（用户存放相册的地方）、在线银行服务、微博站点或者保存用户私有数据的其他服务。OAuth不强制要求服务提供商也必须是身份认证提供商，这意味着服务提供商可以使用自己的用户名密码认证体系，也可以使用其他的认证系统比如OpenID。
q 用户（User） – 用户是OAuth存在的意义，没有用户就没有OAuth存在的必要。用户拥有在服务提供商那里保存的私有数据，并且他们希望和其他网站共享这些数据。OAuth确保必须在征得用户同意（至少一次[⑧]）后才能拥有这些私有数据的授权。
q 消费者（Consumer）- 这是一个很潮的名字，用来描述希望获取用户资源的应用。它可以是个网站、桌面应用、移动设备、机顶盒或者任何联网的设备。消费者可以从用户那里获取对资源的授权，这也正是OAuth中真正有意思的地方。OAuth定义了“Consumer Developer”这个名字，因为正是他们编程实现与服务提供商的交互过程。“Consumer Key”和“Consumer Secret[⑨]”会在后面描述。
q 受保护的资源（Protected Resources） – OAuth保护并授权访问的东西。它可以是数据（图片、文档、通讯录）、事件（发表博文、转账）或者任何有访问限制的URL。
q 令牌（Tokens）- 用来代替用户凭证来访问资源。令牌一般是字母和数字（不限于）组成的随机字符串，它是唯一的，难于猜测的，通过密钥来保护它不被篡改。OAuth定义了两种类型的令牌：请求令牌和访问令牌。我们会在后面详细介绍。
[①] 虽然这篇文章比较老了，是作者07年10月份完成的，但是对于初学者理解OAuth的基本概念非常有用，所有就有了这篇译文 ---译者注
[②] 仆从钥匙相对于主人的钥匙有更对的限制，比如仆从钥匙不能打开主人家的保险柜，这里采用的是比喻义 ---译者注
[③] 这里指的是第二节，通过用户视角来说明OAuth的流程 ---译者注
[④] 可以用来转账、修改密码甚至注销银行卡 ---译者注
[⑤] 在最终的RFC5849中，这个应用在1.2节中描述，而不是附录。本文参考的版本比较老 ---译者注
[⑥] 这个已经被声明废弃了，最新的1.0规范是http://tools.ietf.org/html/rfc5849 ---译者注
[⑦] 这里的密钥指的是服务提供商（Service Provider）分发给消费者（Consumer）的密码，双方可以基于此对传输的数据进行验证，以防止在传输过程中被非法篡改 ---译者注
[⑧] 消费者在获取用户授权的令牌后，在一定时间内不必再次征得用户的同意就能访问用户在其他网站保存的私有资源 ---译者注
[⑨] Consumer Secret就是前面提到的密钥 ---译者注
==========