关于手机app之api认证
出于安全考虑，近期推进一次app和api间通讯的认证的流程。舍弃了app认证这种思路，走的用户授权的思路。
具体流程如下:
- 就是app第一次启动时，向服务器请求获得
accessId授权id,accessToken授权token,accessExp授权过期时间。 - 接口请求的时候，将参数，时间戳，
accessToken哈希，作为sign附加在参数上。（如果上https，只要将accessToken附加返回就好了） - 当用户登录的时候，将用户id和
accessId关联,存于服务器端。 - 操作用户数据接口获取到用户id后校验和
accessId关联的用户id比较是否一致。 - 以后手机启动的时候，拿保存的
access信息，请求更新接口，获取新的access信息。
考虑的安全问题：
- 数据私密性，让数据在传输过程中不可见，避免偷窥狂，解决办法是上https，第一期不做。
- 数据完整性，防止数据发出后被篡改，解决办法是上https，第一期特么不上https，第二期又不知道在哪里。所以，将所有参数，加上时间戳，和
access_token拼接后进行hash得到sign，附加在请求里面。服务端对sign进行校验。保证参数不被篡改。 - 请求幂等性，一个请求只请求一次有效，例如A给B转账，这个请求调用多次，只会转账一笔。通过
accessId,接口，时间戳作为唯一判断来避免重放。 - 密钥泄漏，app被反编译，密钥丢了怎么办，所以舍弃app授权，改用对用户授权。
- 内存修改器，app如果直接持有
memberId与服务端通讯，假如memberId被修改，防线瞬间就瓦解了，所以不以app持有的memberId为凭证，而是以accessId关联的memberId为准。
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
