OAuth 的权限问题与信息隐忧
- - 月光博客 去年 3Q大战之后，开放几乎成为了最热的词汇，随后的国内互联网看似进入了开放平台的“蜜年”，各种基于开放平台的应用和社会化登录也随之出现. 将自身的产品和服务与大网站平台对接，不仅能省去注册等繁琐工作，不用为储存和传输大量的用户账号信息而烦恼，还可以迅速的带来流量、用户资源，并得到更好的推广.
OAuth 的权限问题与信息隐忧
标签：
oauth
问题
信息
| 发表时间：2012-04-06 17:41 | 作者：投稿 (guest)
出处：http://www.williamlong.info/
去年 3Q大战之后，开放几乎成为了最热的词汇，随后的国内互联网看似进入了开放平台的“蜜年”，各种基于开放平台的应用和社会化登录也随之出现。
将自身的产品和服务与大网站平台对接，不仅能省去注册等繁琐工作，不用为储存和传输大量的用户账号信息而烦恼，还可以迅速的带来流量、用户资源，并得到更好的推广。而对于平台来说通过 API 支持协议可以得到很多的应用接入，可以为用户提供更多更好的服务。这对开发者和平台提供商来说是双赢的局面。因此，QQ 登录、各种微博登录和 SNS 登陆也似乎成为了第三方网站或应用的必备按钮。（在昨天腾讯宣布其 QQ登录已经成为国内最大第三方帐号登录体系。）
本来利用已有的账号登陆这些第三方网站和应用是一件好的事情，因为从体验上来说可以方便用户，但是国内这些“一键登陆”真的是用户想的那样“一键登陆”吗？我们看到一个网站就用我们的账号登陆难道没有隐患吗？ 这些”登陆“的背后的关键是什么？
如果你有够细心的话会发现所有登陆基本都是弹出一个对应对话框，其地址栏中也都会包含有“OAuth”字样。这说明，其当前采用的是 OAuth 协议。在目前，无论是国外还是国内，绝大部分都是采用 OAuth 协议来完成在第三方网站或应用的登陆的。
OAuth 是什么？它有什么优点呢？为什么都采用 OAuth？
OAuth（开放授权）是一个开放标准 ，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。via 维基百科
OAuth 的优点
OAuth 不会使第三方网站或应用接触到用户的帐号信息（如用户名与密码），授权后的 http 通信中也不再传输用户信息而是以数字签名和访问令牌（Access Token）取代，即使截到数据包，也无法还原出用户的登录信息。这是OAuth 最大的优点，也是它得以逐渐成为现在通用的授权标准的原因。
OAuth 被普及的原因
对用户来说方便、安全；对中小第三方网站和应用来说，OAuth 可以使它们能够得到用户基本信息外的其他信息资料和账户部分使用权限；对大网站平台来说，OAuth 可以完美的解决用户的账户安全和开发者授权的平衡问题。因此 OAuth 协议确定后就获得了包括国外 Twitter、Facebook 和 Google 等认可，之后在国内也得到了有效跟进。
OAuth 授权的信息隐患
凡是只有其利就有其弊，OAuth 也不例外。为什么在安全上看似完美无缺的 OAuth 都有信息隐患呢？
1. 被滥用了的 OAuth 授权
OAuth 是一个授权（authorization）协议而不是认证（authentication）协议，因此，对于 OAuth 来说最大的信息隐患就是其本身。
OAuth 提供的是权限分配而非认证。在国内大多数网站的一键登陆根本没有去区分认证和授权 ，全部混淆为授权。本身用类似 OpenID 的简单认证即可完成的事情却非要走授权。而一键登陆在给用户带来便利的同时也带来了另一个弊端：用户变得越来越不在意自己的账号。因为 OAuth 协议本身的安全给了我们一种假象：别人获取不到我的账号密码，所以我的账户很安全。我们要明白，授权本身的实质相当于系统为第三方网站/应用开了一个后门，而你的授权就是允许它们可以走后门进来获取你的隐私资料和使用权限。
打个比方就是，虽然它们不知道你家的锁长什么样，也没有你家的钥匙，但是人家就是能进得去你家，还可以看你家的电话簿，用你家的电话给你的亲朋好友打电话等。很多其实扮演的只是抄水表的角色，在门外瞅一眼即可，但是偏偏国内那些平台们把水表安到了你家里面，这样很多抄水表的就可以打着抄水表的借口从后门去你家向你的亲朋好友宣传它水表抄的好，想继续去你亲朋好友家抄水表。
譬如一些小游戏和星座信息之类的第三方网站和应用，无一例外都会要求我们授权给它们我们的好友关系、生日、相册、评论、甚至地理信息位置。对于我们来说，个人信息的安全不仅仅是我们的用户名和密码，那些“被授权”的都是信息安全的一部分，甚至是最重要的部分。前几天通过 QQ 圈子我们也了解到了这些信息有多重要。
你授权的网站/应用越多，意味着越多的网站和应用能够接触到你的账户资料并拥有部分使用权限，也意味着隐患越多。虽然它们并没有获取到的你的账户密码，虽然你之后从未登陆过或使用过它们，但是，除非你去隐藏很深的后台设置里面取消它们的权限，否则它们是一直能够接触到你的账户资料并拥有你账户的部分使用权限的。
某种程度上说，OAuth 对我们个人信息安全来说是一扇隐形的窗户，而且这个窗户还是默认永久开放的。
2. OAuth 使用的不规范
在很多时候，出问题的环节往往不是技术，而是背后使用技术的人。
1. 平台 OAuth 部署不规范
OAuth 部署是否规范，例如有无强制使用 https 加密，有无强制部署 OAuth 2.0。对移动应用的授权有无注意应用会自建浏览器，有无注意在信息回传过程中的信息防护，这些都是需要考据的问题。OAuth 协议本身没有问题，但是对协议的用途是否规范值得商榷。
事实上，各开放平台之间的技术差异很大，因此每个平台使用并不是相同版本的协议，有 OAuth 1.0、OAuth 2.0 或混合的技术体系（甚至还有继续使用不安全的 Basic Auth）。此外，如果你去翻看一下国内各个开放平台的开发文档就会发现，虽然 OAuth 整体流程大致类似，但是对于授权的定义各家有各家的标准，对待开发者的态度各不相同，对授权的限制也是各家有各家的标准 ，对用户的账号保护也是各有各的说法。
例如某家开发平台上对待涉及自身利益的时候用“严禁”“禁止”字眼，而涉及用户账号利益的时候就变成了“不应”、“不鼓励” 等字样。再例如，对未审核应用、待审核应用和未通过审核应用的限制，国内只有两家平台对使用人数进行限制外，其他各家都只是稍微限制了一下调用频率次数和不显示来源而已。
综合来看，国内的关于OAuth协议标准的实施部署是一个开发者和平台综合博弈的结果。
2. 应用开发者不自律
OAuth 的安全性相当一部分需要依靠应用开发者的高度自律，不该有的权限不去申请，但是事实并非如此。正常情况下，平时我们所用的 90% 的应用只需用只读权限即可，但是相反的是，只有 5% 的应用只拥有只读权限。对于开发者开说，尽量获取到用户账户的使用权限似乎是一种”追求“，而不管用不用得到。这不仅让人想起了 Android 移动应用上的普遍高权限。
3. 平台审核是否仔细
第三方网站或应用要接入平台需要通过平台的审核，审核是一层对开发者的把关。因为平台竞争的原因，各家审核标准并不一致，实际操作更是谁也不清楚。总体来看，强势的平台限制严格，弱势的平台因为要吸引开发者所以很多事情睁一只眼闭一只眼。
4. 用户对 OAuth 的不设防
OAuth 协议的实施很类似微软平台下软件的安装，用户经常在一步步的点击中默认”被授权“，因为国内大多数用户暂时还没有注意防护自己账户信息和权限的习惯。
我们该注意些什么？该怎么做？
1. 防止 OAuth 钓鱼登陆界面
注意观察弹出窗口是否为官方登陆域名，要谨防假冒钓鱼。
2. 授权之前的三思
在你将自己的账号权限授权给一个应用之前，先查清楚应用开发者的具体信息和他们的隐私保护条款，知道自己到底授权给了谁，到底给谁授予了哪些权限。
3. 定时清理你的第三方应用授权
要注意清理你的第三方应用授权，将那些无关紧要的或已经不再使用的第三方网站或应用取消授权，关上那扇隐形的窗户。
4.授权后注意其来源
授权第三方网站或应用后要注意查看其有没有通过官方平台的审核，如果来源显示来自”未审核应用“或类似字样后尽量先取消其授权，待审核通过后再进行授权。
未来，国内应该分区开认证和授权，给用户减少不必要的隐患，期待国内出现一个统一的OpenID（不像国外 OpenID 那样繁琐，或许类似 BrowserID 的东西），而不像现在，虽然号称一键登陆，但实际上许多第三方网站/应用在用户授权登录后，依旧有二次登录或重新注册等操作。
虽然目前这些隐患只是表现为偶尔的偷偷关注或偷偷以用户账号发一些广告，并没有爆发出严重的事件。但是想想那么多隐私信息和部分权限控制在那么多的第三方应用或平台上就有点不寒而栗的感觉。
服务的整合本来是大势所趋，也是未来方向，但是国内这些将认证和授权混为一谈的做法使得我们不仅没有更使得我们可以更方便更安全更省事的去管理，去获得服务，反而使我们的账户更加混乱，更埋下了信息安全的隐患。对此我们一定要提高警惕。
后记：在国外 OAuth 也没有太多安全可言，最近两天一个名为reference.me的社交服务就在滥用OAuth 协议，用户只要用 Google 账户授权登录就会自动向所有联系人发送邀请邮件，大家要注意。
来源：Afio投稿， 原文链接。
相关文章:
微博： 新浪微博 - 腾讯微博 - 论坛
月光博客投稿信箱：williamlong.info(at)gmail.com
Created by William Long www.williamlong.info
相关 [oauth 问题 信息] 推荐：
OAuth的改变
- lyxint - 火丁笔记去年我写过一篇《OAuth那些事儿》，对OAuth做了一些简单扼要的介绍，今天我打算写一些细节，以阐明OAuth如何从1.0改变成1.0a，继而改变成2.0的. 在OAuth诞生前，Web安全方面的标准协议只有OpenID，不过它关注的是验证，即WHO的问题，而不是授权，即WHAT的问题. 好在FlickrAuth和GoogleAuthSub等私有协议在授权方面做了不少有益的尝试，从而为OAuth的诞生奠定了基础.
理解OAuth 2.0
- - 阮一峰的网络日志OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版. 本文对OAuth 2.0的设计思路和运行流程，做一个简明通俗的解释，主要参考材料为 RFC 6749. 为了理解OAuth的适用场合，让我举一个假设的例子. 有一个"云冲印"的网站，可以将用户储存在Google的照片，冲印出来.
oauth 认证心得
- 非狐外传 - python.cn(jobs, news)OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准. 简易来说，就是我们可以在某一个第三方服务器,如:新浪，豆瓣，在用户授权，并且不透漏密码等信息给我们的条件下，访问和修改用户的资源. oauth的项目主页为:http://oauth.net/ ，现在国内很多网站的开放平台都采用了Oauth方式来进行授权.
OAuth学习笔记
- 宋大妈 - FeedzShare来自: 标点符 - FeedzShare . 发布时间:2011年08月29日, 已有 2 人推荐. OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用. OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据.
OAuth 2.0 工作流程
- - 企业架构 - ITeye博客原文链接：http://www-01.ibm.com/support/knowledgecenter/SSELE6_8.0.0.3/com.ibm.ammob.doc_8.0.0.3/config/concept/con_oauth20_workflow.html%23con_oauth20_workflow?lang=zh.
基于PECL OAuth打造微博应用
- lostsnow - 火丁笔记最近，国内主要门户网站相继开放了微博平台，对开发者而言这无疑是个利好消息，不过在实际使用中却发现平台质量良莠不齐，有很多不完善的地方，就拿PHP版SDK来说吧，多半都是用TwitterOAuth改的，一旦多平台集成，很容易出现命名冲突之类的问题. 既然官方SDK不给力，那我们只能发扬自力更生的革命精神了.
纯 JavaScript 实现的 OAuth 认证
- - 博客 - 伯乐在线英文原文： JavaScript oAuth 编译： oschina. 现在，很多的应用程序都在使用HTML和JavaScript, 这是一个非常明智的选择,让你跟上目前的趋势. 一些主要实体工具因为客户端验证和授权等原因提供了API. 当前网站对于验证的一个广受欢迎的功能是”单点登录”. 这让用户可以通过其它一些社交媒体网站上的身份认证直接登录你的网站.