Cookie、Session、Token、JWT的区别

先总结

其实比较的话就只是Session、Token、JWT的区别，Session是基于Cookie的

这里暂时只比较Session和JWT的区别

1. 存放位置不同

• Session基于Cookie存储在服务端
• JWT存放在客户端，通常是在浏览器的Cookie或LocalStorage中。

JWT将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自己包含了用户信息和加密的数据。

2. 存放用户信息位置不同

• 基于session，用户信息存放在session里，在分布式下，是需要使用一个数据库（redis）存放共用的session信息的。

• 基于jwt，因为用户信息都在jwtToken里，所以直接解析就能获取用户信息，不需要查询任何数据库。

3. 跨域问题

因为 JWT 并不依赖 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）

4. 扩展性

• Token 机制是无状态的，每个请求都包含足够的信息，服务器不需要存储 session 数据，适合分布式系统和微服务架构。
• Session是基于服务器的，所以当数据量大的话是需要扩展的，JWT不需要考虑这个问题

5. 注销机制

Session可以通过服务器端的操作来注销，而JWT由于其无状态的特性，不支持传统意义上的注销

6. 性能

• 由于JWT包含所有必要的信息，减少了服务器查询数据库的次数，这可能提高性能。然而，如果JWT过长，可能会增加HTTP请求的大小，影响性能。

• JWT 的验证过程相对简单，只需要对 JWT 进行数字签名验证即可。此外，由于 JWT 是无状态的，服务器不需要在内存中存储用户的会话信息，因此可以减少服务器的内存开销。

例如，在高并发的场景下，使用 JWT 可以减少服务器的负载，提高系统的性能。

• Session 的验证过程需要在服务器端查找用户的会话信息，这可能会导致一定的性能开销。此外，如果服务器需要存储大量的会话信息，也会占用较多的内存资源。

例如，在高并发的场景下，如果服务器需要处理大量的用户请求，并且每个请求都需要查找用户的会话信息，这可能会导致服务器的性能下降。

• 网络传输

  • session 都需要传输 sessionId，是很短的一串字符。
  • jwt 都需要传输 jwtToken，是很长的一串字符。

7. 适用场景

• JWT：

适用于前后端分离的应用、微服务架构、移动应用等场景。在这些场景中，客户端和服务器之间的通信通常是通过 HTTP 协议进行的，并且客户端需要在不同的设备和平台上运行。使用 JWT 可以方便地在不同的设备和平台之间传递用户的状态信息，并且无需考虑会话复制或共享的问题。

例如，在一个前后端分离的电商应用中，前端可以使用 JWT 来验证用户的身份，并在每次请求时将 JWT 发送给后端服务器。后端服务器可以使用 JWT 来验证用户的身份，并根据用户的权限返回相应的响应数据。

• Session：

适用于传统的 Web 应用、企业内部应用等场景。在这些场景中，客户端和服务器之间的通信通常是在同一个局域网内进行的，并且服务器的负载相对较低。使用 Session 可以方便地管理用户的状态信息，并且可以利用服务器的内存来存储会话信息，提高系统的性能。

例如，在一个企业内部的办公自动化系统中，用户可以通过浏览器访问系统，并且系统需要记录用户的登录状态、权限信息等。使用 Session 可以方便地实现这些功能，并且可以利用服务器的内存来存储会话信息，提高系统的性能。

其他，等面试问到再说

有效期：Session的有效期通常由服务器控制，而JWT的有效期可以在令牌生成时设置，并且可以在客户端进行缓存和重复使用。
适用场景：Session适用于传统的Web应用程序，而JWT更适合现代的分布式应用程序和API。
一次性使用：JWT适合用于一次性操作的认证，如一次性授权Token，而Session更适合需要频繁交互和状态管理的场景。

复杂性:需要处理 Token 的生成、存储、过期和刷新，可能比 Session 实现要复杂。

JWT 有很好的使用场景，但它们不适合作为会话机制。JWT特别有效的用例通常是被用作用户一次性授权令牌。
JWT用作会话，则需要返回access_token 和 refresh_token。前者短有效期，后者长有效期。这在原来的JWT基础上扩展，使JWT适用于作为会话。

JWT无法失效的问题

无法失效: Token 一旦生成，在有效期内都有效，无法像 Session 那样容易地失效或撤销。需要实现刷新 Token 机制来处理 Token 过期问题。

在使用 JSON Web Token（JWT）的系统中，实现注销功能相对传统的基于会话的认证方式要复杂一些，因为 JWT 一旦签发，在有效期内会一直存在，后端无法直接使一个已签发的 JWT 失效。但是，可以通过以下几种方式来实现类似注销的效果：

一、设置短有效期

在生成 JWT 时，将其有效期设置得相对较短。这样，即使用户不主动注销，JWT 也会在较短的时间后自动过期，降低了安全风险。
例如，在 Java 中使用 jjwt 库时，可以这样设置较短的过期时间：

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;

public class UserService {
    public static String generateJwt(String userId, String username) {
        String secretKey = "your_secret_key";
        long expirationTime = 600000; // 10 分钟后过期
        Date expirationDate = new Date(System.currentTimeMillis() + expirationTime);

        Map<String, Object> claims = new HashMap<>();
        claims.put("sub", userId);
        claims.put("name", username);

        return Jwts.builder()
              .setClaims(claims)
              .setIssuedAt(new Date())
              .setExpiration(expirationDate)
              .signWith(SignatureAlgorithm.HS256, secretKey)
              .compact();
    }
}

二、在后端维护已注销的令牌列表

当用户注销时，将用户的 JWT 存储在后端的一个已注销令牌列表中，比如存储在数据库或内存中。

在每次请求到来时，除了验证 JWT 的签名和过期时间等常规操作外，还检查该 JWT 是否在已注销令牌列表中。如果在列表中，则拒绝该请求。

import java.util.ArrayList;
import java.util.List;

public class LogoutService {
    private static List<String> revokedTokens = new ArrayList<>();

    public static void addRevokedToken(String token) {
        revokedTokens.add(token);
    }

    public static boolean isTokenRevoked(String token) {
        return revokedTokens.contains(token);
    }
}

在验证 JWT 的过滤器或中间件中：

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jwts;

import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.Date;

public class JwtAuthenticationFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws ServletException, IOException {
        String jwtToken = extractJwtFromRequest(request);
        if (jwtToken!= null &&!jwtToken.isEmpty()) {
            try {
                String secretKey = "your_secret_key";
                Claims claims = Jwts.parser()
                      .setSigningKey(secretKey)
                      .parseClaimsJws(jwtToken)
                      .getBody();

                Date expirationDate = claims.getExpiration();
                if (expirationDate.after(new Date()) &&!LogoutService.isTokenRevoked(jwtToken)) {
                    // JWT 有效，可以从 claims 中获取用户信息并设置到请求中，以便后续处理使用
                    request.setAttribute("userId", claims.get("sub"));
                    request.setAttribute("username", claims.get("name"));
                } else {
                    response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Token has expired or is revoked.");
                    return;
                }
            } catch (Exception e) {
                response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Invalid token.");
                return;
            }
        } else {
            response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Missing token.");
            return;
        }

        filterChain.doFilter(request, response);
    }

    private String extractJwtFromRequest(HttpServletRequest request) {
        String authHeader = request.getHeader("Authorization");
        if (authHeader!= null && authHeader.startsWith("Bearer ")) {
            return authHeader.substring(7);
        }
        return null;
    }
}

三、强制用户重新登录
当用户注销时，让前端清除存储的 JWT。然后，当用户再次尝试访问需要认证的资源时，由于没有有效的 JWT，将被重定向到登录页面，强制用户重新登录以获取新的 JWT。

例如，在前端 JavaScript 中，可以这样处理：

// 注销时清除存储的 JWT
localStorage.removeItem('jwtToken');

认证和授权

认证就是让服务器知道你是谁，授权就是服务器让你知道你什么能干，什么不能干，
认证（Authentication）

通俗地讲就是验证当前用户的身份，证明“你是你自己”（比如：你每天上下班打卡，都需要通过指纹打卡，当你的指纹和系统里录入的指纹相匹配时，就打卡成功）

互联网中的认证：

• 用户名密码登录
• 邮箱发送登录链接
• 手机号接收验证码
  只要你能收到邮箱/验证码，就默认你是账号的主人

授权（Authorization）

用户授予第三方应用访问该用户某些资源的权限

你在安装手机应用的时候，APP 会询问是否允许授予权限（访问相册、地理位置等权限）

你在访问微信小程序时，当登录时，小程序会询问是否允许授予权限（获取昵称、头像、地区、性别等个人信息）

实现授权的方式有：cookie、session、token、OAuth

除了这种授权还有一种权限的概念，就简单的理解为不同的角色有不同的权限。

凭证（Credentials）

实现认证和授权的前提是需要一种媒介（证书） 来标记访问者的身份

在互联网应用中，一般网站（如掘金）会有两种模式，游客模式和登录模式。游客模式下，可以正常浏览网站上面的文章，一旦想要点赞/收藏/分享文章，就需要登录或者注册账号。当用户登录成功后，服务器会给该用户使用的浏览器颁发一个令牌（token），这个令牌用来表明你的身份，每次浏览器发送请求时会带上这个令牌，就可以使用游客模式下无法使用的功能。

Cookie和Session

HTTP 是无状态的协议（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）：每个请求都是完全独立的，服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。

所以服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态需要通过 cookie 或者 session 去实现。

cookie 存储在客户端：cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。

cookie 是不可跨域的：每个 cookie 都会绑定单一的域名，无法在别的域名下获取使用，一级域名和二级域名之间是允许共享使用的（靠的是 domain）。

session 是另一种记录服务器和客户端会话状态的机制

session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中

session 认证流程：

1. 用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器

2. 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名

3. 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

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

1. 存储位置不同
   cookie的数据信息存放在客户端浏览器上
   session的数据信息存放在服务器上
2. 存储容量不同
   单个cookie保存的数据<=4KB，一个站点最多保存20个Cookie
   对于session来说并没有上限，但出于对服务器端的性能考虑，session内不要存放过多的东西
3. 隐私策略不同
   cookie对客户端是可见的，别有用心的人可以分析存放在本地的cookie并进行cookie欺骗，所以它是不安全的
   session存储在服务器上，对客户端是透明对，不存在敏感信息泄漏的风险
4. 性能使用不同
   session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用cookie。

Token

Acesss Token

访问资源接口（API）时所需要的资源凭证

简单 token 的组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）

特点：

1. 服务端无状态化、可扩展性好
2. 支持移动端设备
3. 安全
4. 支持跨程序调用

token 的身份验证流程：

1. 客户端使用用户名跟密码请求登录，服务端收到请求，去验证用户名与密码，验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端

2. 客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里；客户端每次向服务端请求资源的时候需要带着服务端签发的 token

3. 服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据

4. 每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
   基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库

5. token 完全由应用管理，所以它可以避开同源策略

Refresh Token
暂时没用到这个，有时间再看它

Token 和 Session 的区别

Session 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。而 Token 是令牌，访问资源接口（API）时所需要的资源凭证。Token 使服务端无状态化，不会存储会话信息。

Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击，而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。

所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SessionID 的不可预测性，暂且认为是安全的。而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App上，也不可以转到其它用户上。

Session 只提供一种简单的认证，即只要有此 SessionID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方 App。所以简单来说：如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。

JWT

JSON Web Token（简称 JWT）是目前最流行的跨域认证解决方案。

是一种认证授权机制。

JWT 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（RFC 7519）。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。

可以使用 HMAC 算法或者是 RSA 的公/私秘钥对 JWT 进行签名。因为数字签名的存在，这些传递的信息是可信的。

JSON Web Token（JWT）是一种开放标准（RFC 7519），它定义了一种紧凑且独立的方式，可以将各方之间的信息作为JSON对象进行安全传输。该信息可以验证和信任，因为是经过数字签名的。

JWT基本上由.分隔的三部分组成，分别是头部，有效载荷和签名。 一个简单的JWT的例子，如下所示：

eyJhbGciOiJIUzI1NiIsInR5cCI6Ik

如果你细致得去看的话会发现其实这是一个分为 3 段的字符串，段与段之间用 “.”【点号】 隔开，在 JWT 的概念中，每一段的名称分别为：

Header.Payload.Signature

在字符串中每一段都是被 base64url 编码后的 JSON，其中 Payload 段可能被加密。

Header

JWT 的 Header 通常包含两个字段，分别是：typ(type) 和 alg(algorithm)。

• typ：token的类型，这里固定为 JWT
• alg：使用的 hash 算法，例如：HMAC SHA256 或者 RSA
  一个简单的例子：

{
      "alg": "HS256",
      "typ": "JWT"
    }

我们对他进行编码后是：

base64.b64encode(json.dumps({“alg”:“HS256”,“typ”:“JWT”}))
‘eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9’

Payload

JWT 中的 Payload 其实就是真实存储我们需要传递的信息的部分，例如正常我们会存储些用户 ID、用户名之类的。此外，还包含一些例如发布人、过期日期等的元数据。

但是，这部分和 Header 部分不一样的地方在于这个地方可以加密，而不是简单得直接进行 BASE64 编码。

Signature

Signature 部分其实就是对我们前面的 Header 和 Payload 部分进行签名，保证 Token 在传输的过程中没有被篡改或者损坏，签名的算法也很简单，但是，为了加密，所以除了 Header 和 Payload 之外，还多了一个密钥字段

JWT 的原理

JWT 认证流程：

1. 用户输入用户名/密码登录，服务端认证成功后，会返回给客户端一个 JWT

2. 客户端将 token 保存到本地（通常使用 localstorage，也可以使用 cookie）

3. 当用户希望访问一个受保护的路由或者资源的时候，需要请求头的 Authorization 字段中使用Bearer 模式添加 JWT，其内容看起来是下面这样

Authorization: Bearer

4. 服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为
   因为 JWT 是自包含的（内部包含了一些会话信息），因此减少了需要查询数据库的需要

因为 JWT 并不使用 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
因为用户的状态不再存储在服务端的内存中，所以这是一种无状态的认证机制

---------------------另一种说法------------------------------------------------------------

工作原理

1.首先，前端通过Web表单将自己的用户名和密码发送到后端的接口。这一过程一般是一个HTTP POST请求。建议的方式是通过SSL加密的传输（https协议），从而避免敏感信息被嗅探。

2.后端核对用户名和密码成功后，将用户的id等其他信息作为JWT Payload（负载），将其与头部分别进行Base64编码拼接后签名，形成一个JWT。形成的JWT就是一个形同http://lll.zzz.xxx的字符串。

3.后端将JWT字符串作为登录成功的返回结果返回给前端。前端可以将返回的结果保存在localStorage或sessionStorage上，退出登录时前端删除保存的JWT即可。

4.前端在每次请求时将JWT放入HTTP Header中的Authorization位。(解决XSS和XSRF问题)

5.后端检查是否存在，如存在验证JWT的有效性。例如，检查签名是否正确；检查Token是否过期；检查Token的接收方是否是自己（可选）。

6.验证通过后后端使用JWT中包含的用户信息进行其他逻辑操作，返回相应结果。

JWT 的使用方式
客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

1. 方式一
   当用户希望访问一个受保护的路由或者资源的时候，可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求头信息的 Authorization 字段里，使用 Bearer 模式添加 JWT。

GET /calendar/v1/events
Host: api.example.com
Authorization: Bearer

用户的状态不会存储在服务端的内存中，这是一种 无状态的认证机制

由于 JWT 是自包含的，因此减少了需要查询数据库的需要

JWT 的这些特性使得我们可以完全依赖其无状态的特性提供数据 API 服务，甚至是创建一个下载流服务。

因为 JWT 并不使用 Cookie ，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）

2. 方式二

跨域的时候，可以把 JWT 放在 POST 请求的数据体里。

3. 方式三

通过 URL 传输
http://www.example.com/user?token=xxx

Token 和 JWT 的区别

相同：
都是访问资源的令牌
都可以记录用户的信息
都是使服务端无状态化
都是只有验证成功后，客户端才能访问服务端上受保护的资源

区别：
Token：服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。
JWT：将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。

JWT和Session的区别

可扩展性

随着应用程序的扩大和用户数量的增加，你必将开始水平或垂直扩展。

session数据通过文件或数据库存储在服务器的内存中。在水平扩展方案中，你必须开始复制服务器数据，你必须创建一个独立的中央session存储系统，以便所有应用程序服务器都可以访问。否则，由于session存储的缺陷，你将无法扩展应用程序。

解决这个挑战的另一种方法是使用 sticky session。

你还可以将session存储在磁盘上，使你的应用程序在云环境中轻松扩展。这类解决方法在现代大型应用中并没有真正发挥作用。

建立和维护这种分布式系统涉及到深层次的技术知识，并随之产生更高的财务成本。在这种情况下，使用JWT是无缝的;由于基于token的身份验证是无状态的，所以不需要在session中存储用户信息。

我们的应用程序可以轻松扩展，因为我们可以使用token从不同的服务器访问资源，而不用担心用户是否真的登录到某台服务器上。你也可以节省成本，因为你不需要专门的服务器来存储session。为什么？因为没有session！

注意：如果你正在构建一个小型应用程序，这个程序完全不需要在多台服务器上扩展，并且不需要RESTful API的，那么session机制是很棒的。 如果你使用专用服务器运行像Redis那样的工具来存储session，那么session也可能会为你完美地运作！

安全性

JWT签名旨在防止在客户端被篡改，但也可以对其进行加密，以确保token携带的claim 非常安全。JWT主要是直接存储在web存储（本地/session存储）或cookies中。 JavaScript可以访问同一个域上的Web存储。这意味着你的JWT可能容易受到XSS（跨站脚本）攻击。恶意JavaScript嵌入在页面上，以读取和破坏Web存储的内容。事实上，很多人主张，由于XSS攻击，一些非常敏感的数据不应该存放在Web存储中。一个非常典型的例子是确保你的JWT不将过于敏感/可信的数据进行编码，例如用户的社会安全号码。

最初，我提到JWT可以存储在cookie中。事实上，JWT在许多情况下被存储为cookie，并且cookies很容易受到CSRF（跨站请求伪造）攻击。预防CSRF攻击的许多方法之一是确保你的cookie只能由你的域访问。作为开发人员，不管是否使用JWT，确保必要的CSRF保护措施到位以避免这些攻击。

现在，JWT和session ID也会暴露于未经防范的重放攻击。建立适合系统的重放防范技术，完全取决于开发者。解决这个问题的一个方法是确保JWT具有短期过期时间。虽然这种技术并不能完全解决问题。然而，解决这个挑战的其他替代方案是将JWT发布到特定的IP地址并使用浏览器指纹。

注意：使用HTTPS / SSL确保你的Cookie和JWT在客户端和服务器传输期间默认加密。这有助于避免中间人攻击！

RESTful API服务

现代应用程序的常见模式是从RESTful API查询使用JSON数据。目前大多数应用程序都有RESTful API供其他开发人员或应用程序使用。由API提供的数据具有几个明显的优点，其中之一就是这些数据可以被多个应用程序使用。在这种情况下，传统的使用session和Cookie的方法在用户认证方面效果不佳，因为它们将状态引入到应用程序中。

RESTful API的原则之一是它应该是无状态的，这意味着当发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。保持API无状态，不产生附加影响，意味着维护和调试变得更加容易。

另一个挑战是，由一个服务器提供API，而实际应用程序从另一个服务器调用它的模式是很常见的。为了实现这一点，我们需要启用跨域资源共享（CORS）。Cookie只能用于其发起的域，相对于应用程序，对不同域的API来说，帮助不大。在这种情况下使用JWT进行身份验证可以确保RESTful API是无状态的，你也不用担心API或应用程序由谁提供服务。

性能

对此的批判性分析是非常必要的。当从客户端向服务器发出请求时，如果大量数据在JWT内进行编码，则每个HTTP请求都会产生大量的开销。然而，在会话中，只有少量的开销，因为SESSION ID实际上非常小。看下面这个例子：

JWT有5个claim：

{

  "sub": "1234567890",

  "name": "Prosper Otemuyiwa",

  "admin": true,

  "role": "manager",

  "company": "Auth0"

}

编码时，JWT的大小将是SESSION ID（标识符）的几倍，从而在每个HTTP请求中，JWT比SESSION ID增加更多的开销。而对于session，每个请求在服务器上需要查找和反序列化session。

JWT通过将数据保留在客户端的方式以空间换时间。你应用程序的数据模型是一个重要的影响因素，因为通过防止对服务器数据库不间断的调用和查询来减少延迟。需要注意的是不要在JWT中存储太多的claim，以避免发生巨大的，过度膨胀的请求。

值得一提的是，token可能需要访问后端的数据库。特别是刷新token的情况。他们可能需要访问授权服务器上的数据库以进行黑名单处理。获取有关刷新token和何时使用它们的更多信息。

下游服务

现代web应用程序的另一种常见模式是，它们通常依赖于下游服务。例如，在原始请求被解析之前，对主应用服务器的调用可能会向下游服务器发出请求。这里的问题是，cookie不能很方便地流到下游服务器，也不能告诉这些服务器关于用户的身份验证状态。由于每个服务器都有自己的cookie方案，所以阻力很大，并且连接它们也是困难的。JSON Web Token再次轻而易举地做到了！

实效性

此外，无状态JWT的实效性相比session太差，只有等到过期才可销毁，而session则可手动销毁。

例如有个这种场景，如果JWT中存储有权限相关信息，比如当前角色为 admin，但是由于JWT所有者滥用自身权利，高级管理员将权利滥用者的角色降为 user。但是由于 JWT 无法实时刷新，必需要等到 JWT 过期，强制重新登录时，高级管理员的设置才能生效。

或者是用户发现账号被异地登录，然后修改密码，此时token还未过期，异地的账号一样可以进行操作包括修改密码。

但这种场景也不是没有办法解决，解决办法就是将JWT生成的token存入到redis或者数据库中，当用户登出或作出其他想要让token失效的举动，可通过删除token在数据库或者redis里面的对应关系来解决这个问题。

node中使用JWT

我这个项目中使用的是JWT，使用方法如下：

首先安装JWT库：

npm install jsonwebtoken
然后创建签名数据，生成token：

let jwt = require(‘jsonwebtoken’);

var token = jwt.sign({ name: ‘张三’ }, ‘shhhhh’);
console.log(token);
运行程序可以看到打印出来的内容类似这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoi5byg5LiJIiwiaWF0IjoxNDYyODgxNDM3fQ.uVWC2h0_r1F4FZ3qDLkGN5KoFYbyZrFpRJMONZrJJog
之后，对token字符串，可以这样解码：

let decoded=jwt.decode(token);
console.log(decoded);
将打印出：

{ name: ‘张三’, iat: 1462881437 }
其中iat是时间戳，即签名时的时间（注意：单位是秒）。

不过，一般我们不会使用decode方法，因为它只是简单的对claims部分的做base64解码。

我们需要的是验证claims的内容是否被篡改。

此时我们需要使用verify方法：

let decoded = jwt.verify(token, ‘shhhhh’);
console.log(decoded);
虽然打印出的内容和decode方法是一样的。但是是经过校验的。

我们可以改变校验用的密钥，比如改为shzzzz，使之和加密时的密钥不一致。那么解码就会出现报错：

JsonWebTokenError: invalid signature
我们也可以偷偷修改token的claims或者header部分，会得到这样的报错：

JsonWebTokenError: invalid token
最后，根据自己的需求，决定是否需要将生成的token存入数据库或者redis，但建议不要存储用户密码等敏感信息。

session、cookie、sessionStorage、localstorage的区别

session: 主要存放在服务器端，相对安全
cookie: 可设置有效时间，默认是关闭浏览器后失效，主要存放在客户端，并且不是很安全，可存储大小约为4kb
sessionStorage: 仅在当前会话下有效，关闭页面或浏览器后被清除
localstorage: 除非被清除，否则永久保存

常见问题

Cookie

• 使用 cookie 时需要考虑的问题
  因为存储在客户端，容易被客户端篡改，使用前需要验证合法性

2. 不要存储敏感数据，比如用户密码，账户余额
   使用 httpOnly 在一定程度上提高安全性

3. 尽量减少 cookie 的体积，能存储的数据量不能超过 4kb
   设置正确的 domain 和 path，减少数据传输

4. cookie 无法跨域
   一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie

5. 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

Session

• 将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在服务端定期的去清理过期的 session

• 当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session 是由单个服务器创建的，但是处理用户请求的服务器不一定是那个创建 session 的服务器，那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了。

• 当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好 cookie 跨域的处理。

• sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie 怎么办？一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现

• 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

Token

• 如果你认为用数据库来存储 token 会导致查询时间太长，可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。

• token 完全由应用管理，所以它可以避开同源策略

• token 可以避免 CSRF 攻击(因为不需要 cookie 了)

• 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

JWT

• 因为 JWT 并不依赖 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
• JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
• JWT 不加密的情况下，不能将秘密数据写入 JWT。
• JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
• JWT 最大的优势是服务器不再需要存储 Session，使得服务器认证鉴权业务可以方便扩展。但这也是 JWT 最大的缺点：由于服务器不需要存储 Session 状态，因此使用过程中无法废弃某个 Token 或者更改 Token 的权限。也就是说一旦 JWT 签发了，到期之前就会始终有效，除非服务器部署额外的逻辑。
• JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
• JWT 适合一次性的命令认证，颁发一个有效期极短的 JWT，即使暴露了危险也很小，由于每次操作都会生成新的 JWT，因此也没必要保存 JWT，真正实现无状态。
• 为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

使用加密算法时需要考虑的问题

绝不要以明文存储密码

永远使用 哈希算法 来处理密码，绝不要使用 Base64 或其他编码方式来存储密码，这和以明文存储密码是一样的，使用哈希，而不要使用编码。编码以及加密，都是双向的过程，而密码是保密的，应该只被它的所有者知道， 这个过程必须是单向的。哈希正是用于做这个的，从来没有解哈希这种说法， 但是编码就存在解码，加密就存在解密。

绝不要使用弱哈希或已被破解的哈希算法，像 MD5 或 SHA1 ，只使用强密码哈希算法。

绝不要以明文形式显示或发送密码，即使是对密码的所有者也应该这样。如果你需要 “忘记密码” 的功能，可以随机生成一个新的 一次性的（这点很重要）密码，然后把这个密码发送给用户。

分布式架构下 session 共享方案

session 复制

任何一个服务器上的 session 发生改变（增删改），该节点会把这个 session 的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要 session ，以此来保证 session 同步
优点：可容错，各个服务器间 session 能够实时响应。
缺点：会对网络负荷造成一定压力，如果 session 量大的话可能会造成网络堵塞，拖慢服务器性能。

粘性 session /IP 绑定策略

采用 Ngnix 中的 ip_hash 机制，将某个 ip的所有请求都定向到同一台服务器上，即将用户与服务器绑定。用户第一次请求时，负载均衡器将用户的请求转发到了 A 服务器上，如果负载均衡器设置了粘性 session 的话，那么用户以后的每次请求都会转发到 A 服务器上，相当于把用户和 A 服务器粘到了一块，这就是粘性 session 机制。
优点：简单，不需要对 session 做任何处理。
缺点：缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的 session 信息都将失效。
适用场景：发生故障对客户产生的影响较小；服务器发生故障是低概率事件 。
实现方式：以 Nginx 为例，在 upstream 模块配置 ip_hash 属性即可实现粘性 session。

session 共享（常用）

使用分布式缓存方案比如 Memcached 、Redis 来缓存 session，但是要求Memcached 或 Redis 必须是集群
把 session 放到 Redis 中存储，虽然架构上变得复杂，并且需要多访问一次 Redis ，但是这种方案带来的好处也是很大的：
实现了 session 共享；
可以水平扩展（增加 Redis 服务器）；
服务器重启 session 不丢失（不过也要注意 session 在 Redis 中的刷新/失效机制）；
不仅可以跨服务器 session 共享，甚至可以跨平台（例如网页端和 APP 端）

9. session 持久化
   将 session 存储到数据库中，保证 session 的持久化
   优点：服务器出现问题，session 不会丢失
   缺点：如果网站的访问量很大，把 session 存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。

只要关闭浏览器 ，session 真的就消失了？

不对。对 session 来说，除非程序通知服务器删除一个 session，否则服务器会一直保留，程序一般都是在用户做 log off 的时候发个指令去删除 session。

然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分 session 机制都使用会话 cookie 来保存 session id，而关闭浏览器后这个 session id 就消失了，再次连接服务器时也就无法找到原来的 session。如果服务器设置的 cookie 被保存在硬盘上，或者使用某种手段改写浏览器发出的 HTTP 请求头，把原来的 session id 发送给服务器，则再次打开浏览器仍然能够打开原来的 session。

恰恰是由于关闭浏览器不会导致 session 被删除，迫使服务器为 session 设置了一个失效时间，当距离客户端上一次使用 session 的时间超过这个失效时间时，服务器就认为客户端已经停止了活动，才会把 session 删除以节省存储空间。

文章转载自：
https://new.qq.com/rain/a/20230228A00QTQ00
部分内容引用自：

https://zhuanlan.zhihu.com/p/662495115
https://blog.csdn.net/u010101252/article/details/137119900
https://blog.csdn.net/hola173841439/article/details/140723646
https://www.sohu.com/a/777044518_121934862

我们要引导员工理解、欣赏、接受和习惯高雅的生活习惯与文化活动，使他们从身心上自己解放自己。这次我们不惜使用为客户提供的服务，作一次演示，让大家看到高雅的生活无处不在。这些生活场景、生活方式北京、上海已经比较多，只要你愿意多花一些钱就可以实现。员工不能成为守财奴，不能成为金钱的奴隶，丰厚的薪酬是为了通过优裕、高雅的生活，激发人们更加努力去工作、有效的奋斗而服务的，不是使我们精神自闭、自锁。我们不要再把绅士风度、淑女精神当作资产阶级腐朽的东西，而自以粗鄙为荣。应该看到欧美发达国家的人民的自律，社会道德风尚是值得我们学习的。欧美国家的人，大多数不嫉妒别人的成功，也不对自己的处境自卑，而且和谐相处。

任正非：要快乐地度过充满困难的一生