一文搞懂Session和JWT登录认证 - 服务器托管|北京服务器租用|机房托管租用|IDC托管租用|机房机柜带宽租用-价格及费用咨询

前言

目前在开发的小组结课项目中用到了JWT认证，简单分享一下，并看看与Session认证的异同。

登录认证（Authentication）的概念非常简单，就是通过一定手段对用户的身份进行确认。

我们都知道 HTTP 是无状态的，服务器接收的每一次请求，对它来说都是 “新来的”，并不知道客户端来过。

举个例子：
客户端A: 我是A, 给我一瓶水。
服务端B：好，给你。
客户端A：再给我来个面包。
服务端B: 啥，你是谁?

即每一个请求对服务器来说都是新的。

我们不可能每次操作都让用户输入用户名和密码，那么我们如何让服务器记住我们登录过了呢?

那就是凭证。即每次请求都给服务器一个凭证告诉服务器我是谁。

现在一般使用比较多的认证方式有四种：

Session
Token
SSO单点登录
OAtuth登录

下面就来说说比较常用的前两种。

Session

Cookie + Session

最常见的就是 Cookie + Session 认证。

Session，是一种有状态的会话管理机制，其目的就是为了解决HTTP无状态请求带来的问题。

当用户登录认证请求通过时，服务端会将用户的信息存储起来，并生成一个 SessionId 发送给前端，前端将这个 SessionId 保存起来。之后前端再发送请求时都携带 SessionId，服务器端再根据这个 SessionId 来检查该用户有没有登录过。

这个 SessionId，一般是保存在Cookie中。

如果用户第一次访问某个服务器时，服务器响应数据时会在响应头的 Set-Cookie 标识里将Session Id 返回给浏览器，浏览器就将标识中的数据存在Cookie中。

下面我们来简单写个 demo 测试一下：

初始化一个spring boot 项目，并且代码如下：

demo

我们只需要在用户登录的时候将用户信息存在HttpSession中

@RestController
public class UserController {

    @PostMapping("login")
    public String login(@RequestBody User user, HttpSession session) {
        if ("admin".equals(user.getUsername()) && "admin".equals(user.getPassword())) {
            // 登录成功 写入Session
            session.setAttribute("sessionId", user);
            return "login success";
        }
        return "username or password incorrect";
    }

    @GetMapping("/logout")
    public String logout(HttpSession session) {
        // 注销 删除Session
        session.removeAttribute("sessionId");
        return "logout success";
    }

    public String api(HttpSession session) {
        // 用户操作 判断是否登录
        User user = (User) session.getAttribute("sessionId");
        if (user == null) {
            return "please login";
        }
        return "return data";
    }
}

下面我们向 login 地址请求，并查看响应。可以看到，用户登录时服务端会返回 Set-Cookie 字段。这些工作 Servlet帮我们做好了

下面我们向 api 地址请求。可以看到，后续访问服务端自动就会携带Cookie：

服务端认证身份成功，返回数据。

Session + Header认证

当前开发的几个项目都是采用这种模式。

即 将 Session 会话放进请求头中作为认证信息。

下面简单写个 demo 并用 postman 测试

demo

pom.xml:


        
            org.springframework.session
            spring-session
            1.3.5.RELEASE
        
        
            org.springframework.boot
            spring-boot-starter-security

HeaderAndParamHttpSessionStrategy:

将cookie认证改为Header认证，请求关键字为 x-auth-token

/**
 * Header或是请求参数中的带有 token 的认证策略
 * */
public class HeaderAndParamHttpSessionStrategy extends HeaderHttpSessionStrategy {
  /**
   * header认证关键字名称
   */
  private String headerName = "x-auth-token";

  @Override
  public String getRequestedSessionId(HttpServletRequest request) {
    String token = request.getHeader(this.headerName);
    return (token != null && !token.isEmpty()) ? token : request.getParameter(this.headerName);
  }
}

MvcSecurityConfig:
使用spring 提供的 MapSessionRepository 来帮助我们管理Session

@Configuration
@EnableWebSecurity
@EnableSpringHttpSession
public class MvcSecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                // 开放端口
                .antMatchers("**").permitAll()
                .anyRequest().authenticated()
                .and()
                .httpBasic()
                .and().cors()
                .and().csrf().disable();
        http.headers().frameOptions().disable();
        return http.build();
    }

    /**
     * 使用header认证来替换默认的cookie认证
     */
    @Bean
    public HttpSessionStrategy httpSessionStrategy() {
        return new HeaderAndParamHttpSessionStrategy();
    }


    /**
     * 由于我们启用了@EnableSpringHttpSession后，而非RedisHttpSession.
     * 所以应该为SessionRepository提供一个实现。
     * 而Spring中默认给了一个SessionRepository的实现MapSessionRepository.
     *
     * @return session策略
     */
    @Bean
    public SessionRepository sessionRepository() {
        return new MapSessionRepository();
    }
}

重新启动项目：

尝试1：向 login 地址请求:

可以看到，服务端的响应头上带有了 x-auth-token, 这种将 session 放在请求头部的认证就是 header认证。

结果：响应头返回 x-auth-token 字段

尝试2：请求头不带 x-auth-token，向服务端请求 api

而这时候，假如客户端发送接下来的请求的时候，请求头不带上服务端返回的 x-auth-token，那么是无法得到认证的。

结果：认证失败

尝试3：请求头带 x-auth-token，向服务端请求 api

将登录成功之后，服务端返回

结果：认证成功

通过以上的方式：我们成功将 Cookie + Session 认证，替换为了 Header + Session 认证。

那么换之后，有什么好处呢？

Header + Session 相较 Cookie + Session 有几点好处：

防止跨站脚本攻击（XSS）：使用 Cookie 存储会话 ID 的话，Cookie 是通过浏览器自动管理的，容易受到 XSS 攻击的影响。而将会话 ID 存储在头部，可以避免这种攻击。
避免 CSRF 攻击：使用 Cookie 存储会话 ID 的话，攻击者可以利用 CSRF 攻击来获取 Cookie 中的会话 ID，从而伪造用户请求。将会话 ID 存储在头部的话，可以避免这种攻击。
不受第三方 Cookie 支持的限制：如果用户的浏览器禁用了第三方 Cookie，那么使用 Cookie + Session 的方式就无法使用。而将会话 ID 存储在头部，不需要使用 Cookie，不受这个限制。

缺点：

会话 ID 存储在头部，可能被重放攻击利用
执行性能代价较高：由于 HTTP 头比 Cookie 更大，因此将会话 ID 存储在头部通常会占用更多的网络资源，增加传输延迟。

因此，应该根据具体的应用场景、协议、需求和安全要求来选择合适的身份认证方式。

Token 认证

除了Session之外，目前比较流行的做法就是使用JWT（JSON Web Token）。

JWT具有以下俩种特性：

可以将一段数据加密成一段字符串，也可以从这字符串解密回数据
可以对这个字符串进行校验，比如有没有过期，有没有被篡改

看到这，这不和 Session + Header 认证一样嘛！就是把 SessionId 换成了JWT字符串而已，有必要么？🤔

Session 和 JWT有一个重要的区别，就是 Session 是有状态的，JWT是无状态的。

即，Session 在服务端保存了用户信息，而JWT在服务端没有保存任何信息。

当前端携带Session Id到服务端时，服务端要检查其对应的 HttpSession 中有没有保存用户信息，保存了就代表登录了。

当使用JWT时，服务端只需要对这个字符串进行校验，校验通过就代表登录了。

下面继续从一个Demo体验：

demo

pom.xml:


    io.jsonwebtoken
    jjwt
    0.9.1

写一个工具类

public interface CommonService {
  /**
   * 签名秘钥
   */
  String SECRET = "shareMusic";

  // 根据用户id生成token
  static String createJwtToken(Long id) {
    long ttlMillis = -1; // 表示不添加过期时间
    return createJwtToken(id.toString(), ttlMillis);
  }

  /**
   * 生成Token
   *
   * @param id        编号
   * @param ttlMillis 签发时间 （有效时间，过期会报错）
   * @return token String
   */
  static String createJwtToken(String id, long ttlMillis) {

    // 签名算法 ，将对token进行签名
    SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;

    // 生成签发时间
    long nowMillis = System.currentTimeMillis();
    Date now = new Date(nowMillis);

    // 通过秘钥签名JWT
    byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary(SECRET);
    Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());

    // Let's set the JWT Claims
    JwtBuilder builder = Jwts.builder().setId(id)
        .setIssuedAt(now)
        .signWith(signatureAlgorithm, signingKey);

    // 如果指定了过期时间，则添加
    if (ttlMillis >= 0) {
      long expMillis = nowMillis + ttlMillis;
      Date exp = new Date(expMillis);
      builder.setExpiration(exp);
    }

    return builder.compact();

  }

    // 验证并解析JWT
    static Claims parseJWT(String jwt) { // 如果是空字符串直接返回null
        if (jwt == null ||jwt.isEmpty()) {
            return null;
        }
        // 这个Claims对象包含了许多属性，比如签发时间、过期时间以及存放的数据等
        Claims claims = null;
        // 解析失败了会抛出异常，所以我们要捕捉一下。token过期、token非法都会导致解析失败
        try {

            claims = Jwts.parser()
                    .setSigningKey(DatatypeConverter.parseBase64Binary(SECRET))
                    .parseClaimsJws(jwt).getBody();
        } catch (JwtException e) {
            System.err.println("解析失败！");
        }
        return claims;
    }
}

同时改写一下我们的 Controller:
登录成功返回

    @PostMapping("login")
    public String login(@RequestBody User user, HttpServletResponse response) {
        if ("admin".equals(user.getUsername()) && "admin".equals(user.getPassword())) {
            // 判断成功 返回头加入token
            String token = CommonService.createJwtToken(user.getUsername());
            response.setHeader("Authorization", token);
            return "login success";
        }
        return "username or password incorrect";
    }

    @GetMapping("/api")
    public String api(HttpServletRequest request) {
        String jwt = request.getHeader("Authorization");
        // 解析失败就提示用户登录
        if (CommonService.parseJWT(jwt) == null) {
            return "please login";
        }
        return "return data";
    }

重启服务开始测试。

尝试1：向 login 地址请求.

可以看到，我们成功地在服务端响应头中返回了 JWT，它是以 Authorization 作为名字的字段。

尝试2：不带JWT，向 api 地址请求.

认证失败。

尝试3：带JWT，向 api 地址请求.

结果：认证成功，返回数据。

上面我们成功使用JWT完成了登录和请求api。下面简单看一下它的原理：

JWT原理：

JWT 通常由三部分组成：Header、Payload 和 Signature。

Header：包含 Token 类型（即 JWT）和所使用的签名算法信息（如 HS256)。
Payload：存储了一些描述信息，如 Token 的颁发者、过期时间、访问权限等，也可以包含一些用户的自定义数据。
Signature：由服务器端生成，用于验证 Token 的正确性和完整性。

我们将刚才获取到的JWT去在线网站解密一下：
可以看到，获取到了我们传输的信息: 用户名

在线网站将 Header 和 Payload 中的 Base64 编码信息通过简单的算法将其还原成原始的明文数据

可以看到签名是无法解密的，这是因为 JWT 的签名主要是用于保证 JWT 的完整性和防止 JWT 被篡改或伪造。

signature 可以选择对称加密算法或者非对称加密算法，常用的就是 HS256、RS256。

具体JWt解析过程可以看这篇文章： https://www.freecodecamp.org/chinese/news/how-to-sign-and-val…

JWT 注销

你可能会留意到，上面的JWT方法没有注销的功能。那么如何注销?🤔

事实上，JWT 是无状态的认证方式，因此它本身并不提供注销的机制。让我们从后台注销token，这对于jwt来说并不是那么简单，并不能像删除 session 那样来删除token。

JWT的目的与session不同，不可能强制删除或失效已经生成的token。

我们可以采用下面两种方式：

Token 过期⏰。

通过过期时间机制。可以在生成 JWT Token 时设置一个过期时间，一旦 Token 过期后则视为无效。通过这种方式，可以保证 Token 在一定时间内有效，同时也避免了 Token 滥用和被盗用的风险。

我还是想注销

假如我有一个严格的注销功能，无法等待Token自动过期怎么办？🕵️‍

那么存储一个所谓的“名单”，判断Token是有效的。一般可以采用 Redis,

校验时，检查提供的 token 在 redis 中是否有效，如何无效的话就让用户去登录。

从这个方面也体现出了 JWt 更适合分布式结构。

Session 和 JWT

两者的不同：

存储位置：Session 信息是存储在服务端的，而 JWT 将认证信息存储在客户端的 Token 中。

是否需要状态：Session 基于状态来维护会话，如果会话状态丢失或者被篡改，服务器将会重新初始化会话。而 JWT 身份认证机制是无状态的，每个请求均包含足够的信息，服务器不需要维持任何状态。这一点使得 JWT 身份认证机制特别适合于分布式系统。

安全性：Session 是基于某种算法生成的 Session ID 来维护用户状态的，如果 Session ID 被窃取或者伪造，会话会受到攻击，凭证会失效。而 JWT 通过签名来防止伪造和篡改，只有在经过验证后才能使用。

扩展性：Session 方案一般适用于单一的服务或者单个应用，而 JWT 身份认证机制适用于跨域、分布式服务调用等多场景。

两种方式都可以实现登录认证，至于具体选型就根据自己实际业务需求来了。

参考文章:
https://www.cnblogs.com/RudeCrab/p/14251154.html#%E6%94%B6%E5…
https://segmentfault.com/a/1190000041216780
https://cloud.tencent.com/developer/news/837117

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

前言

Session

Cookie + Session

demo

Session + Header认证

demo

Token 认证

demo

JWT原理：

JWT 注销

Token 过期⏰。

我还是想注销

Session 和 JWT

服务器托管，北京服务器托管，服务器租用，机房机柜带宽租用