Token是什么?和session、cookie相比,使用场景有什么区别?_token session 区别

由网友 懒人懒炒 提供的答案：

如果你（星火大模型）是一个web开发工程师,Token是什么？和session、cookie相比,使用场景有什么区别？

看看星火大模型的回答：

Token、Session 和 Cookie 是 Web 开发中常用的三种身份验证方式,它们各自有不同的使用场景和特点。

1. Token: Token 是一种客户端和服务器之间的单向令牌,用于在一段时间内保持用户的身份验证状态。当用户登录后,服务器会生成一个唯一的 Token 并将其发送到客户端的浏览器。在后续的请求中,浏览器会将这个 Token 作为请求头的一部分发送给服务器。服务器会验证这个 Token 是否有效,如果有效,则允许用户访问受保护的资源。Token 通常具有较短的有效期(如几分钟或几小时),以确保用户的安全。

Token 的使用场景：

• 在不需要记住用户登录状态的情况下,例如 API 接口。
• 需要对多个请求进行身份验证的场景。
• 对安全性要求较高的应用场景,因为 Token 可以避免将用户信息存储在客户端或服务器上。

1. Session: Session 是在客户端(浏览器)端保存用户身份验证信息的机制。当用户登录时,服务器会生成一个唯一的 Session ID,并将其发送到客户端的浏览器。在后续的请求中,浏览器会将这个 Session ID 作为 Cookie 或者 URL 参数发送给服务器。服务器会检查这个 Session ID 以确认用户的身份,然后允许用户访问受保护的资源。Session 的有效期可以设置为较长时间(如一天或一周)。

Session 的使用场景：

• 在需要记住用户状态的应用场景,例如购物车系统、社交网络等。
• 在客户端存储数据较多且不需要跨页面共享的用户认证信息时。
• 如果安全性不是首要考虑因素,可以考虑使用 Session。

1. Cookie: Cookie 是 Web 开发中最常用的身份验证技术,它会在客户端(浏览器)中保存用户身份验证信息。当用户登录时,服务器会生成一个包含用户身份验证信息的 Cookie 并将其发送到客户端的浏览器。在后续的请求中,浏览器会将这个 Cookie 作为请求头的一部分发送给服务器。服务器会检查这个 Cookie 以确认用户的身份,然后允许用户访问受保护的资源。Cookie 可以设置过期时间,也可以设置域名、路径等属性来限制其作用范围。

Cookie 的使用场景：

• 在需要记住用户状态的应用场景,例如购物车系统、社交网络等。
• 在客户端存储较少的数据且不需要跨页面共享的用户认证信息时。
• 如果安全性不是首要考虑因素,可以使用 Cookie。

总结：

Token、Session 和 Cookie 都是 Web 开发中常用的身份验证方法,它们各自有不同的使用场景和特点。Token 通常用于无状态的 API 接口,而 Session 更适合于需要记住用户状态的应用场景。Cookie 则适用于大多数情况,特别是对于那些不需要高度安全性的应用

由网友 网络圈 提供的答案：

在Web开发领域,相信大家对于Cookie和Session都很熟悉,Cookie和Session都是会话保持技术的解决方案。随着技术的发展,Token机制出现在我们面前,不过很多开发者对于Token和Cookie、Session的区别及使用场景分辨不清。

Cookie和Session的用途

要知道我们访问网站都是通过HTTP协议或HTTPS协议来完成的,HTTP协议它本身是无状态的协议（即：服务器无法分辨哪些请求是来源于同个客户）。而业务层面会涉及到客户端与服务器端的交互（同网站下多个页面间能共享数据）,此时服务器端必须要保持会话状态,这样才能进行用户身份的鉴别。

由于HTTP无状态的特性,如果要实话客户端和服务器端的会话保持,那就需要其它机制来实现,于是Cookie和Session应运而生。

通常情况下,Session和Cookie是搭配在一起使用的。

Token是什么

上面说到的Session和Cookie机制来保持会话,会存在一个问题：客户端浏览器只要保存自己的SessionID即可,而服务器却要保存所有用户的Session信息,这对于服务器来说开销较大,而且不利用服务器的扩展（比如服务器集群时,Session如何同步存储就是个问题）！

于是有人思考,如果把Session信息让客户端来保管而且无法伪造不就可以解决这个问题了？进而有了Token机制。

Token俗称为"令牌",它的构成是：

• uid：用户唯一身份标识

• timestamp：当前时间戳

• sign：签名字符串,防止第三方伪造数据；签名密钥是存储在服务器端的,其它人无法知道

• 其它附加参数。

Token机制下的认证流程

Token机制其实和Cookie机制极其相似,主要有以下流程：

1、用户登录进行身份认证,认证成功后服务器端生成Token返回给客户端；

2、客户端接收到Token后保存在客户端（可保存在Cookie、LocalStorage、SessionStorage中）；

3、客户端再次请求服务器端时,将Token作为请求头放入Headers中；

4、服务器端接收请求头中的Token,将用户参数按照既定规则再进行一次签名,两次签名若一致则认为成功,反之数据存在篡改请求失败。

（生成签名示例图）

（验证签名示例图）

Token与Cookie+Session的区别

Cookie其实也充当的是令牌作用,但它是"有状态"的；而Token令牌是无状态的,更利于分布式部署。

以上就是我的观点,对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者,十年互联网从业经验,欢迎关注我了解更多科技知识！

由网友 会点代码的大叔 提供的答案：

session和cookie

在讲Token之前,先简单说说什么是session和cookie。

• 首先要知道HTTP请求是无状态的,也就是不知道这一次的请求和上一次请求是否有关系,比如我们登录一个系统的时候,验证用户名密码之后,打开系统各个页面的时候就不需要再进行登录操作了,直到我们主动退出登录或超时退出登录；这里为了避免访问每个都登录一下,就要用到session、cookie。

• cookie是在客户端(浏览器)保存用户信息的一种机制；而且每种浏览器存储大小会有一些差异,一般不超过4KB；

• session是在服务端保存,可以用于记录客户状态,比如我们经常会用session保存客户的基本信息、权限信息等；用户第一次登录之后,服务器就会创建一个session,浏览器再次访问时,只需要从该session中查找该客户的信息就可以了。

Token

但是这里会有个问题,服务器要保存所有用户的session信息,开销会很大,如果在分布式的架构下,就需要考虑session共享的问题,需要做额外的设计和开发,例如把session中的信息保存到Redis中进行共享；所以因为这个原因,有人考虑这些信息是否可以让客户端保存,可以保存到任何地方,并且保证其安全性,于是就有了Token。

Token是服务端生成的一串字符串,可以看做客户端进行请求的一个令牌。

• 当客户端第一次访问服务端,服务端会根据传过来的唯一标识userId,运用一些加密算法,生成一个Token,客户端下次请求时,只需要带上Token,服务器收到请求后,会验证这个Token。

• 有些公司会建设统一登录系统（单点登录）,客户端先去这个系统获取Token,验证通过再拿着这些Token去访问其他系统；API Gateway也可以提供类似的功能,我们公司就是这样,客户端接入的时候,先向网关获取Token,验证通过了才能访问被授权的接口,并且一段时间后要重新或者Token。

基于Token的认证流程

整体的流程是这样的：

1. 客户端使用用户名、密码做身份验证；

2. 服务端收到请求后进行身份验证；(也可能是统一登录平台、网关)

3. 验证成功后,服务端会签发一个Token返回给客户端；

4. 客户端收到Token以后可以把它存储起来（可以放在）；每次向服务端发送请求的时候,都要带着Token；

5. Token会有过期时间,过期后需要重新进行验证；

6. 服务端收到请求,会验证客户端请求里面的Token,验证成功,才会响应客户端的请求；

总结

• cookie：保存在浏览器种,有大小限制,有状态；

• session：保存在服务器中,服务器有资源开销,分布式、跨系统不好实现；

• Token：客户端可以将Token保存到任何地方,无限制,无状态,利于分布式部署。

希望我的回答,能够帮助到你！我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。

由网友 软件测试开发技术栈 提供的答案：

由Session到Token的身份验证演变过程理解Session、Cookie、Token

由网友 阿迈达聊技术 提供的答案：

Token顾名思义就是令牌、凭证、钥匙。只有这把钥匙,你才能打开门。token一般都是服务端生成,比如一个web系统,用户登录的时候,服务端校验用户名密码通过以后,会生成一个token,同时会生成refreshToken和一个过期时间。然后将refreshToken和token返回给客户端。客户端会将token保存下来。后续所有的请求都会携带这个token。服务端会判断当前token是否存在已经是否过期。如果token不存在或者过期就会拒绝本次请求。如果token过期怎么办,就用refreshToken刷新时间。当然这里可能还有别的方案。比如只生成token,每次请求的时候都刷新过期时间。如果长时间没有刷新过期时间,那token就会过期。

session就是回话,这是服务端的一种操作。当你第一次访问一个web网站的时候,服务端会生成一个session,并有一个sessionid和他对应。这个session是存储到内存中的,你可以向这个session中写入信息,比如当前登录用户的信息。sessionid会被返回到客户端,客户端一般采用cookie来保存。当然这个cookie不用人为写入。用tomcat容器来举个例子。当后端调用HttpServletRequest对象的getSession的方法的时候,tomcat内部会生成一个jsessonid（tomcat sessionid的叫法）。这个jsessonid会随本次请求返回给客户端。响应头信息

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=xxxxxxxxxxxxxxxxxxx

这个jessionid就会写到cookie中。之后jessionid就会通过cookie传递到服务端。

这里我们就会很清楚了,session的数据是存储到内存中。那问题就来了,如果我们的服务是分布式部署,有多台机器的话,可能我们第一次登陆的时候,我们把用户的信息存储到了session,但是后面的请求到了B机器上,那B机器是获取不到用户的session的。另外就是session存储在内存中,那服务器重启,session就丢失了,这就是他的弊端。现在有一些技术,例如session共享、iphash、session持久等也可以解决上述问题。

cookie是浏览器的一种策略。上述讲到了sessionid就是存储在cookie中的。我们知道http协议是无状态的,cookie就是用来解决这个问题的。cookie中可以用来保存服务端返回的一些用户信息的,例如前文提到的token、sessionid。每一次的请求,都会携带这些cookie。服务端从请求头中取到cookie中的信息,就可以识别本次请求的来源,这样,http是不是就变成有状态的了。

这里说几点cookie注意事项。

1、cookie存放在客户端,所以是不安全的。人为可以清除

2、cookie有过期时间设定。如果不设置过期时间,说明这个cookie就是当前浏览器的会话时间,浏览器关了,cookie 就存在了。如果有过期时间,cookie就会存储到硬盘上,浏览器关闭不影响cookie。下次打开浏览器,cookie还存在

3、cookie有大小的限制,4KB。

由网友 犍为真人 提供的答案：

这个问题,网上有很多的答案,相信都看过了,估计也没有看明白。所以我就不去网上复制了,用自己的话,尽量说通俗,说重点。

cookie和session实际上是同一套认证流程,相辅相成。session保存在服务器,cookie保存在客户端。最常见的做法就是客户端的cookie仅仅保存一个sessionID,这个sessionID是一个毫无规则的随机数,由服务器在客户端登录通过后随机生产的。往后,客户端每次访问该网站都要带上这个由sessionID组成的cookie。服务器收到请求,首先拿到客户端的sessionID,然后从服务器内存中查询它所代表的客户端(用户名,用户组,有哪些权限等)。

与token相比,这里的重点是,服务器必须保存sessionID以及该ID所代表的客户端信息。这些内容可以保存在内存,也可以保存到数据库(通常是内存数据库)。

而token则可以服务器完全不用保存任何登录信息。

token的流程是这样的。客户端登录通过后,服务器生成一堆客户端身份信息,包括用户名、用户组、有那些权限、过期时间等等。另外再对这些信息进行签名。之后把身份信息和签名作为一个整体传给客户端。这个整体就叫做token。之后,客户端负责保存该token,而服务器不再保存。客户端每次访问该网站都要带上这个token。服务器收到请求后,把它分割成身份信息和签名,然后验证签名,若验证成功,就直接使用身份信息(用户名、用户组、有哪些权限等等)。

可以看出,相对于cookie/session机制,token机制中,服务器根本不需要保存用户的身份信息(用户名、用户组、权限等等)。这样就减轻了服务器的负担。

我们举个例来说,假如目前有一千万个用户登录了,在访问不同的网页。如果用cookie/session,则服务器内存(或内存数据库)中要同时记录1千万个用户的信息。每次客户端访问一个页面,服务器都要从内存中查询出他的登录信息。而如果用token,则服务器内存中不记录用户登录信息。它只需要在收到请求后,直接使用客户端发过来的登录身份信息。

可以这么说,cookie/session是服务器说客户端是谁,客户端才是谁。而token是客户端说我(客户端)是谁,我就是谁。当然了,token是有签名机制的。要是客户端伪造身份,签名通不过。这个签名算法很简单,就是将客户端的身份信息加上一个只有服务器知道的盐值(不能泄露),然后进行md5散列算法(这里只是简化,方便理解,实际细节要稍复杂一些)。

cookie/session在单服务器,单域名时比较简单,否则的话,就要考虑如何将客户端的session保存或同步到多个服务器。还要考虑一旦宕机,内存中的这些信息是否会丢失。token因为服务器不保存用户身份,就不存在这个问题。这是token的优点。

token因为服务器不保存用户身份信息,一切都依赖当初那个签名。所以存在被盗用的风险。也就是说一旦盗用,服务器可能毫无办法,因为它只认签名算法。而session机制,服务器看谁不爽,可以随时把他踢出(从内存中删掉)。正是因为如此,token高度依赖过期时间。过期时间不能太长。过期短,可以减少被盗用的风险。

除了上面所说的,我个人认为,如果开发的系统足够小,倾向于使用cookie/session。如果系统同时登录用户多,集群服务器多,有单点登录需求,则倾向于使用token。

由网友 汇聚魔杖 提供的答案：

万维网（www：World Wide Web）的诞生起源自1990年12月15日蒂姆·伯纳斯·李利用网际网络实现了超文本传输协议（http：Hyper Text Transfer Protocol）客户端和服务器的第一次通讯。

http是运行在TCP之上的一种简单的请求、响应协议,所谓的协议就是形成了固有的套路,客户端指定向服务器发送什么信息,然后服务器就会做出与之对应的回应。

举个例子：GET、POST、HEAD等方法中,post一般用于客户端提交表单数据给服务器,或者上次文件给服务器,而head、get则是获取URL中指定的资源。在使用get时请求的参数、值需要附加在URI(URI时URL的一种扩张,在HTTP协议中URI一般都是指URL)后面,利用"?"将资源的URI和请求参数、值隔离开来,参数、值之间使用"&"隔开。

万维网的发展历史

要彻底理解session、cookie、token之间的区别,就不得不去翻开过去尘封的历史。仅30年web发生了翻天覆地的变化。

早期的web其实是非常简陋的,仅仅实现的是基本的文本浏览而已。用寒酸的表格来做框架定位还仅仅是后话。仅仅只是文本和文本包含的超链接而已,服务器仅仅只是机械式的请求,然后响应,并不需要记录谁在某一个时间段里浏览了什么内容,也不需要记住是谁发的HTTP请求。

慢慢的网站就需要登录、留言、发表内容、内容管理、在线购物等等交互,这时web就需要引入会话管理机制,记录谁登录了系统,谁又将商品放入了购物车中等等。由于早期的web本身就是无状态请求,于是有人就想出了一个办法,给每个访问的人发一个不会重复的号码牌,也就是session id（会话标识）。由于session id是服务器发给每个接收端的一串随机字符串,这样就能够区分谁是谁了。

session id看似解决web无状态请求的问题,但也造成了不小的困扰。比如在负载均衡组成的集群中,当我们通过机器A登录,session id就会保持在机器A上。但如果下次请求转发到了机器B,就需要将机器A的session id复制到机器B上,所以总是在session复制、粘贴的过程,如果保存了session的机器挂了新的问题接着又产生了。

除此之外每个人的设备确实是保存了属于自己的session id,但服务器却要保存所有的session id,这可不一定是几个几十个了,二十成千上万,甚至几十、上百万个。

session其实也特别不安全,如果有人伪造了你的session id,也就意味着他可以为所欲为了。可以通过cookie的方式来保存session id,但cookie的区别在于其主要内容包括了名字、值、过期时间、路径、域等信息,cookie可以实现类似于访问者离开店铺或者关闭浏览器,再打开店铺就能马上回复购物车的功能。但cookie一旦过期就会被清理,当访问者再次打开网站时又会重新分配cookie。

这么看来session id和cookie在本质上并没有完全的区别,别人想伪造很容易伪造。于是token就出现了,比如用HMAC-SHA256算法加上一个密钥来对数据进行签名,那么别人不知道密钥,那么就没有办法伪造了,签名和数据组合在一起就是token了。

token并不需要保存,只需要将发过来的token用同样的HMAC-SHA256算法和密钥再算一次比对相同就表示这个用户已经登录了,并且可以直接取到用户的userID,相反不相同,则会提示认证失败。token的优势是非常明显的,服务器只生产token和验证token,所以服务器就变得非常轻松,没有了各种附带的状态。

但由于token中的数据也是明文保存,所以一旦某个人的token被人偷走了,和本人是一样的。

总之cookie依旧在,使用web api的互联网大厂更加热衷于token,token相对于session id、cookie会更加安全,并且无状态、可扩展,支持移动设备,可以跨程序调用。

以上个人浅见,欢迎批评指正。

认同我的看法,请点个赞再走,感谢！

喜欢我的,请关注我,再次感谢！

由网友 流麦士 提供的答案：

Token, 令牌,代表执行某些操作的权利的对象。

token主要用于鉴权使用,主要有以下几类：

cookie主要是网站用于在浏览器临时存放的数据,包括浏览器缓存数据以及服务器设定的一些数据,主要存放在浏览器端。

session主要用于保存会话数据,一般存储在服务器端,同时每一条session对用一个sessionID,sessionID是存放在浏览器的cookie中。

传统上的会话登陆和鉴权主要用session加cookie实现,随着分布式系统的快速演进,尤其是微服务的应用,token+cookie的授权访问机制得到亲睐,通常在用户登录后,服务器生成访问令牌(Access token),浏览器存储cookie中,在每次请求资源时都会在请求头中带上token,用于服务器授权访问使用。

由网友 min鍋說 提供的答案：

Token和session都是web网站的会话保持、认证的解决方案；

既然都一样为什么还有token的说法。

从token产生的背景说起

1.移动端应用使得服务器端Session失效

2.分布式系统中Session无法共享

所以说session对于以上两种情况无效了,所以有了Token的说法

那么什么是token,token长什么样子？

先给大家一个直观的感受

token:PC-3066014fa0b10792e4a762-23-20170531133947-4f6496

说白了token保存就是用户的信息（不能保存密码等敏感信息）

token的组成：

客户端标识-USERCODE-USERID-CREATIONDATE-RONDEM[6位]

USERCODE,RONDEM[6位]经过MD5加密就变成了以上字符串

token的请求流程

请求流程解析

1.前端用户发送登录信息至认证系统

2.验证用户登录信息,判断用户是否存在

3.如果用户存在,生成token信息（客户端标识-USERCODE-USERID-CREATIONDATE-RONDEM[6位]）,并存储在redis中

4.并将该token返回前端,附加至header

验证token

客户端

将token附加至header

服务端

1. 从客户端请求header中取出token

2. 与redis中的token进行比对,如果一致则允许访问。

最后总结一下

一般的垂直架构项目使用Session没有任何问题,但是分布式项目或涉及到移动端则考虑使用token。

由网友 mikechen的互联网架构 提供的答案：

想要全面深入地掌握Token,我们需要先了解这些：Token的概念、身份验证过程、实现思路、使用场景,以及Cookie、Session、Token的区别。

内容纲要

• Token的定义

• Token的身份验证过程

• Token的实现思路

• Token的使用场景

• Cookie和Session的区别

• Token 和 Session的区别

Token的定义

Token是验证用户身份的一种方式,简称做"令牌"。最简单的token组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,由token的前几位+盐,以哈希算法压缩成一定长的十六进制字符串,可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token,避免多次查库。

Token的身份验证过程

1. 用户通过用户名和密码发送请求。

2. 程序验证。

3. 程序返回一个签名的Token给客户端。

4. 客户端储存Token,并且每次用于每次发送请求。

5. 服务端验证Token并返回数据。

每一次请求都需要Token,Token应该在HTTP的头部发送,从而保证Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ,让服务器能接受到来自所有域的请求。

需要注意的是,在ACAO头部标明(designating)*时,不得带有像HTTP认证,客户端SSL证书和cookies的证书。

Token的实现思路

1. 用户登录校验,校验成功后就返回Token给客户端。

2. 客户端收到数据后保存在客户端。

3. 客户端每次访问API是携带Token到服务器端。

4. 服务器端采用filter过滤器校验。校验成功则返回请求数据,校验失败则返回错误码。

当我们在程序中认证了信息,并取得Token之后,我们便能通过这个Token做许多的事情。我们甚至能基于创建一个基于权限的token传给第三方应用程序,这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的token）。

Token的应用场景

1. 当用户注册、首次成功登录之后, 服务器端会生成一个Token值,服务器会将这个Token值保存在数据库中,再将这个Token值返回到客户端。

2. 客户端拿到Token 值之后,进行本地保存。

3. 当客户端再次发送网络请求时（任一请求）,将连同这个Token 值到参数中,一并传送给服务器。

4. 服务器接收到客户端的请求,调用Token值,与保存在数据库中的Token值做如下对比：

• 如果两个Token数据相同,即用户曾经登录成功过,当前用户处于登录状态。

• 如果数据库中没有找到这个Token数据,即用户没有登录成功。

• 如果Token数据不同,说明原来的登录信息失效,用户需要重新登录。

Cookie和Session的区别

1. 存储：Cookie数据存放在客户的浏览器上,Session数据存放在服务器上。

2. 安全：Cookie安全性不高,黑客可以通过分析本地的Cookie记录,然后进行Cookie欺骗。

3. 性能：Session会在一定时间内保存在服务器上,当访问量较大时,占用服务器,影响系统性能。

4. 数据储存量：单个Cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个Cookie。

综合以上考量,建议方案：

Session和Cookie取长补短、配合使用,将登陆信息等重要信息存放为Session,其他信息如果需要保留,可以放在Cookie中。

Token 和 Session 的区别

Session和Token并不矛盾,作为身份认证,Token安全性比Session高,因为Token发送的每个请求都带有签名,能防止监听,以及重放攻击。而session就必须靠链路层来保障通讯安全。如上所说,如果需要实现有状态的会话,可以通过增加session,在服务器端保存一些状态。

App通常用Restful API跟server打交道。Rest是Stateless的,也就是App不需要像Browser那样用Cookie来保存Session,因此使用Session Token来标示就足够了。Session/state由API Server的逻辑处理。如果后端不是Stateless的rest API,那么可能需要在App里保存Session,可以在App里嵌入webkit,用一个隐藏的Browser来管理Cookie Session.

Session是一种HTTP存储机制,目的是为无状态的HTTP提供持久机制。所谓的Session认证,只是简单的把User信息存储到Session里,因为SID的不可预测性,暂且认为是安全的,这是一种认证手段。

Session只提供一种简单的认证,即有此SID,以及User的全部权利。是需要严格保密的,这个数据只在使用站点保存,不可共享给其它网站或者第三方App。所以简单来说,如果你的用户数据可能需要和第三方共享,或者允许第三方调用API接口,则使用Token,如果只是自己的网站或App应用,使用什么都OK。

Token,指的是OAuth Token或类似的机制的话,提供的是认证和授权 ,认证是针对用户,授权是针对App。其目的是让某App有权利访问某用户的信息,这里的Token是唯一的,不可以转移到其它App上,也不可以转到其它用户上。

Token就是令牌,比如你授权（登录）一个程序时,他就是个依据,判断你是否已经授权该软件。Cookie就是写在客户端的一个txt文件,记录下用户的访问、登录等信息,下次用户再登录某个网站时,服务器接收到请求,就会自动调用Cookie,自动登录用户名。

Session和Cookie差不多,只是Session是写在服务器端的文件,也需要在客户端写入Cookie文件,但是文件里是用户的浏览器编号.Session的状态是存储在服务器端,客户端只有session id,而Token的状态是存储在客户端的。

以上,是关于Token、Session、Cookie的知识点介绍,更加深入的详解,感兴趣的童鞋,可查看我持续分享的【BAT架构技术专题合集500+】,回复【架构】,即可领取。

如果觉得不错,请点赞支持下~