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 的东西)，而不像现在，虽然号称一键登陆，但实际上许多第三方网站/应用在用户授权登录后，依旧有二次登录或重新注册等操作。
虽然目前这些隐患只是表现为偶尔的偷偷关注或偷偷以用户账号发一些广告，并没有爆发出严重的事件。但是想想那么多隐私信息和部分权限控制在那么多的第三方应用或平台上就有点不寒而栗的感觉。
服务的整合本来是大势所趋，也是未来方向，但是国内这些将认证和授权混为一谈的做法使得我们不仅没有更使得我们可以更方便更安全更省事的去管理，去获得服务，反而使我们的账户更加混乱，更埋下了信息安全的隐患。对此我们一定要提高警惕。
(责任编辑：)
