OAuth那些事儿

    英国诗人蒲柏在牛顿的墓志铭中写道：“自然和自然的法则在黑暗中隐藏，上帝说，让牛顿去吧，于是一切都被照亮！”，而在保护账号安全方面，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。