sessionkey获取流程(请使用有效的sessionkey参数)
如何获取sessionKey，即access
首先根据appkey和回调url获得code
然后根据code，appkey，app_secret
回调地址就可以获取session_key
微信小程序（抖音小程序）：手机号码解析失败解决方案
本文以抖音小程序（微信小程序获取流程和接口一模一样）为例，最近博主在做一个抖音小程序的小项目，前端在获取用户手机号的时候，需要调用 tt.login 接口进行登录，登录后返回一个code，这个code有3分钟的失效时间，根据这个code可以获取到sessionKey，这个sessionKey类似于对称加密的密钥，会对用户信息进行加密。在获取用户信息的时候，前端
需要将 button 组件 open-type 的值设置为 getPhoneNumber。用户点击后会弹出一个授权弹窗让用户确认（若该用户账户未绑定手机号码会执行一次绑定手机号码的流程；授权弹窗每次使用都会弹出）。 用户同意后，开发者可以通过 bindgetphonenumber 事件回调获取到一个加密数据，开发者可以把该数据传回到自己的服务端进行解密获取手机号。
获取到的加密数据需要使用sessionKey进行解密，因此在获取用户信息前，需要登录一次，获取到code，然后根据code获取到sessionKey，再根据sessionKey进行加密数据的解密，解析出手机号。
根据博主猜测，抖音在登录后会生成一个code，和一个对应的sessionKey，在会话期间（session未过期）的时候获取用户信息，会将用户信息使用sessionKey进行数据的加密，进行数据的解密也需要使用到sessionKey。code和sessionKey是对应的，但是它们的失效期是不一样的，code的失效期是3分钟，sessionKey的失效时间是不定的，只要用户活跃在页面上都不会失效。在获取到code的3分钟内调用 code-2-session 接口，会获取到sessionKey，如果3分钟后根据code获取sessionKey将会获取失败，因此解密也会失败。
因为无法判断用户什么时候开始获取用户信息，所以用户一进入页面，前端就会调用 tt.login 接口进行登录，然后放到localstorage缓存中，在用户点击按钮时，弹出授权框用户确认后获取到用户信息的加密数据，然后前端将缓存的code和加密数据一并传给后端。后端用code先去调用 code-2-session 接口获取到sessionKey，然后以sessionKey为密钥进行AES解密，获取到手机号返回给前台。整个流程看起来没什么问题，但是一旦用户在页面停留时间超过3分钟，然后再去获取用户信息会失败，主要是因为code已经失效，获取sessionKey会失败。
目前的问题就是过了code的有效期后，根据code获取sessionKey失败。那么在前端login获取到code后，先缓存到本地，然后立即调用后台接口去获取sessionKey然后缓存到redis里面，key为code，value为sessionKey。失效时间根据自己的业务设置（小程序页面用户不会停留太久，因此缓存失效时间设置为30分钟），用户退出小程序后，会重新login，然后也会存一份新的code和sessionKey的对应值。
用户在授权到用户信息后，前端直接将缓存的code和加密后的用户信息上传到服务到进行解密。服务端根据code从缓存中先获取到sessionKey，然后再用sessionKey进行解密，解析出手机号进行返回。
以上解决办法每次基本都可以获取手机号成功，但是也会存在一些问题
UserInfoController主要提供两个接口，一个是解密手机号和code2seesion操作
TiktokEncryptedParam 主要是前端传过来的code和加密后的数据
TiktokUserInfoSPI 主要是对接口的封装
TiktokUserInfoSPIAdapter 实现接口
使用AES对称加密
NetKey、AppKey、DevKey和Session Key
在通信阶段使用NetKey，AppKey和DevKey。
Network Key ：用来在Network Layer加密通信数据。NetKey是16字节。NetKey使用随机数产生方式，避免冲突。NetKey属于Configuration Client维护的NetKey List（12bits NetKey Index），可以多达4096个NetKey。可以通过Config NetKey Add的Message来给Node分配NetKey。
Application Key ：用来在Upper Transport Layer加密通信数据。在Provisioning结束后，进入Configuration过程，添加AppKey并且把AppKey和具体的Model绑定。一个Model可以有251个AppKey。APPKey是16字节。AppKey使用随机数产生方式，避免冲突。APPKey属于Configuration Client维护的APPKey List（12bits AppKey Index），可以多达4096个AppKey。可以通过Config AppKey Add的Message来给Node分配AppKey。
NetKey Index（12bits）+AppKey Index（12bits）=24bits，使用3个字节表达。
Device Key ：Configuration Client（比如Provisioner）通过这个密钥来管理Node，同时发布更新的网络信息和Application Key。
Configuration message通过这个Key来加密信息。
一个节点可以有一个Device Key，多个AppKey，多个NetKey，如下图所示：
Session Key ：Provisioning过程使用到这个Key，在Provisioning的交换公开密钥获得ECDHSecret以及认证通过后，通过k1算法获得Session
Key。然后，Provisioner和Device用这个Session Key交换Provisioning Data。