在学习微信开放平台官方文档的过程中，直观的感受就是这套流程是足够安全的。
微信授权流程是安全的
微信授权流程的重心在微信服务器和个人服务器之间的通信。两者通过微信开放平台的配置解决了信任链的问题，只要彼此的配置是正确的则请求是可信的。相比于 https 的认证流程，需要繁杂的过程去解决信任问题，信任链的终点是设备出厂时候配置的用于验证证书的 ca，需要首先通过非对称加密参与解决信任问题，才能进一步使用对称加密。而微信和个人服务器只要确定了服务端的配置就可以直接使用，非常可靠。
和其它厂商实现比较
由于时间安排和个人经验不足，以下我对 facebook、google sdk 方案的描述可能是不充分或者存在错误的。
通过简单的了解 facebook 和 google 也是通过 OAuth2.0 方式鉴权且方式都比较接近，和微信流程有挺大的差异。
facebook 和 google 应用在授权完成后跳转到具体的 URL。猜想 认证页面认证完成后将认证凭证写入 cookies， 目标页面引入的厂商的脚本在初始化时可以读取到 cookies，带入 javascript 环境从而页面脚本可以判断登陆情况并进一步获取用户信息。该过程不需要个人服务器参与，简单够用。而微信流程在客户端获取临时凭证后到需要提交到服务端，由服务端与微信服务端通信之后才能得到客户端的身份（openId）。
相比与 fg，微信流程需要个人服务器的参与，使得 openId 可以不下发到客户端(下发 access_token)，fg 流程在网页中客户获取到用户固定的身份标志。存在的差异是在微信页面中恶意脚本没法向个人服务端探测其它用户的数据，而 fg 流程在该应用的其它用户身份标志已经被发现的情况下，用户数据可能被探测到。
相比与 fg 流程，微信流程对微信服务器的依赖更多，微信服务器的稳定性决定了业务的稳定性。提高了安全性的同时，引入了流程，增加时耗和网站设计难度。
其它
个人服务器与微信服务器通信过程会将 appId, appSecret 拼接在请求链接，例如：
https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code
在通信链路不可信的情况下，其安全性由 https 保证，但是服务端程序在实现和配置的时候不一定保证会对证书进行验证，存在被中间人攻击的可能。一个不成熟的方案：可以尝试由微信统一实现用于安装在个人服务器的程序，该程序为其它进程提供服务，用于取代替换个人服务器自主实现向微信服务器发起上述请求的过程。