前言：在微信小程序后台发现陌生第三方服务商握着15项授权权限？本文带你分清公众平台、开放平台与开发者平台的分工，讲透绑定关系与授权关系的本质区别，解析OAuth2.0授权机制与authorizer_access_token原理，并给出自查授权列表、收权解绑的实操方法，帮你把小程序权限牢牢握回自己手里。
我在自己的小程序后台，发现一个陌生名字拿着我15项权限
前两天，我干了一件所有做小程序的人都该干、但大概率从来没干过的事。
我把微信的三个后台，挨个翻了一遍。
起因特别简单。那天我在微信开发者平台闲逛，就是那个 developers.weixin.qq.com，点开自己一个小程序的授权关系页面，然后看到一个名字。
星零云。
一个我完全没印象的服务商，安安静静躺在我的授权列表里，手里握着15项权限。获取小程序码、开发与数据分析、客服管理、开放平台账号管理、基本信息管理……一条一条列在那，跟一份不动声色的权力清单似的。
我盯着屏幕看了半天。。。第一反应是？？？
我什么时候授权的？它能拿我的小程序干什么？它会不会正在替我干一些我不知道的事？
坦率的讲，那一刻我的心情，一半是警惕，一半是兴奋。警惕的是权限给出去了，兴奋的是，有东西可以查了。
于是我花了整整一个晚上，把微信的三个平台挨个翻了一遍，官方文档啃了半截，还顺手把这段历史扒了个底朝天。这篇文章，就是我这一晚上的调查报告。
先交代一下背景。做微信开发或者运营的人，这辈子躲不开三个域名。
mp.weixin.qq.com，公众平台。
open.weixin.qq.com，开放平台。
developers.weixin.qq.com，开发者平台。
三个名字长得像三兄弟，点进去是三套完全不同的逻辑。我以前也是稀里糊涂用，哪个弹二维码就扫哪个。这次认真查完才发现，这三个地方的分家史，就是一部微信生态的进化史。
先说最老的，mp，公众平台。
2012年公众号刚出来那会儿，整个微信的商业生态就这一个后台。群发图文、配菜单、看数据，全在这。后来2017年小程序横空出世，腾讯为了复用这套已经跑熟的商户体系，直接把小程序塞进了mp。所以直到今天，你提审小程序版本、改名字头像、看用户数据，还是得去这个最早为写文章设计的地方。
它管的是「这一个账号长什么样、发什么内容、数据好不好」。
再看open，开放平台。
大概2013年前后，外面的App和网站开始想接微信登录，这事超出了mp的管辖范围，腾讯就单开了一个open。它的核心使命一句话就能讲完，让微信之外的东西，也认得出「这是同一个用户」。
你公司如果有App、有网站、有小程序、有公众号，想拿到统一的UnionID，就必须把这些账号全绑到同一个开放平台账号下面。微盟、有赞这种代运营服务商，它们的第三方平台也是在这创建的。
它管的是「跨端怎么打通，外面的人怎么进来」。
压轴的，是developers，开发者平台。
这个最新。我查的时候发现它是微信这两年才推出来的一站式工作台，官方文档原话，「面向微信生态业务的一站式工作台」。小程序、公众号、小游戏、微信小店、移动应用、网站应用、第三方平台，全收拢到一个后台，绑定关系、授权关系、接口调用监控，一个登录态全搞定。
而且我翻文档的时候看到一个特别关键的细节，开放平台里绑定小程序、小游戏的功能，已经正式迁移到开发者平台了，文档里还写着一句，「后续更多微信能力的开放也将只在微信开发者平台上进行」。
翻译一下，open正在被慢慢搬空，未来是developers的。
那为什么不一开始就设计成一个地方呢？
我一开始也觉得这是腾讯产品经理的锅，三个后台三套登录态，谁用谁裂开。但查完历史我发现，这真不全是设计的问题，是生态长出来的形状。
微信不是规划出来的，是长出来的。2012年没人能想到会有小程序，更没人想到外面的App也想用微信登录。每多一种需求，就多打一个补丁，补丁打多了，就长成了三个平台。
这像什么，像一座老城。老城区的街道弯弯曲曲，因为它是从一个村口慢慢长出来的，不是有人拿尺子画出来的。新区横平竖直，因为画它的时候，已经知道要住多少人了。
developers，就是那个新区。
好，回到正题。三个平台的历史搞清楚了，但真正让我起鸡皮疙瘩的，是接下来这个发现。
要搞明白星零云为什么能拿着我15项权限，得先搞明白开发者平台里两个长得特别像的词。
绑定关系，和授权关系。
我一开始以为这俩是同一个东西的两种叫法，仔细一查，发现完全是两码事。而且我跟你说，这个区别值得每一个有账号的人搞清楚。
绑定关系，管的是「我是谁」。
它解决的是身份归属问题。把小程序绑到开放平台下面，是为了跟同主体的公众号、App打通UnionID，让系统认出刷小程序的人和开App的人是同一个用户。把某个微信号绑成项目成员，是给他发一张内部工牌，让他能上传代码、真机调试。公众号关联小程序，是为了在菜单和图文里能挂上它。
你会发现，绑定的对象全是「自己人」。同主体的账号，自己公司的同事，自己名下的公众号。
说到底，绑定像户口本。一家人迁到同一个本子上，为的是证明你们是一家人。
而授权关系，管的是「谁能替我做事」。
它解决的是权限委托问题，对象全是「外人」。星零云就是这么进来的，它是一个第三方服务平台，行业里管这个叫ISV。我把小程序的部分管理权限委托给它，它就能代替我去调用微信的接口，帮我做代开发、代运营。
技术上这一套就是OAuth2.0的授权机制。我作为管理员扫码同意之后，微信会向星零云颁发一个叫authorizer_access_token的凭证，之后它拿着这个token，就能合法地代表我的主体，去调那15项权限对应的接口。
注意，是15项权限「对应」的接口，不是我小程序的全部。它拿不到我的账号密码，也拿不到我没授权的能力。
这个设计我觉得特别妙。打个比方，绑定是把一家人的户口迁到一起，授权是给家政公司办一张门禁卡。卡只能开指定的几扇门，而且我随时可以单方面注销，不需要家政公司点头。
我还特意去翻了官方文档，这个token只要我不解除授权就一直有效，但我一解除，它立刻作废。主动权从头到尾都在我手里。
那星零云到底是怎么进来的？
我顺着授权记录往上扒，想起来了，之前用过一个SaaS工具帮忙搭东西，授权流程就是扫一个码，页面上列了一排权限集，我大概率是没细看就点了同意。
这事儿我一点都不意外，因为这就是绝大多数人的操作习惯。你不是安全专家，你就是一个想快点把功能跑起来的普通创业者，授权页面又长又枯燥，跟App安装时弹的权限申请一样，我非常理解直接点同意的那只手。
但这次，我把那15项权限逐条看完之后，心里反而踏实了。每一项都对应它替我干活需要的能力，没有越界的。看完之后我顺手做了个决定，把用不到的权限收掉，只留它干活必需的那几项。微信支持自定义权限集重新授权，也支持随时在后台单方面解除，几分钟的事。
写到这，我停下来想了想，觉得「绑定和授权分开」这个设计，其实是一件挺伟大的事。
在OAuth普及之前，互联网上的代运营是什么样？是把账号密码直接交给对方。你找一家公司帮你运营公众号，得把邮箱密码、后台密码全给出去。密码交出去的那一刻，你就失去了控制权，改密码是唯一的止损方式。
而授权体系把「身份」和「权限」拆开了。我不用把钥匙给你，我给你一张可以随时作废的临时通行证，你能进哪几扇门，白纸黑字写得清清楚楚。
这套思路最早来自2007年的OAuth协议，Twitter和Google那批工程师搞出来的，后来成了全互联网的标准。微信的第三方平台机制，就是这套协议在中文互联网最大规模的落地之一。
想想还挺感慨的。人类花了几千年，才在法律上把这两件事分开。律师拿着授权委托书才能替你出庭，股东签了代理权声明才能让别人替他投票。户口本证明你是谁，委托书证明谁能替你。而互联网用一套协议，把几千年的法律智慧，压缩成了几次点击。
大时代啊，朋友们。
所以，回到开头那个陌生名字。
我在自己的后台看到它，第一反应是警惕，第二反应是好奇，第三反应是把它查了个底朝天。查完之后我发现，真正的问题从来不是「星零云是谁」，而是我们绝大多数人，从来没认真看过，自己到底把权限给出去给了谁。
你的小程序、你的公众号，此刻可能正躺着一堆你忘了的授权关系，安安静静地生效着。
今晚花五分钟，去开发者平台翻一眼你的授权列表吧。看不懂的名字，逐条看看它拿着什么权限。该收的收，该解的解。
互联网时代，身份是你的。但权限，是你一点一点、亲手给出去的。
别给出去之后，就忘了。
磨平一些信息差，有时候得从自己的后台开始。
/ 注意，本项目仅在 SyncMein 的500人小群分享。
/ 谢谢你看完了我的文章，我们下次再见吧。
/ 作者：明察
/ 投稿或爆料，请联系邮箱：mingcha@gqmg.com
暂无评论内容