英国诗人蒲柏在牛顿的墓志铭中写道：“自然和自然的法则在黑暗中隐藏，上帝说，让牛顿去吧，于是一切都被照亮！”，而在保护账号安全方面，OAuth起着如同牛顿般中流砥柱的作用，为什么这么说呢？先让我们看一个例子：

    人人网提供了导入MSN联系人的功能，但前提是用户必须提供账号密码，如下图所示：

    人人网信誓旦旦的宣称不会记录你的密码，它甚至提供了一个所谓保证账号安全的方法：先改密码再导入，成功后再改为原密码。不过这样做就安全了么？

什么是OAuth

    如今很多网站的功能都强调彼此间的交互，因此我们需要一种简单，标准的解决方案来安全的完成应用的授权，于是，OAuth应运而生，看看官网对其的定义：

    An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.

    一个典型的OAuth应用通常包括三种角色，分别是：

Consumer：消费方Service Provider：服务提供者User：用户

    用户好理解，不必多言，消费方和服务提供者则需要解释一下，举例来说：假设我们做了一个SNS，它有一个功能，可以让会员把他们在Google上的联系人导入到SNS上，那么此时的消费方就是SNS，而服务提供者则是Google。

    注：Google APIs支持OAuth。

    消费方如果想使用服务提供者的OAuth功能，通常需要先申请两样东西：

Consumer KeyConsumer Secret

    当消费方生成签名的时候，会用到它们。

    一个典型的OAuth流程通常如下图所示：

A：消费方请求Request TokenB：服务提供者授权Request TokenC：消费方定向用户到服务提供者D：获得用户授权后，服务提供者定向用户到消费方E：消费方请求Access TokenF：服务提供者授权Access TokenG：消费方访问受保护的资源

    基本就是用Request Token换取Access Token的过程。这里需要注意的是，对服务提供者而言，Request Token和Access Token的生命周期不一样，通常，Request Token的生命周期很短，一般在一个小时以内，这样相对安全一些；而Access Token的生命周期很长，往往是无限，如此一来，消费方就可以把它保存起来，以后的操作就无需用户再授权了，即便用户修改账号密码，也不会受影响，当然，用户可以废除消费方的授权。

有腿的OAuth

    我们前面描述的OAuth，被称为三条腿的OAuth（3-Legged OAuth），这也是OAuth的标准版本。这里所谓的“三条腿”，指的是授权过程中涉及前面提到的三种角色，也就是：消费方，服务提供者，用户。不过有些情况下，不需要用户的参与，此时就产生了一个变体，被称作两条腿的OAuth（2-Legged OAuth），一般来说，访问私有数据的应用需要三条腿的OAuth，访问公共数据的应用需要两条腿的OAuth。

    两条腿的OAuth和三条腿的OAuth相比，因为没有用户的参与，所以在流程中就不会涉及用户授权的环节，也就不需要使用Token，而主要是通过Consumer Key和Consumer Secret来完成签名的，此时的Consumer Key和Consumer Secret基本等价于账号和密码的作用。

OAuth简史

    2007年12月4日发布了OAuth Core 1.0：

    此版本的协议存在严重的安全漏洞：OAuth Security Advisory: 2009.1，更详细的介绍可以参考：Explaining the OAuth Session Fixation Attack。

    2009年6月24日发布了OAuth Core 1.0 Revision A：

    此版本的协议修复了前一版本的安全漏洞，并成为RFC5849，我们现在使用的OAuth版本多半都是以此版本为基础。

    OAuth的未来：OAuth 2.0 Working Draft，…

OAuth和OpenID的区别

    OAuth关注的是authorization；而OpenID侧重的是authentication。从表面上看，这两个英文单词很容易混淆，但实际上，它们的含义有本质的区别：

authorization: n. 授权，认可；批准，委任authentication: n. 证明；鉴定；证实

    OAuth关注的是授权，即：“用户能做什么”；而OpenID关注的是证明，即：“用户是谁”。

    如果混淆了OAuth和OpenID的含义，后果很严重。以国内某网站开发的应用为例：它的功能是通过OAuth授权让新浪微博和豆瓣的用户使用各自的身份发表评论，如下图所示：

    此类应用属于身份证明问题，本应该通过OpenID来实现，但因为错误的使用了OAuth，从而带来安全隐患：设想一下用户只是在网站上发表了评论而已，但却赋予了网站随意操作自己私有数据的权利！这就好比：快递员送包裹，为了证明收件人的身份，原本你只要给他看一下身份证即可，可你却把防盗门钥匙都给他了！Oh，My God！

    收工！作为首尾呼应的结束语，请允许我套用蒲柏的话：“账号和账号的安全在黑暗中隐藏，上帝说：让OAuth去吧，于是一切都被照亮！”，不过这可不是墓志铭 。

    BTW：关于OAuth详细的介绍可以参考Beginner’s Guide to OAuth。

建议继续学习：

1. 新浪微博OAuth认证流程分析    (阅读：3951)
2. 基于PECL OAuth打造微博应用    (阅读：3840)
3. 深入理解OAuth与豆瓣OAuth test    (阅读：3688)
4. PHP for Twitter OAuth 教学演示    (阅读：3414)
5. 在sae中利用SaeFetchurl进行豆瓣的OAuth授权    (阅读：3355)
6. OAuth 1.0a与1.0协议的改进…    (阅读：2849)
7. 新浪微博 Android SDK中OAuth2.0隐式授权部分的一个代码逻辑问题    (阅读：2362)
8. [演讲稿]OAuth1.0协议    (阅读：2363)
9. OAuth的改变    (阅读：2273)
10. 简述 OAuth 2.0 的运作流程    (阅读：2284)