因为最近在帮忙做博客的后台接口让朋友接上做个app玩玩，其中涉及到客户端和服务器间进行交互的安全问题，考虑到用token传输密匙…这里稍稍做下token的考虑…

这里记录下在知乎看到的一个见解：

token是个凭条，不过它比门票温柔多了，门票丢了重新花钱买，token丢了重新操作下认证一个就可以了，因此token丢失的代价是可以忍受的——前提是你别丢太频繁，要是让用户隔三差五就认证一次那就损失用户体验了。

基于这个出发点，如果你认为用数据库来保持token查询时间太长，会成为你系统的瓶颈或者隐患，可以放在内存当中。

比如memcached、redis，KV方式很适合你对token查询的需求。

这个不会太占内存，比如你的token是32位字符串，要是你的用户量在百万级或者千万级，那才多少内存。

 要是数据量真的大到单机内存扛不住，或者觉得一宕机全丢风险大，只要这个token生成是足够均匀的，高低位切一下分到不同机器上就行，内存绝对不会是问题。 

 客户端方面这个除非你有一个非常安全的办法，比如操作系统提供的隐私数据存储，那token肯定会存在泄露的问题。

比如我拿到你的手机，把你的token拷出来，在过期之前就都可以以你的身份在别的地方登录。 

 解决这个问题的一个简单办法 

 1、在存储的时候把token进行对称加密存储，用时解开。 

 2、将请求URL、时间戳、token三者进行合并加盐签名，服务端校验有效性。 

 这两种办法的出发点都是：窃取你存储的数据较为容易，而反汇编你的程序hack你的加密解密和签名算法是比较难的。

然而其实说难也不难，所以终究是防君子不防小人的做法。 话说加密存储一个你要是被人扒开客户端看也不会被喷明文存储……方法1它拿到存储的密文解不开、方法2它不知道你的签名算法和盐，两者可以结合食用。 

 但是如果token被人拷走，他自然也能植入到自己的手机里面，那到时候他的手机也可以以你的身份来用着，这你就瞎了。

于是可以提供一个让用户可以主动expire一个过去的token类似的机制，在被盗的时候能远程止损。 

 话说一个人连自己手机都保护不好还谈什么安全……在网络层面上token明文传输的话会非常的危险，所以建议一定要使用HTTPS，并且把token放在post body里。