这里是小P的三省日记，从设计，产品，运营，商业等角度看问题的本质，偶尔更新，看心情，勤奋起来日更，懒惰起来季更，希望能给读者带来价值，长时间不更新还望多催促监督。
OAuth是个什么鬼东西呢？简单的说就是第三方登陆的背后的技术方案。
就是上面红圈里面这个鬼东西的技术方案
在互联网蓬勃发展，尤其是web2.0时代的到来，让各式各样的社区，网站，如雨后春笋一样蓬勃而出，网站变多，登陆和数据授权就变得越来越迫切，2007年，OAuth1.0正式发布。
受制于授权模式和技术方案，OAuth1.0有众多安全问题，而且OAuth实际上是面向web时代的一个技术方案，到了移动互联网时代已经完全不适用，尤其在安全性上面，比如在web时代，user端是有个URL概念的，看得到域名的。在安全性上面，问题没有那么大，但是在移动端，尤其是大量的App内置了一个webview，导致实际上用户使用OAuth1.0的方式授权的时候，比如使用QQ第三方登陆，跳转到一个网页，这个网页是QQ的登录界面，还是第三方恶意伪造的页面，是不知道的，这个时候就有很多安全性问题(QQ最近才开始不再支持OAuth1.0)。
直到移动互联网高速发展的前夜，2011年，OAuth2.0才正式颁布。第三方登陆迎来大发展。同时登陆意味着数据，将自己的账号体系开放出去，也能获得大量的第三方数据，同时在用户授权的情况下，可以获得很多授权网站的用户信息资源。
OAuth技术方案其实解决两个核心问题，一个是用户认证，告诉你，这个人是谁(就是赋予这个人一个唯一标识符)，一个是授权，在用户同意的情况下，给你我有的资源(昵称，手机号，身份信息等)。
OpenID其实着重在认证上面。该诉你，这个人是谁。这其实是绝大部分应用使用第三方登陆的时候的核心目的。基于这个，在技术上就可以有简化的一个接口。(所以在微信开发者文档里面，授权有两个接口，第一个接口最常用。)
1、以snsapi_base为scope发起的网页授权，是用来获取进入页面的用户的openid的，并且是静默授权并自动跳转到回调页的。用户感知的就是直接进入了回调页(往往是业务页面)2、以snsapi_userinfo为scope发起的网页授权，是用来获取用户的基本信息的。但这种授权需要用户手动同意，并且由于用户同意过，所以无须关注，就可在授权后获取该用户的基本信息。
OpenID的后背，是干掉登录
第一种，实际上是OpenID是在OAuth技术方案上面演化而来的账户体系。具体关系如下：
上面这张图里面，公众号A背后对应的是一个开发者，公众号和公众号之间的数据是不相通的，非常好地解决了隐私问题，同时，最关键的，在OAuth技术方案基础上面，提供两种接口方案，常用的第一种snsapi_base对应的接口，其实就通过静默获取的方式干掉了登录这件事。
这是天才的设计，又是微信的神来之笔，但是这个背后，其实是设计者，对于“ID”这个东西的深刻理解。
实际上，作为网络常用的通行证，邮箱是经常被使用的产品，作为很多个网站登录信息，邮箱可以说是网络“ID”的始发站。但是这个始发站，有很多实际问题，比如同一个邮箱作为登录账号，在某一个网站信息泄露，常常威胁到该用户其他网站的数据，因为用户的密码常常，很多网站都是一样的。所以，对于ID的理解上面，邮箱团队会更加深刻，思考地会更多一点。
密码学里面有很多原则和道理，就是如何增加密码复杂度来提升安全性，但其实账户安全不是技术问题，是社会学问题(这一点以后有时间会讲到)。其实最安全的方式，就是干掉登录。
现在，在微信里面的服务，基本上，登录都已经被干掉了。
2014年6月27日，微信开放新的用户登录接口内测，核心引入了UnionID机制。新机制带来的ID认知可以用下图表示：
一下子解决了开发者多个公众号开发的账户体系问题，减少了很多清洗会员数据的工作。UnionID的引入，进一步提升了微信环境下面“账户”的可用性，进一步干掉了“登录”这个动作。(在UnionID引入前，多个公众号的主体还是要通过自身的账户体系和多个公众号体系之间OpenID的映射，来打通自身在微信webview下面的账用户信息。)
在小程序时代，由于产生了新的应用体系，和原来的公众号体系完全不同，UnionID被更频繁地使用。
太方便了，但是在这里埋下了伏笔。
微信在ID的理解上面，是顶级地，能在安全的条件下面做到最方便，大大降低了开发者获取用户的门槛和成本，但是至少目前看来有两个缺陷：
Oauth技术方案，核心目的在于和第三方通信，会映射一个第三方的id和对应的OpenID绑定，API里面只有授权信息，核心在于认证和授权，所以OpenID的有效性没那么重要，但是微信环境里面不是这样的。微信的帐号生态系统里面的能力太多，还有交易和支付。
比如，当你在微信环境里面给对应的一个OpenID进行转账的时候，是不校验这个OpenID的有效性的，当这个OpenID不存在的时候，也是可以转账到零钱成功的，但是在这种海量的平台下面，会有很多开发者自己的风控不严，仰仗微信的ID体系自身的安全性，那么这种支付行为会成为一个恶意请求消耗完微信商户账户里面所有的钱。(再往深处，不能细想。)
唉，多说了，你们去翻一下抖音和微信的吵架新闻吧。“假设”抖音获得微信关系链孵化多闪APP，微信也不能大张旗鼓说抖音抓了微信关系链，因为这其实是隐私漏洞问题，FB至今还深陷剑桥分析公司的丑闻中不能自拔。
但是有一个问题是，在当前的微信生态系统下面，能不能获得微信关系链呢？
只要在微信环境里面的用户规模很大的，都可以。这里面关键在于微信环境的用户隐私策略，再朋友圈里面，只有好友可以看到自己分享的内容。怎么做到的呢？我们看一张图：
上图为基本模型，分享的文章URL只要含有用户A的识别字符串就行了，一旦B访问了A分享的链接，B就一定是A的好友，因为在微信里面，只有好友才能访问他的朋友圈，而这条内容的拥有者，比如今日头条原理上就可以知道A和B是好朋友。当用户B分享这条内容，URL里面的参数就换成B的唯一字符串就好了。
这里面关键点有两个：1、用户的OpenID是可以静默获得的；2、朋友圈只有好友可以访问，非好友不能访问。
基于上面的模型还有很多应用：
1、根据用户分享出来的URL的被访问次数，分析用户好友的关系程度。
2、根据多个用户的访问关系挖掘微信好友之间的关系。
前文讲到，UnionID有一个伏笔，就是UnionID不仅让体量大的开发者获得用户关系链，还可以让体量小的开发者通过收购合并转移公众号主体的方式获得用户关系链。
但是目前我们无法判断头条系有没有抓去微信关系链，但是抖音里面常常看到这个：
玩抖音的你，上图这个见过吧？一般情况下昵称也常常是微信昵称，一般情况下这个人启用了微信第三方登录了。
3、如何修补ID的漏洞？
第一个漏洞很容易修复，在微信支付的时候，增加有效性校验就行了，银行支付，也是有有效性校验的，如果对应的帐号或者用户不存在，是会支付失败的，主要看微信是不是愿意修复这个漏洞。
第二个漏洞，其实核心漏洞在朋友圈，在微信群是不会有这样的漏洞的，只需要修改访问渠道为朋友圈的授权规则就行了，但是所有的方案只是降低不能避免关系链泄露。
比如访问渠道为朋友圈的H5内容，强制为用户主动授权方式获取关系。来大大降低用户关系链被抓去的概率。
比如朋友圈渠道被访问的H5内容，可以静默获取UnionID，但是需要绑定一个事件，这个事件触发才可以获得对应的OpenID，这个事件，由微信定义。事件由使用次数等限制。
好长好无聊的一篇文章，唉。
点击联系发帖人
