HTTP是无状态的。所有请求都是无状态的。但是，在某些情况下，我们希望记住我们的状态。例如，在一家在线商店中，当我们将香蕉放入购物车后，我们不希望我们的香蕉在转到另一页上购买苹果时消失。IE。我们希望在浏览网上商店时记住我们的购买状态！

为了克服HTTP请求的无状态本质，我们可以使用session或token。

基于session的身份验证

基于认证的session，服务器将在用户登录之后创建session，然后sessionID存储在用户的浏览器的cookie。当用户保持登录状态时，Cookie将与每个后续请求一起发送。然后，服务器可以将Cookie中存储的sessionID与内存中存储的session信息进行比较，以验证用户的身份并发送具有相应状态的响应！

基于session的身份验证流程

基于token的身份验证

许多Web应用程序使用JSON Web token（JWT）代替用于身份验证的session。在基于token的应用程序中，服务器使用机密创建JWT，并将JWT发送到客户端。客户端存储JWT（通常在本地存储中），并在每个请求的标头中都包含JWT。然后，服务器将使用来自客户端的每个请求来验证JWT并发送响应。

基于token的身份验证流程

这里最大的区别是用户状态没有存储在服务器上，而是状态存储在客户端的token内。大多数现代Web应用程序都使用JWT进行身份验证，因为他的可扩展性和移动设备身份验证。

JWT的节点模块

jsonwebtoken库可用于在服务器上创建JWTtoken。用户登录后，客户端会将JWTtoken传递回header.authorization.bearer属性。

{
  method: "GET",
  headers:{
    "Authorization": "Bearer ${JWT_TOKEN}"
  }
}

中间件[express-jwt](https://github.com/auth0/express-jwt),可用于通过比较秘密来验证JWTtoken。

可扩展性

基于session的身份验证：因为session存储在服务器的内存中，所以当大量用户一次使用系统时，扩展就成为一个问题。

基于token的身份验证：扩展没有问题，因为token存储在客户端。

多设备

基于session的身份验证： Cookie通常在单个域或子域上工作，并且如果它们跨域工作，则通常会被浏览器禁用（第三方Cookie）。当从不同的域向移动设备和Web设备提供API时，就会出现问题。

基于token的身份验证： cookie没有问题，因为请求标头中包含JWT。

在现代Web应用程序中，更推荐使用JWT的基于token的身份验证。JWT的一个缺点是与存储在cookie中的sessionID相比，JWT的大小要大得多，因为JWT包含更多的用户信息。必须注意确保JWT中仅包含必要的信息，并且应省略敏感信息以防止XSS安全攻击。

参考

Session vs Token Based Authentication