前后端分离，生成了token，这个token保存在哪里比较合适

[JAVA-上帝之手]

前后端分离，生成了token，这个token保存在哪里比较合适

1.后台保存在 cookies,,,设置httponly=true,,,,,z这种感觉就像以前的session模式，貌似不科学

2,。前端自行保存！但是前端又保存在哪里呢，，，存cookie，前端可能会被攻击，不安全！

各位大佬，你们在保存token，传递信息的时候都是怎么做的？？？？？

[Wales_]

用jwt生成的token不用存储，直接解码

[JAVA-上帝之手]

引用 1 楼 Wales_ 的回复:

用jwt生成的token不用存储，直接解码

是直接解码，，你生成token后，这个token肯定要保存在前端或者cookie，，才能让后续的请求使用哦，我说的是这个问题

[Forevermark993]

vue那套的话就存在Vuex里面

[weixin_61500025]

@JAVA-上帝之手 那记住密码就不好实现了啊

[JAVA-上帝之手]

引用 3 楼 Farmermark993 的回复:

vue那套的话就存在Vuex里面

我感觉，还是后台设置cookie，然后禁止前端访问这个cookie比较安全

[a584257442]

cookie不是也保存在浏览器，和后台有什么关系，既然前后端分离，token肯定保留在客户端，该被攻击还是被攻击，如果想保证安全，只能从校验手段出发，比如token多加些限制条件，比如把浏览器情况之类七的八的也一起加进去，最好也别用jwt，这个没法主动让他失效

[晟小明]

@s478853630 @s478853630 那这种情况下后端怎么校验token是否正确呢，每个用户的token都存放在数据库里嘛，是不是太浪费空间了

[s478853630]

前端存入localstorage就可以，localstorage不参与服务器交互，没有抓包一说，绝对安全， 但后端要验证，前端就必须传入，比如：http://x.x.com/save?token=xxx&a=1&b=2， 这种方式相当于裸奔，post也是，建议改良一下： 先用MD5混淆token，示例代码：var token = md5(md5('a=1&b=2&time=当前时间&token=xxx')); 再调接口：http://x.x.com/save?token=混淆后的token&time=当前时间&a=1&b=2 MD5不可逆，加上时间有效性验证，即使被抓包，也无法获取真实token， 参数一起混淆不能篡改，用相同参数时间已过期， 前后校验端逻辑保持一致，安全系数可达99.9%

[苏颙]

存localstorage里和cookie都可以

[rumlee]

正常就放在cookie，然后设置httponly就可以了。当然你的token必须是跟sessionid一样，能够追溯到一个唯一用户的。 如果这个担心攻击利用的话，你倒是模拟一个攻击方法看看，至少我不知道这种可以怎么利用（不暴露我自己的登录信息的情况下）。而且如果这种能够攻击的话，那现在的整个http协议都有问题，几乎所有的需要登录的网站都存在问题，因为session就是这么实现的啊，现在几乎所有的网络系统都是基于session来实现登录状态保持的啊。

[rumlee]

引用 7 楼 rumlee 的回复:

正常就放在cookie，然后设置httponly就可以了。当然你的token必须是跟sessionid一样，能够追溯到一个唯一用户的。 如果这个担心攻击利用的话，你倒是模拟一个攻击方法看看，至少我不知道这种可以怎么利用（不暴露我自己的登录信息的情况下）。而且如果这种能够攻击的话，那现在的整个http协议都有问题，几乎所有的需要登录的网站都存在问题，因为session就是这么实现的啊，现在几乎所有的网络系统都是基于session来实现登录状态保持的啊。

如果你的token并没有和登录信息绑定，无法追溯到一个唯一用户的话，那你不管放在哪里都不安全，跟放在哪里没有关系，你只要在网络上传输就会暴露。

[Gemini_Kanon]

存Redis吧，单独管理，安全高效

[哈哈gogo]

不用担心，jwt-go库还是安全的

[lambCan]

前端的token可以存在vuex，localStorage，cookie推荐localStorage，cookie，可以实现免密登录，记住密码等功能，后端的话存在Redis里面，每次请求的时候吧token放在请求头里，后端接收到token之后在Redis里进行查询，为什么不存在mysql里面，因为Redis是基于内存存储的，存储的是k-v格式的数据，操作数据比mysql快，而且还能设置token的过期时间，有了token就不用频繁的去执行sql语句去判断用户角色了。再讲一下为什么现在都用token而不用session了，因为通常session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的会压力增大，再一个session是基于cookie进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。然后现在项目基本都是微服务，如果搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。

[你假发掉了]

m