JWT面试常见问题

JWT面试常见问题

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时伪造的拦截请求即可