有关类似opendId的敏感数据是否可以在通信中作为参数传递，大家怎么看？
原创声明:本文为作者原创，未经允许不得转载，经授权转载需注明作者和出处
微信小程序文档中没有明确的指出他所谓的敏感数据是否可以在通信中传输，如openid这种。
如wx.getUserInfo的数据中敏感数据是在加密段中的，解密需要后台进行，如果可以服务器解析返回给小程序端，这个过程openid同样是暴露在网络传输中，那他加密的意义又何在？不是只是为了推卸责任，openid泄露是在小程序与我们自身服务器通信过程中而不在于小程序与微信服务器通信过程中把？都是https也不存在这个考虑吧。
如果不能把openid用作传输，那这个加密信息不可能每次都作为参数传递给后台吧，而且后台登录的时候已经拿到openid了，后台也不需要通过他这个加密段来解析出openid，根据session就可以获取到。那意义有何在？
所以这个部分的设计感觉有些鸡肋了，揣摩不透，他想怎么弄。目前我是按照openid可以后台解析传给小程序这种方式在使用。用小程序代码端解析出的openid和后台session里面的openid做匹配来判断身份安全性。
如果真的是这样，那估计腾讯就是为了，避免那个可能泄露openid的责任吧，大家怎么看？
http://www.wxappclub.com/topic/422
openid个人觉得不是敏感数据，每个用户针对每个公众号会产生一个安全的openid；openid只有在appid的作用域下可用。除非你的appid也泄露了。
但是不幸的是，解密敏感数据里面包含应用的appid，如果不注意就会把整个解密后的明文回传给客户端。
我想到的微信团队这样做的意图有可能是：服务端解密敏感数据为了方便开发者记录用户信息；而不是做个解密回传给客户端。
记录解密的用户信息，可以知道哪个用户（openid）属于哪个服务号（appid）的用户，以及通过unionid识别认证主体下的用户。
wx.getUserInfo 这个接口本身不就说明问题了吗？可以在通信中传输。
另外，既然加密了，为何要服务器解密后返回给小程序端？
关于登录，文档里写得其实也比较明确了，自行派发一个3rd_session进行校验。
然后wx.getUserInfo返回数据的设计，主要是为了保护敏感信息，也没有什么鸡肋的地方。因为还有其他数据：
{ "appId": "APPID", "openId": "OPENID", "nickName": "NICKNAME", "gender": 1, "city": "CITY", "province": "PROVINCE", "country": "COUNTRY", "avatarUrl": "AVATARURL", "unionId": "UNIONID" }其中的UnionID可以用来区分用户的唯一性，具体可以参考UnionID机制说明。
敏感信息还包括appid，openid
此外，wx.getUserInfo 需要在调用wx.login之后，你这里说的
用小程序代码端解析出的openid和后台session里面的openid做匹配来判断身份安全性。我不知道有什么意义。
@ghostsf 目前来看，解密的工作是后台来做的，而获取userInfo的是小程序前端，这里就涉及到一个问题，openId这些信息是否需要在前端使用，还是只传递到后台就可以了。
这就就分开讨论
第一种：如果传递到后台就可以了，不允许在前端明文显示openid，现在后台登录的时候就已经返回了openId了，没有再必要使用这个加密段的userInfo再解析一次，唯一能说通的就是除了openid之外还有unionid和appid，但是如果必定后台使用，为什么接口不设计成后台在根据code去获取sessionkey那个环节一次性把opein unionid appid返回就行了？或者提供后台的另外一个接口去访问，何必要前端访问，得到数据加密，然后再传递到后端解析呢
第二种：如果传递给后台解析完允许把解析到的openid，unionid传给前台用作后续调用业务使用的话，这个数据也就暴露在通信中了（当然现在使用https也不能叫暴露，但是微信getUerInfo的也是https也应该不存在暴露的，但是他加密了），这个所谓的敏感数据是否能用于业务传递呢？
@Michael 第一种，第一个为什么，微信就是这么设计接口的，wx.login它就是用来负责登录，为什么要返回那么多不属于它接口职责的东西呢？所以设计了getUserInfo接口，用来返回这些数据，这个应该很容易理解。然后后面的或者，提供后台的另外一个接口？webservice?显然微信不会这么做。
第二种，微信并没有限制你怎么用这些敏感数据，所以理论上，随便你怎么用。
@Michael
我的个人意见是openid在通讯中传不传递都没关系，只是微信建议你不要传输。微信只是提供了一个保护第三方服务器的方案，不是所有的请求都能使用服务器资源。小程序每次向服务器发起请求都要带上3rd_session，服务器收到3rd_session后检查是否“备案”过，合法服务器才响应请求。那如果3rd_session被截获怎么办？所以3rd_session得有个有效时间。我是这么理解的。
领教了，写得不错
我觉得openid应该能够传递，不然怎么判断用户？？
@小猪 是的，前后台的交互使用的是服务器（第三方）生成的3d_session ,类似于token。openid不用于前后的传递。
@JeremyLu
“watermark”:
{
“appid”:”APPID”,
“timestamp”:TIMESTAMP
}
这里watermark有什么作用?辅助服务器进行用户认证？这里的appid是开发者的Appid吧
昨天去停了小程序的课程，尽量不要吧，让服务器获取到敏感信息后自动生成一个3rd_session给客户端,然后客户端通过和服务器的session配对，取数据。
我觉得@小猪 分析得有道理 合法逻辑 学习了！ 这些问题 我相信微信团队也在思索 ，肯定有一个合理合法的解决方案 他们才敢推出来；不然到时候就是官司缠身了 。。。。。。
顶一下
顶一下
111
1.
赞
值得看看
3rd_session是自己在后台获取到openid后随机生成的吗
？那么3rd_session需要录入数据库吗？
@请告诉我怎能不想你 是的，后台生成，存入数据库