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

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

查找你的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 Key
• Consumer Secret

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

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

OAuth流程图

• A：消费方请求Request Token
• B：服务提供者授权Request Token
• C：消费方定向用户到服务提供者
• D：获得用户授权后，服务提供者定向用户到消费方
• E：消费方请求Access Token
• F：服务提供者授权Access Token
• G：消费方访问受保护的资源

基本就是用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相比，因为没有用户的参与，所以在流程中就不会涉及用户授权的环节，而主要是通过Consumer Key和Consumer Secret来完成签名的，此时的Consumer Key和Consumer Secret基本等价于账号和密码的作用。

补充：关于腿的解释详见The OAuth Bible

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授权让新浪微博和豆瓣的用户使用各自的身份发表评论，如下图所示：

错误的把OAuth当做OpenID使用

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

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

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