Oauth那些事
2013-03-14 13:43
113 查看
英国诗人蒲柏在牛顿的墓志铭中写道:『自然和自然的法则在黑暗中隐藏,上帝说,让牛顿去吧,于是一切都被照亮!』,而在保护账号安全方面,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基本等价于账号和密码的作用。
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去吧,于是一切都被照亮!』,不过这可不是墓志铭
。
BTW:关于OAuth详细的介绍可以参考Beginner’s Guide to 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基本等价于账号和密码的作用。
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去吧,于是一切都被照亮!』,不过这可不是墓志铭
。
BTW:关于OAuth详细的介绍可以参考Beginner’s Guide to OAuth。
相关文章推荐
- 关于Oauth认证的那些事
- 产品新版本发布前要做那些事呢
- OAuth2 通用组件源码下载(支持新浪微博、QQ、淘宝)(转载)
- php oauth 模块在linux下安装
- 关于打开游标的那些事
- Oauth笔记
- [置顶] 考研那些事——那些年,我们一起度过的猪狗不如的生活
- 清明雨后的那些事
- 妙味云课堂之css:兼容的那些事
- 回车键默认提交表单的那些事
- IOS didReceiveMemoryWarning 的那些事
- OAuth认证协议原理分析及使用方法
- 微博阅读器demo(一)OAuth 2.0 认证
- UIWebView与js那些事
- c的那些事
- 关于睡眠健康那些事
- OAuth 2.0系列教程
- Asp.Net MVC 4 Web API 中的安全认证-使用OAuth
- 【C++ STL】细数C++ STL 的那些事---List(双向链表)
- 【144】重装系统那些事