devbox
Li_阴宅
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

会话技术------Cookie、Session、Token（JWT）详解_token 会话

作者：Li_阴宅 | 2024-06-19 22:47:23

赞

踩

token 会话

引言

会话技术概述

用户打开浏览器，访问站点服务器，连续操作(连续的访问站点服务器web资源)，直到关闭浏览器，这个整个过程就叫做会话。会话技术是一种在网络通信中用于跟踪用户状态的机制，它可以让服务器在处理用户请求时保持特定用户的状态信息，从而实现个性化的服务和用户体验。

会话技术的由来与发展历程

HTTP 协议是一种无状态协议，每个请求都是相互独立的，服务器无法直接识别来自同一个用户的连续请求。这导致了一些问题，例如无法跟踪和管理用户状态信息、无法提供个性化服务等。所以服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。于是会话技术就应运而生了。

为了解决这些问题，人们开始探索如何实现会话管理。最初的方案是基于 Cookie 的会话管理。Cookie 是一种在客户端存储数据的机制，服务器可以在响应中设置 Cookie，然后在后续的请求中读取 Cookie。通过将会话标识符（Session ID）存储在 Cookie 中，服务器能够识别特定用户的请求并保持其状态信息。Cookie 在浏览器中存储，可以设置过期时间，也可以通过设置路径和域名来限制 Cookie 的范围。

为了更好地管理会话，开发人员开始使用服务器端的会话存储来替代完全依赖于 Cookie。这就是 Session-Based Session 技术（Session技术）。服务器会为每个会话分配一个唯一的 Session ID，并将该 ID 存储在服务器端的会话存储中，而不是直接依赖于客户端的 Cookie。客户端的 Cookie 只包含 Session ID，服务器通过 Session ID 来查找对应的会话数据。这样可以增加对会话的控制和安全性，但需要在服务器端维护会话存储。

随着移动设备和分布式系统的兴起，无状态会话管理变得更加重要。Token-Based Session 技术（Token技术）应运而生。在这种技术中，服务器使用 Token（令牌）来表示会话状态。当用户登录成功后，服务器生成一个加密的 Token，并将其发送给客户端。客户端在后续的请求中将 Token 带上，服务器通过解析和验证 Token 来识别和管理会话。由于 Token 是无状态的，服务器不需要维护会话存储，可以更好地适应分布式环境。

什么是Cookie

Cookie是一种在客户端（通常是Web浏览器）和服务器之间传输的小型文本文件。它由服务器通过HTTP响应的头部设置，并存储在客户端的浏览器中。当客户端发送后续请求时，会将该Cookie信息包含在HTTP请求头中发送给服务器。

Cookie认证流程

Cookie认证流程通常包括以下步骤：

  1. 用户访问需要身份验证的网站。如果用户未经过身份验证，则服务器将重定向用户到登录页面。
  2. 用户输入用户名和密码，发送Http请求传递给服务器进行验证。
  3. 服务器验证用户的凭据，并创建一个会话来保存用户的身份验证状态。在这个过程中，服务器生成一个唯一的标识符Session ID，并将其存储在服务器端。
  4. 服务器将Session ID发送到客户端的浏览器中，通常是将Cookie放在Http请求响应的请求头中，在请求头中有一系列的以Set-Cookie为键的键值对，在这些键值对中包含有Session ID、到期日期、作用域和有效时间等信息。
  5. 当用户发送后续请求时，浏览器会将Session ID作为Cookie的一部分自动包含在HTTP请求头中。
  6. 服务器解析请求头中的Session ID，并将Cookie中的Session ID与数据库中的Session进行比较以验证用户的有效性。
  7. 如果会话ID有效且相关联的身份验证状态信息表明用户已经通过身份验证，则服务器可以允许请求并提供所需的响应。否则，服务器可能会拒绝请求或重定向用户到登录页面以重新验证。

下面是Cookie认证流程图

代码测试

  1. package com.kjz;
  2.  
  3. import com.kjz.pojo.Result;
  4. import lombok.extern.slf4j.Slf4j;
  5. import org.springframework.web.bind.annotation.GetMapping;
  6. import org.springframework.web.bind.annotation.RestController;
  7.  
  8. import javax.servlet.http.Cookie;
  9. import javax.servlet.http.HttpServletRequest;
  10. import javax.servlet.http.HttpServletResponse;
  11. import javax.servlet.http.HttpSession;
  12.  
  13. /**
  14.  * HttpCookie演示
  15.  */
  16. @Slf4j
  17. @RestController
  18. public class SessionController {
  19.  
  20.     //设置Cookie
  21.     @GetMapping("/c1")
  22.     public Result cookie1(HttpServletResponse response){
  23.         response.addCookie(new Cookie("login_username","kjz")); //设置Cookie/响应Cookie
  24.         return Result.success();
  25.     }
  26.  
  27.     //获取Cookie
  28.     @GetMapping("/c2")
  29.     public Result cookie2(HttpServletRequest request){
  30.         Cookie[] cookies = request.getCookies();
  31.         for (Cookie cookie : cookies) {
  32.             if(cookie.getName().equals("login_username")){
  33.                 System.out.println("login_username: "+cookie.getValue()); //输出name为login_username的cookie
  34.             }
  35.         }
  36.         return Result.success();
  37.     }
  38.  
  39.     }
  40. }

A.访问 c1 接口，设置Cookie ，http://localhost:8080/c1

 我们可以看到，设置的cookie，通过响应头Set-Cookie响应给浏览器，并且浏览器会将Cookie，存储在浏览器端。

B. 访问c2接口 http://localhost:8080/c2，此时浏览器会自动的将Cookie携带到服务端，是通过请求头Cookie，携带的

优缺点

  • 优点：HTTP协议中支持的技术（像Set-Cookie 响应头的解析以及 Cookie 请求头数据的携带，都是浏览器自动进行的，是无需我们手动操作的）

  • 缺点：

    • 移动端APP(Android、IOS)中无法使用Cookie

    • 不安全，用户可以自己禁用Cookie

    • Cookie不能跨域

Session

什么是Session

Session是一种在Web应用程序中跨请求保持用户状态的机制。

Session是一段服务器上的存储区域，用于存储用户信息和状态。当用户第一次访问Web应用程序时，服务器会创建一个Session，并给它分配一个唯一的标识符（session ID），然后将该标识符发送给客户端。客户端收到session ID后，通常会将其存储在cookie中，以便后续请求时将其发送回服务器。服务器通过session ID可以找到对应的Session，并从中读取或修改用户信息和状态。session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中

Session认证流程

  • session 认证流程：
    • 用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
    • 请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
    • 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
    • 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

以下是流程图：

代码测试

  1. package com.kjz;
  2.  
  3. import com.kjz.pojo.Result;
  4. import lombok.extern.slf4j.Slf4j;
  5. import org.springframework.web.bind.annotation.GetMapping;
  6. import org.springframework.web.bind.annotation.RestController;
  7.  
  8. import javax.servlet.http.Cookie;
  9. import javax.servlet.http.HttpServletRequest;
  10. import javax.servlet.http.HttpServletResponse;
  11. import javax.servlet.http.HttpSession;
  12.  
  13. /**
  14.  * HttpSession演示
  15.  */
  16. @Slf4j
  17. @RestController
  18. public class SessionController {
  19.  
  20.     @GetMapping("/s1")
  21.     public Result session1(HttpSession session){
  22.         log.info("HttpSession-s1: {}", session.hashCode());
  23.  
  24.         session.setAttribute("loginUser", "tom"); //往session中存储数据
  25.         return Result.success();
  26.     }
  27.  
  28.     @GetMapping("/s2")
  29.     public Result session2(HttpServletRequest request){
  30.         HttpSession session = request.getSession();
  31.         log.info("HttpSession-s2: {}", session.hashCode());
  32.  
  33.         Object loginUser = session.getAttribute("loginUser"); //从session中获取数据
  34.         log.info("loginUser: {}", loginUser);
  35.         return Result.success(loginUser);
  36.     }
  37. }

A. 访问 s1 接口，http://localhost:8080/s1

请求完成之后，在响应头中，就会看到有一个Set-Cookie的响应头，里面响应回来了一个字符串，就是JSESSIONID，这个就是服务端会话对象 Session 的ID。

Session ID被存储在浏览器的Cookie中。

B. 访问 s2 接口，http://localhost:8080/s2

接下来，在后续的每次请求时，都会将Cookie的值，携带到服务端，那服务端呢，接收到Cookie之后，会自动的根据JSESSIONID的值，找到对应的会话对象Session。

两次请求，获取到的Session会话对象的hashcode是一样的，就说明是同一个会话对象。而且，第一次请求时，往Session会话对象中存储的值，第二次请求时，也获取到了。 那这样，我们就可以通过Session会话对象，在同一个会话的多次请求之间来进行数据共享了。

优缺点

  • 优点：Session是存储在服务端的，安全

  • 缺点：

    • 服务器集群环境下无法直接使用Session

    • 移动端APP(Android、IOS)中无法使用Cookie

    • 用户可以自己禁用Cookie

    • Cookie不能跨域

Cookie与Session的区别和联系

区别

  • 安全性： Session 比 Cookie 安全，Session的用户信息 是存储在服务器端的，浏览器端只会存储SessionId，Cookie则将用户信息存储在浏览器端的。
  • 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
  • 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
  • 数据存储：
  1. Cookie：Cookie是以键值对的形式存储在客户端的文本文件中。每个Cookie都有名称、值、过期时间、域名等属性。Cookie的数据容量通常有限制，一般为几KB。
  2. Session：Session将用户状态数据存储在服务器端的内存或数据库中。因此，Session可以存储更大量的数据，并且不受Cookie容量限制。
  • 生命周期：
  1. Cookie：可以设置Cookie的过期时间，在过期时间之前，Cookie会一直保留在客户端，除非被删除或过期。
  2. Session：Session的生命周期由服务器控制，通常在用户关闭浏览器或一段时间不活动后过期。过期后，服务器会清理掉相应的Session数据。

联系

Cookie和Session通常是结合使用的。服务器使用Session来管理用户的状态和敏感信息，而将Session ID存储在Cookie中发送给客户端。客户端在后续的请求中会自动携带Cookie中的Session ID，服务器通过Session ID来识别和恢复对应的Session，从而实现跨请求的状态保持。

Token

什么是Token

作为计算机术语时，是“令牌”的意思。Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。

token其实说的更通俗点可以叫暗号，在一些数据传输之前，要先进行暗号的核对，不同的暗号被授权不同的数据操作。说白了token是一个身份卡，有权限的作用。例如在USB1.1协议中定义了4类数据包：token包、data包、handshake包和special包。主机和USB设备之间连续数据的交换可以分为三个阶段，第一个阶段由主机发送token包，不同的token包内容不一样（暗号不一样）可以告诉设备做不同的工作，第二个阶段发送data包，第三个阶段由设备返回一个handshake包。

Token的分类

在Web应用程序中，有各种类型的Token用于身份验证和授权。以下是一些常见的Token类型：

  • 访问令牌（Access Token）：用于访问受保护的资源，通常用于OAuth 2.0授权框架中。当用户通过认证服务器获得授权后，会收到一个访问令牌，该令牌可以被发送到资源服务器以获取受保护资源。

  • 刷新令牌（Refresh Token）：用于获取新的访问令牌，通常也用于OAuth 2.0授权框架中。刷新令牌可以用来获取新的访问令牌，以避免用户需要重新进行认证流程。

  • JSON Web Token（JWT）：一种开放标准（RFC 7519），用于在各方之间安全地传输信息。JWT通常被用作访问令牌，它包含了被加密的用户信息和其他元数据，可以被用于身份验证和授权。

  • ID令牌（ID Token）：也通常用于OAuth 2.0认证框架中，用于向客户端提供已认证用户的身份信息。ID令牌通常被用于OpenID Connect协议中。

  • CSRF令牌（Cross-Site Request Forgery Token）：用于防止跨站请求伪造攻击。CSRF令牌通常是一个随机生成的值，它会被包含在表单提交中，服务器会验证该令牌以确定请求是否合法。

  • 身份令牌（Identity Token）：用于表示用户的身份信息，通常在身份验证过程中使用。

下面详细介绍一下Access Token和Refresh Token这两者常见的令牌

Access Token

Access Token（访问令牌）是OAuth 2.0授权框架中的一种令牌类型，用于标识和验证客户端的访问权限。在OAuth 2.0认证流程中，用户通过认证服务器进行身份验证后，会获得一个Access Token，然后将该Token用于访问受保护的资源服务器。

Token认证流程:

  • 客户端使用用户名跟密码请求登录
  • 服务端收到请求，去验证用户名与密码
  • 验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
  • 客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
  • 客户端每次向服务端请求资源的时候需要带着服务端签发的 token
  • 服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据

  • 每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
  • 基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库
  • token 完全由应用管理，所以它可以避开同源策略

Refresh Token

Refresh Token（刷新令牌）是OAuth 2.0授权框架中的一种令牌类型，用于获取新的Access Token（访问令牌），以避免用户需要重新进行认证流程。在OAuth 2.0授权流程中，Refresh Token通常是在用户通过认证服务器进行身份验证后，一并返回给客户端的。

特点：

  • 生命周期较长：相对于Access Token而言，Refresh Token的生命周期较长，可以用来获取多个Access Token，以延长用户的认证状态。

  • 不包含用户信息：Refresh Token通常不包含任何用户信息，只包含用于获取新Access Token的信息，如客户端ID、密钥、过期时间等。

  • 需要安全存储：由于Refresh Token可以用来获取新的Access Token，因此需要被妥善保管，并且在传输过程中需要采用加密等安全措施。

工作流程：

  1. 用户在客户端进行OAuth 2.0授权流程，通过认证服务器进行身份验证，获取Access Token和Refresh Token。

  2. 客户端在后续的请求中使用Access Token进行API访问，当Access Token过期时，客户端会使用Refresh Token向认证服务器请求新的Access Token。

  3. 认证服务器收到Refresh Token，并验证其有效性和权限，如果验证通过，则生成并返回新的Access Token。

  4. 客户端使用新的Access Token进行后续的API访问，直到新的Access Token过期或者再次使用Refresh Token获取新的Access Token。

使用注意点

Refresh Token可以避免用户频繁进行认证流程，提高用户体验。但是它也需要被妥善保管，以避免被恶意利用。在使用Refresh Token时，需要注意以下几点：

  • 安全存储：Refresh Token应该被安全地存储，通常建议使用加密等技术保护其安全性。

  • 过期时间控制：Refresh Token应该具有一定的过期时间，并且客户端需要及时更新Refresh Token，以避免过期而导致无法获取新的Access Token。

  • 权限控制：Refresh Token应该和Access Token一样，具有权限控制机制，确保只有拥有合法Refresh Token的客户端才能获取新的Access Token。

下面是工作流程图：

优缺点

  • 优点：

    • 支持PC端、移动端

    • 解决集群环境下的认证问题

    • 减轻服务器的存储压力（无需在服务器端存储）

    • 服务端无状态化、可扩展性好

  • 缺点：需要自己实现（包括令牌的生成、令牌的传递、令牌的校验）

JWT

前面介绍了基于令牌技术来实现会话追踪。这里所提到的令牌就是用户身份的标识，其本质就是一个字符串。令牌的形式有很多，接下来介绍一下一种实现方案：功能强大的 JWT令牌。

介绍

JWT全称：JSON Web Token （官网：JSON Web Tokens - jwt.io）

  • 定义了一种简洁的、自包含的格式，用于在通信双方以json数据格式安全的传输信息。由于数字签名的存在，这些信息是可靠的。

    简洁：是指jwt就是一个简单的字符串。可以在请求参数或者是请求头当中直接传递。

    自包含：指的是jwt令牌，看似是一个随机的字符串，但是我们是可以根据自身的需求在jwt令牌中存储自定义的数据内容。如：可以直接在jwt令牌中存储用户的相关信息。

    简单来讲，jwt就是将原始的json数据格式进行了安全的封装，这样就可以直接基于jwt在通信双方安全的进行信息传输了。

JWT的组成： （JWT令牌由三个部分组成，三个部分之间使用英文的点来分割）

  • 第一部分：Header(头）， 记录令牌类型、签名算法等。 例如：{"alg":"HS256","type":"JWT"}

  • 第二部分：Payload(有效载荷），携带一些自定义信息、默认信息等。 例如：{"id":"1","username":"Tom"}

  • 第三部分：Signature(签名），防止Token被篡改、确保安全性。将header、payload，并加入指定秘钥，通过指定签名算法计算而来。

    签名的目的就是为了防jwt令牌被篡改，而正是因为jwt令牌最后一个部分数字签名的存在，所以整个jwt 令牌是非常安全可靠的。一旦jwt令牌当中任何一个部分、任何一个字符被篡改了，整个令牌在校验的时候都会失败，所以它是非常安全可靠的。

JWT是如何将原始的JSON格式数据，转变为字符串的呢？

其实在生成JWT令牌时，会对JSON格式的数据进行一次编码：进行base64编码

Base64：是一种基于64个可打印的字符来表示二进制数据的编码方式。既然能编码，那也就意味着也能解码。所使用的64个字符分别是A到Z、a到z、 0- 9，一个加号，一个斜杠，加起来就是64个字符。任何数据经过base64编码之后，最终就会通过这64个字符来表示。当然还有一个符号，那就是等号。等号它是一个补位的符号。

需要注意的是Base64是编码方式，而不是加密方式。

JWT的生成和校验

下面说一下基于java代码如何生成和校验JWT令牌

首先我们先来实现JWT令牌的生成。要想使用JWT令牌，需要先引入JWT的依赖：

  1. <!-- JWT依赖-->
  2. <dependency>
  3.     <groupId>io.jsonwebtoken</groupId>
  4.     <artifactId>jjwt</artifactId>
  5.     <version>0.9.1</version>
  6. </dependency>

然后通过调用工具包中提供的API来完成JWT令牌的生成和校验

工具类：JWTUtils

  1. public class JWTUtils {
  2.  
  3.     private static String signKey = "kjzshicaibi";//签名密钥
  4.     private static Long expire = 43200000L; //有效时间
  5.  
  6.     /**
  7.      * 生成JWT令牌
  8.      * @param claims JWT第二部分负载 payload 中存储的内容
  9.      * @return
  10.      */
  11.     public static String generateJwt(Map<String, Object> claims){
  12.         String jwt = Jwts.builder()
  13.                 .addClaims(claims)//自定义信息（有效载荷）
  14.                 .signWith(SignatureAlgorithm.HS256, signKey)//签名算法（头部）
  15.                 .setExpiration(new Date(System.currentTimeMillis() + expire))//过期时间
  16.                 .compact();
  17.         return jwt;
  18.     }
  19.  
  20.     /**
  21.      * 解析JWT令牌
  22.      * @param jwt JWT令牌
  23.      * @return JWT第二部分负载 payload 中存储的内容
  24.      */
  25.     public static Claims parseJWT(String jwt){
  26.         Claims claims = Jwts.parser()
  27.                 .setSigningKey(signKey)//指定签名密钥
  28.                 .parseClaimsJws(jwt)//指定令牌Token
  29.                 .getBody();
  30.         return claims;
  31.     }
  32. }

通过测试类进行测试

JWT生成：

  1.     /**
  2.      * 生成JWT
  3.      */
  4.     @Test
  5.     public void testGenJwt(){
  6.         Map<String, Object> claims = new HashMap<>();
  7.         claims.put("id",1);
  8.         claims.put("name","tom");
  9.         String jwt = JwtUtils.generateJwt(claims);
  10.         System.out.println(jwt);
  11.     }

输出结果为

输出的结果就是生成的JWT令牌,，通过英文的点分割对三个部分进行分割，我们可以将生成的令牌复制一下，然后打开JWT的官网，将生成的令牌直接放在Encoded位置，此时就会自动的将令牌解析出来。

第一部分解析出来，看到JSON格式的原始数据，所使用的签名算法为HS256。

第二个部分是我自定义的数据，之前我们自定义的数据就是id，还有一个exp代表的是我所设置的过期时间。

由于前两个部分是base64编码，所以是可以直接解码出来。但最后一个部分并不是base64编码，是经过签名算法计算出来的，所以最后一个部分是不会解析的。

另外在这里插一嘴，我调试的过程中出现了以下的bug

产生错误原因：生成JWT的密钥signKey字符串过短引起的异常。

解决方法：尽量将signKey字符串设置长。

之前设置signKey字符串仅仅3个字母字符串 "kjz",现在修改为"kjzshicaibi"

解析JWT：

  1.  @Test
  2.     public void testParseJwt(){
  3.         Claims claims = JwtUtils.parseJWT("eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoidG9tIiwiaWQiOjEsImV4cCI6MTcwMDgzMzkyN30.tF3EmoKNR5PE-vVZcv0VKgpiaaVgp-mYtkqpBVRbtF4");
  4.         System.out.println(claims);
  5.     }

输出结果

JWT认证流程

  1. 用户向服务器发送凭据（例如用户名和密码）以进行身份验证。
  2. 服务器验证用户提供的凭据。如果凭据有效，则服务器生成一个JWT，并将其作为响应返回给客户端。
  3. 客户端收到JWT后，将其存储在本地，通常是在浏览器的Cookie或本地存储中。
  4. 客户端在后续请求中将JWT作为身份验证凭据包含在HTTP请求头中，键值对如下（Authorization: Bearer <JWT>）
  5. 服务器接收到带有JWT的请求后，会对JWT进行验证，确保它是由服务器签发的有效令牌。
  6. 如果JWT验证成功且未过期，服务器将处理请求并提供所需的响应。服务器可以从JWT中获取附加的声明信息，如用户ID、角色等，以进行授权和个性化操作。
  7. 如果JWT验证失败或已过期，服务器会拒绝请求或要求客户端重新进行身份验证。

流程图如下

下面是JWT运用到登录场景的一个例子

1.引入JWT工具类

这里的工具类与上面提到的一致就不重复引用了。

2.登录完成后，调用工具类生成JWT令牌并返回

  1. @RestController
  2. @Slf4j
  3. public class LoginController {
  4.     //依赖业务层对象
  5.     @Autowired
  6.     private EmpService empService;
  7.  
  8.     @PostMapping("/login")
  9.     public Result login(@RequestBody Emp emp) {
  10.         //调用业务层：登录功能
  11.         Emp loginEmp = empService.login(emp);
  12.  
  13.         //判断：登录用户是否存在
  14.         if(loginEmp !=null ){
  15.             //自定义信息
  16.             Map<String , Object> claims = new HashMap<>();
  17.             claims.put("id", loginEmp.getId());
  18.             claims.put("username",loginEmp.getUsername());
  19.             claims.put("name",loginEmp.getName());
  20.  
  21.             //使用JWT工具类，生成身份令牌
  22.             String token = JwtUtils.generateJwt(claims);
  23.             return Result.success(token);
  24.         }
  25.         return Result.error("用户名或密码错误");
  26.     }
  27. }

利用开发者工具，抓取一下网络请求

登录请求完成后，可以看到JWT令牌已经响应给了前端，此时前端就会将JWT令牌存储在浏览器本地。

服务器响应的JWT令牌存储在本地浏览器哪里了呢？

  • 在当前案例中，JWT令牌存储在浏览器的本地存储空间Local Storage中了。 Local Storage是浏览器的本地存储，在移动端也是支持的。

之后再发起一个查询数据的请求，此时可以看到在请求头中包含一个token(JWT令牌)，后续的每一次请求当中，都会将这个令牌携带到服务端。

注意此处我是在前端发请求时自定义了一个名为token的键值对，将JWT放在这个键值对中。一般情况下，默认都是把token放在Authorization的键值对中。

写到此处我的心中又产生了一个问题，为什么要把JWT放在请求头中而不是请求行、请求体中呢

放在请求头中的原因：

安全性：

      将JWT放在请求头中可以避免敏感信息被记录在URL中或者浏览器历史记录中。这是因为，请求头中的内容不会自动包含在浏览器历史记录中，也不会自动写入Web服务器的访问日志文件中，从而增加了身份验证信息的安全性。

标准化：

      将JWT放在请求头中符合HTTP协议规范。HTTP协议定义了请求行（包括方法、URI和协议版本）和请求头两个部分，其中请求头用于传递一些附加的信息，比如身份验证信息、请求正文类型等。因此，将JWT放在请求头中符合HTTP协议的设计理念，而将它放在请求行或请求体中可能会导致与HTTP协议不兼容的问题。

      将JWT放在请求头中也方便了API开发和使用的标准化。HTTP请求头具有标准的格式和语法，这使得API的开发和使用更加规范和易于实现。相比之下，将JWT放在请求行或者请求体中，可能会需要开发人员自己定义格式和语法，这会增加开发和使用的成本和风险

不放在请求行中的原因

安全性问题：

    请求行通常会被记录在服务器的访问日志中，也可能会被缓存或代理服务器记录下来。如果将JWT放在请求行中，就会将敏感的身份验证信息暴露在这些记录中，增加了被恶意利用的风险。

长度限制：

    请求行的长度是有限制的，根据HTTP协议规范，请求行的总长度（包括方法、URI和协议版本等）应该不能超过几千个字节（不同的浏览器配置不同）。如果将JWT放在请求行中，可能会导致JWT太长而无法满足长度限制，导致请求失败或被截断。

处理复杂：

    请求行的解析和处理通常由HTTP服务器或客户端库自动完成。将JWT放在请求行中可能会导致服务器或库无法正确解析请求行，需要进行额外的处理和解析逻辑，增加了开发和维护的复杂性

不放在请求体中的原因

安全性问题：

     请求体通常会被缓存、记录在服务器的日志中、传输到代理服务器中等。将JWT放在请求体中可能会将敏感信息暴露在这些记录和传输中，增加安全风险。

兼容性问题：

    有些浏览器或客户端可能无法正确处理带有请求体的HTTP请求，或者在处理请求体时出现问题。这可能导致请求失败或出现其他错误。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/Li_阴宅/article/detail/737835
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号