本文适合想接入第三方平台开发的同学，通过真实经验大致讲解一下相关业务，建议收藏以备不时之需。
微信开发平台实际上就是给微信外部人员提供微信能力的平台，我们可以在这个平台创建相关的应用，管理对应的认证、授权信息，然后通过开放接口对接微信提供的种种能力。
其中，账号的申请需要公司主体的相关信息。
注册账号需要邮箱（这个邮箱贼恶心，不能是微信绑定过的，也不能是公众号平台绑定的，小程序平台绑定的也不行），然后需要提供公司主体等相关的信息
主要是权限集以及开发资料
授权事件接收URL
消息与事件接收URL
消息校验Token 和 消息加解密Key
授权发起页域名
公众号开发域名
授权测试公众号/小程序列表
白名单IP地址列表
为了更好理解接入的流程，我们需要先明白几个概念
微信提供给开发者们使用的系统
微信开放平台的一个账号
属于开放平台的一种类型的应用，一个开放平台可以建五个定制化开发服务商和五个平台型服务商，一般sass模式的都是基于平台型的，像我们，我们会给开发环境，测试环境，予发布环境，生产环境各建一个第三方平台，实现资源隔离。
就是我们平常看到的公众号，本身公众号是可以自己开发能力的，但是有些企业不想重复造轮子，就会授权给其他的第三方平台来管理自己的公众号
第三方平台的唯一标识
公众号的唯一标识
每十分钟会向配置的授权事件接收URL推送aes 加密后的 ticket，作为第三方平台通讯的临时票据，服务器直接 return success 即可。
每个微信用户关注一个公众号后都会生成open-id, 它由公众号+用户微信作为唯一性，也就是同个微信号在不同的公众号open-id 是不一样的, 不同的微信号在同个公众号open-id 也是不同的
微信生态中，用户的平台级的唯一标识，当公众号和小程序都绑定在了同一个开发者账号中，那么这些公众号和小程序对同一个微信用户就会生成一个唯一的 union-id , 从而可以在公众号和小程序中识别到同一个微信用户
图示是我总结的整个授权体系的流程图
简单来说，微信开放平台会定时的推送 ticket给你，这个ticket可以用来获取第三方平台的 component_access_token 作为调用第三方平台接口的凭证。通过调用第三方平台的接口获得预授权码，你可以可以组装链接给用户去访问扫码，组装的链接实际上是微信的域名，用户扫描并且确认授权后，微信就会给你一个属于该公众号的授权码，你通过该授权码就可以拿到公众号的授权信息（包括权限集，access_token，access_refresh_token , 过期时间等），其中 refresh_token 是用来刷新 access_token 的，这些凭证都是有有效期的，需要在过期前进行刷新。
因此，需要有定时任务可以手动帮我们去定时的刷新这些token，主要是第三方平台 component_access_token 的 公众号的 access_token 的刷新。
其中，相对比较麻烦的是，在获取ticket的时候，微信采用了 AES 加密算法，需要进行解密才能拿到译文，目前微信提供了 c++, php, java, python, c# 5 种语言的示例代码 ，你可以很方便的进行接入，但是没有提供 go 的 SDK ，下面我结合了GitHub 已有的案例，简单梳理一下对应的解密过程。
大家可以先看看微信的介绍，再回头看看这边文章。
这时候就要用到我们之前配置的开发者配置了。
开发者先验证消息体签名的正确性，验证通过后，再对消息体进行解密。
1. 开发者计算签名，dev_msg_signature=sha1(sort(Token、timestamp、nonce, msg_encrypt))
2. 比较dev_msg_signature和URL上带的msg_signature是否相等，相等则表示验证通过。
3. Aes 解密
4. xml 格式解析
...
e, err := wxencrypter.NewEncrypter(token, encodingAesKey, appId)
if err != nil {
return err
}
b, err := e.Decrypt(msgSignature, timestamp, nonce, deCodeInfo)
if err != nil {
return err
}
// 解析xml
var verifyTicketReq http_service_model.ComponentVerifyTicketReq
if err := xml.Unmarshal(b, &verifyTicketReq); err != nil {
return err
}
...
type ComponentVerifyTicketReq struct {
AppId string `xml:"AppId"`
CreateTime string `xml:"CreateTime"`
InfoType string `xml:"InfoType"`
ComponentVerifyTicket string `xml:"ComponentVerifyTicket"`
AuthorizationCode string `xml:"AuthorizationCode"`
}
本着不重复造轮子的原则，在GitHub上找到了一个兄弟好几年前写的sdk，大家可以将其引入作为拓展包使用。
https://github.com/gomydodo/wxencrypter
由于这个仓库代码作者已经不维护了，建议大家拷贝一下自己改改嵌入到项目中，后续有需要可能会出一个开源的 sdk 给大家参考使用。
其中，需要注意的是
EncodingAESKey： 即消息加解密 Key，长度固定为 43 个字符，从 a-z,A-Z,0-9 共 62 个字符中选取。由开发者在创建公众号插件时填写，后也可申请修改。
AESKey： AESKey=Base64_Decode(EncodingAESKey + “=”)，EncodingAESKey 尾部填充一个字符的 “=”, 用 Base64_Decode 生成 32 个字节的 AESKey；
因此实际上用到的AESKE 是上面的算法来生成的，如下图所示。
如图，我们前面说到，一个开放平台账号是可以建多个第三方平台的。例如开放平台账号1有着A第三方平台和B第三方平台。
一个公众号可以授权给多个第三方平台（不过权限集有些是互斥的，比如一些权限集只能给其中一个），如公众号A 分别授权给了 开放平台账号1的 A第三方平台和B第三方平台，又同时授权给了开发平台账号3的C第三方平台。
这时候，你可能会有疑问，为啥有虚框和非虚框的绑定的公众号功能。
在后台系统，是有绑定公众号的功能的，你可以将旗下的公众号都绑定进去，那么这些公众号就会打通账号体系了，同一个微信号在这些公众号拿到的union_id 是一致的，而 open_id 是和公众号有关系，因此open_id 会不一致。
如果你是做的对外使用的第三方平台，目前我们是让客户自己去申请属于自己的开放平台账号，让客户自己在他的账号里绑定他们公司的公众号以及小程序等（毕竟每个客户的主体都不同，这是比较好的做法）。
本文主要讲解了开放平台的一些操作指引，第三方平台的业务流程说明，常见业务概念的解释，以及微信打通账号体系的原理。算是一篇比较干货的内容，建议收藏，说不定后面你也需要搞类似的业务。