关于springboot:一文搞懂Session和JWT登录认证

前言

目前在开发的小组结课我的项目中用到了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:


        <dependency>
            <groupId>org.springframework.session</groupId>
            <artifactId>spring-session</artifactId>
            <version>1.3.5.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>

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:

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>

写一个工具类

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

关于springboot:一文搞懂Session和JWT登录认证

前言

Session

Cookie + Session

demo

Session + Header认证

demo

Token 认证

demo

JWT原理：

JWT 登记

Token 过期⏰。

我还是想登记

Session 和 JWT

评论

发表回复取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

关于springboot:一文搞懂Session和JWT登录认证

前言

Session

Cookie + Session

demo

Session + Header认证

demo

Token 认证

demo

JWT原理：

JWT 登记

Token 过期⏰。

我还是想登记

Session 和 JWT

评论

发表回复 取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

发表回复取消回复