token是个凭条，不过它比门票温柔多了，门票丢了重新花钱买，token丢了重新操作下认证一个就可以了，因此token丢失的代价是可以忍受的——前提是你别丢太频繁，要是让用户隔三差五就认证一次那就损失用户体验了。\x0d\x0a\x0d\x0a客户端方面这个除非你有一个非常安全的办法，比如操作系统提供的隐私数据存储，那token肯定会存在泄露的问题。比如我拿到你的手机，把你的token拷出来，在过期之前就都可以以你的身份在别的地方登录。\x0d\x0a解决这个问题的一个简单办法\x0d\x0a1、在存储的时候把token进行对称加密存储，用时解开。\x0d\x0a2、将请求URL、时间戳、token三者进行合并加盐签名，服务端校验有效性。\x0d\x0a这两种办法的出发点都是：窃取你存储的数据较为容易，而反汇编你的程序hack你的加密解密和签名算法是比较难的。然而其实说难也不难，所以终究是防君子不防小人的做法。话说加密存储一个你要是被人扒开客户端看也不会被喷明文存储??\x0d\x0a方法1它拿到存储的密文解不开、方法2它不知道你的签名算法和盐，两者可以结合食用。\x0d\x0a但是如果token被人拷走，他自然也能植入到自己的手机里面，那到时候他的手机也可以以你的身份来用着，这你就瞎了。\x0d\x0a于是可以提供一个让用户可以主动expire一个过去的token类似的机制，在被盗的时候能远程止损。\x0d\x0a话说一个人连自己手机都保护不好还谈什么安全??\x0d\x0a\x0d\x0a在网络层面上token明文传输的话会非常的危险，所以建议一定要使用HTTPS，并且把token放在postbody里。