why token 2(参见微信,使用签名)

之前讲了一篇Token的文章,服务器需要每个用户分配一个唯一的Token,并且要在有效期内一直持有和维护。如果分布式的话,还要考虑到Token在服务器之间的共享。
但是有个问题来了,如果token暴露了,那么该用户(甚至平台)就被劫持了。
研究了下微信第三方接入的验证方式,有以下几种情况。
1.公众平台服务器端发起,获取该公众号下用户是上面那个方式,APPSecret+APPid 获取access_token,后面直接通过access_token,全程HTTPS保护无烦恼,秘钥等关键信息不过客户端。
2.开放平台,用户微信登陆,使用的是OAUTH认证并且回调服务器,服务器通过Code+APPSecret+APPid获取该用户基本信息,全程HTTPS保护无烦恼,秘钥等关键信息不过客户端。
3.微信JS-SDK,如果要使用到分享,扫一扫语音等功能,那么就需要微信JS-SDK了。JS-SDK不是随便用的(TMD,腾讯的东西,没钱玩你麻痹),要初始化验证,但是又不能赤裸裸的把APPSecret,access_token放到页面里面初始化(如果这家伙一连电脑调试,就能拿到了,拿了会怎么样? 看情况1,直接把该公众平台下用户数据拉下来随便玩),这也是此种情况不同上两种的原因。

下面讲下针对第三种情况的解决办法,不光光是微信,以后碰到类似场景也可以借鉴。虽然微信不能把access_token返回客户端,但是微信让服务器通过access_token换取一个api_ticket(局部风险保护,以后直接用api_ticket做下面操作),之后服务器使用api_ticket+timestamp+nonce_str 等一些按照字母排序做SHA1算法返回客户端作为签名signature。
之后客户端初始化就用signature到微信平台那验证,过了就OK了,就算signature暴露了,也不会对该公众平台有什么危险。

总结一下就是,如果单纯使用token,必须要保证token的安全(HTTPS)。如果有暴露风险,那么就应该加密/签名。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>