虾皮面试：深入探讨JWT身份认证的优缺点及常见解决方案，助力开发者做出明智选择

JWT 的优势

与传统的 Session 认证方式相比，使用 JWT 进行身份认证主要有以下四个显著优势。

无状态

JWT 本身就包含了身份验证所需的所有信息，因此我们的服务器不必储存 Session 信息。这显著提升了系统的可用性和可扩展性，同时减轻了服务端的压力。

然而，JWT 的无状态特征也带来了一个显著的缺点：不可控性！例如，如果我们想在 JWT 有效期内撤销某个 JWT 或者更改它的权限，变更通常不会立即生效，往往需要等到有效期结束后才能生效。此外，当用户登出时，JWT 仍然处于有效状态。除非在后端增加额外的处理逻辑，例如将失效的 JWT 存储起来，以便在后端验证 JWT 的有效性，我们将在后面的内容中详细探讨这个问题。

有效防止 CSRF 攻击

CSRF（跨站请求伪造） 是一种网络攻击形式，尽管比 SQL 注入、XSS 等攻击手法知名度低，但却是开发系统时需要重视的安全隐患。即使技术巨头 Google 的产品 Gmail 也曾在 2007 年爆出过 CSRF 漏洞，造成用户损失。

CSRF 攻击是如何发生的？ 简而言之，就是黑客利用你的身份发起恶意请求（例如恶意转账）。比如，小壮登录某网上银行，看到一个帖子中有链接写着“科学理财，年盈利率过万”，好奇点开后却发现账户少了 10000 元。这是因为黑客在链接中藏了一个请求，利用小壮的身份向银行发起了转账请求。

CSRF 攻击依赖于 Cookie，通常使用 Session 认证时，Cookie 中的 SessionID 会被浏览器发送到服务器，只要发出请求，Cookie 就会被带上。因此，即使黑客无法获取你的 SessionID，只需让你误点击攻击链接便可实施攻击。

然而，使用 JWT 进行身份验证时，登录后用户会将 JWT 存储在 localStorage 中。每次请求都会附带这个 JWT，整个过程与 Cookie 完全无关。因此，若用户点击了恶意链接并发起请求，非法请求将不会携带 JWT，因此被视为无效请求。

总结一句话：使用 JWT 进行身份验证不依赖于 Cookie，从而有效避免了 CSRF 攻击。

但这也增加了 XSS 攻击的风险。为了防范 XSS 攻击，可以选择将 JWT 存储在标记为 httpOnly 的 Cookie 中，然而，这样又需要自己提供 CSRF 保护。因此，在实际项目中，我们通常不采用这种方式。避免 XSS 攻击的常用方法是过滤掉请求中有风险的可疑字符串。在 Spring 项目中，我们一般通过创建 XSS 过滤器来实现。

@Component  
@Order(Ordered.HIGHEST_PRECEDENCE)  
public class XSSFilter implements Filter {  
  
    @Override  
    public void doFilter(ServletRequest request, ServletResponse response,  
      FilterChain chain) throws IOException, ServletException {  
        XSSRequestWrapper wrappedRequest =  
          new XSSRequestWrapper((HttpServletRequest) request);  
        chain.doFilter(wrappedRequest, response);  
    }  
  
    // 其他方法  
}

适合移动端应用

使用 Session 进行身份认证时，必须在服务器端保存一份信息，并依赖 Cookie（保存 SessionId），这使得它不适合移动端应用。而使用 JWT 进行身份认证则不会有此问题，客户端只需将 JWT 存储即可使用，且 JWT 具备跨语言的优越性。

单点登录友好

在使用 Session 进行身份认证时，实现单点登录需要将用户的 Session 信息保存在一台设备上，同时还会遇到 Cookie 跨域问题。相比之下，使用 JWT 进行认证时，JWT 存储在客户端，不存在这类问题。

JWT 身份认证常见问题及解决方案

注销登录等场景下 JWT 仍然有效

JWT 的续签问题

JWT 的有效期一般建议设置短一些，若 JWT 过期后该如何认证？如何实现动态刷新 JWT，以避免用户频繁重新登录？

在 Session 认证中，一般的做法是：假设 Session 有效期为 30 分钟，如果用户在 30 分钟内有访问，就将 Session 的有效期延长 30 分钟。

对于 JWT，我们应如何解决续签问题呢？以下是四种总结方案：

1. 类似于 Session 认证中的做法

这种方案适用于大部分场景。假设服务端给的 JWT 有效期设置为 30 分钟，服务端每次进行校验时，如果发现 JWT 的有效期即将到达，便重新生成 JWT 给予客户端。客户端每次请求时，检查新旧 JWT 是否一致，如不一致则更新本地 JWT。该做法的问题在于，仅在接近过期时请求才会更新 JWT，对客户端并不友好。

2. 每次请求都返回新 JWT

该方案思路简单，但开销较大，尤其在存储和维护 JWT 的情况下。

3. 将 JWT 有效期设置到半夜

该方案为折衷方案，保证大部分用户在白天可以正常使用，适合对安全性要求不高的系统。

4. 用户登录时返回两个 JWT

一个是 accessJWT，有效期为半小时；另一个是 refreshJWT，有效期为一天。客户端在登录后，将 accessJWT 和 refreshJWT 存储在本地，每次访问时发送 accessJWT。服务端校验 accessJWT 的有效性，若过期则发送 refreshJWT 进行校验；若有效，则生成新的 accessJWT。若无效，客户端需重新登录。

该方案的不足在于：