1.jwt和security的对比：
JWT的优点：
-
无需再服务端存储用户数据，减轻服务端压力
- 轻量级，json风格，比较简单
- 跨语言
JWT的缺点：
- token一旦签发，无法修改
- 无法更新token有效期，用户登录状态刷新难以实现
- 无法销毁一个token，服务端不能对用户状态进行绝对控制
- 不包含权限控制
SpringSecurity：
优点：
- 用户信息保存再服务端，服务端可以对用户状态绝对控制
- 基于Spring，无缝整合，修改登录逻辑，其实就是添加过滤器
- 整合权限管理
缺点：
- 限定了语音
- 实现复杂，基于一连串的过滤器链
- 需要再服务端保存用户信息，增加服务端压力
2.你们使用JWT做登录凭证，如何解决token注销问题
答：jwt的缺陷是token生成后无法修改，因此无法让token失效。只能采用其它方案来弥补，基本思路如下：
方案一：
1）适当减短token有效期，让token尽快失效
2）删除客户端cookie
3）服务端对失效token进行标记，形成黑名单，虽然有违无状态特性，但是因为token有效期短，因此标记 时间也比较短。服务器压力会比较小
方案二：
1）用户登录后，生成JWT
2）把JWT的id存入redis，只有redis中有id的JWT，才是有效的JWT
3）退出登录时，把ID从Redis删除即可
3.既然token有效期短，怎么解决token失效后的续签问题？
答：在验证用户登录状态的代码中，添加一段逻辑：判断cookie即将到期时，重新生成一个token。比如token有效期为30分钟，当用户请求我们时，我们可以判断如果用户的token有效期还剩下10分钟，那么就重新生成token。因此用户只要在操作我们的网站，就会续签token
4.如何解决异地登录问题？
答：JWT设计为了实现无状态的登录，因此token无法修改，难以实现异地登录的判断，或者强制让登录token失效。
因此如果有类似需求， 就不应选择JWT作为登录方案，而是使用传统session登录方案。
但是，如果一定要用JWT实现类似要过，就需要在Redis中记录登录用户的JWT的token信息，这样就成了有状态的登录，还不如一开始就选择Session方案。
5.如何解决cookie被盗用问题？
答：cookie被盗用的可能性主要包括下面几种：
XSS攻击：这个可以再前端页面渲染时对 数据做安全处理即可，而且我们的cookie使用了Httponly为true，可以防止JS脚本的攻击。
CSRF攻击：
利用Referer头，防盗链
请求头中加随机码
抓包，获取用户cookie：我们采用了HTTPS协议通信，无法获取请求的任何数据
请求重放攻击：对于普通用户的请求没有对请求重放做防御，而是对部分业务做好了幂等处理。运行管理系统中会对token添加随机码，认证token一次有效，来预防请求重放攻击。
用户电脑中毒：这个无法防范。
6.用户的cookie被禁用怎么办？
cookie一般情况下，是不会被禁用，因为普通人根本不知道是什么是cookie，一般不用管，为了友好，我们可以给用户一个提示：你的cookie已经被禁用了，请启用cookie。
把jwt作为响应头返回，浏览器中JS把token写到本地存储（sessionStorage），要求前端每次发ajax，都必须自己携带token。而且有被xss攻击的风险
7.如何解决cookie被篡改问题？
答：cookie可以篡改，但是签名无法篡改，否则服务端认证根本不会通过
8.如何完成权限校验的？
首先我们有权限管理的服务，管理用户的各种权限，及可访问路径等
在网关zuul中利用Pre过滤器，拦截一切请求，在过滤器中，解析jwt，获取用户身份，查询用户权限，判断用户身份可以访问当前路径
9. 服务端微服务地址不小心暴露了，用户就可以绕过网关，直接访问微服务，怎么办？
答：
首先，我们的微服务隐藏在网关的后面，而且整个服务被Nginx反向代理，用户只能看到nginx的地址，微服务暴露的可能性很低。
然后，即便真的暴露了，我们的微服务都做了严格的服务间鉴权处理，任何对微服务的访问都会被验证是否有授权，如果没有则会被拦截。具体实现：
会有一张表记录每个微服务的id，和密钥信息
服务启动时，需要去授权中心，认证身份，携带id和secret
授权中心认证通过，会颁发一个JWT给微服务
微服务访问其它服务时，需要携带JWT
被访问的服务，需要验证JWT，如果没有携带，或token时伪造的拦截请求即可
原文链接：https://blog.csdn.net/MINGJU2020/article/details/103039418
