Cookie、Session、Token究竟区别在哪？如何进行身份认证，保持用户登录状态？

需要多长的昵称呢:
听完的感受，token生成于服务端，存储在客户端，服务端不用存储，用户后面每次登录都携带首次都登录生成的token字符串用于验证，能做到这点，关键就是token使用的某种算法根据用户签名和其它一些信息生成的令牌信息是一致的，可以验证通过，对于用户量庞大的系统，或者分布式，避免了大量session对象的存储带来的内存消耗，和各服务器之间session的复制或者专门用于存储session的服务器宕机带来的问题

【回复】token的本质就是个数据载体，服务端将原有的数据进行加密验签之后发布给用户，用以代表用户的身份标识，服务端可以根据用户token来解读里面的内容。而且至于存不存redis，如何与业务搭配实现单点登录都是项目开发的策略，跟token技术本身无关。
【回复】token在服务端也是需要存储的，不过一般存在redis里，设置一个有效时间。
【回复】回复 @最爱喝菜汤 :JWT标准（也不能算标准吧，算范式？）里，token还真就是不在服务端存储的，是没有什么主动管理token的手段的，服务端只验证接受到的token的合法性（签名，时限，按一定规则写在token里），如果同时存储在服务端的缓存里，严格来说已经是经典session模式了。
大方式:
sessionid是存在服务器内存里，session保存的用户信息存在服务器内存或数据库， cookie接收保存服务器发来的sessionid，然后每次浏览器发送请求就会带上cookie的数据。 token是服务器加密的用户信息，服务器将token发给浏览器，浏览器用cookie或storage保存cookie。然后浏览器每次发送请求就带上token，服务器将其解密并确认用户登录。 我这样理解可以吗

【回复】可以是可以，就是八股味重了点[笑哭]
【回复】服务器验证是前提。cookie保存在客户端，服务器不加密不保存；session保存在客户端，服务器要加密并保存；token保存在客户端，服务器要加密不保存。
【回复】回复 @XiaoQL青龙 :session保存在服务端[辣眼睛]
ikkiday:
Session 是一种能力：是服务器见鬼说鬼话，见人说人话的能力 Token 是一个字符串凭证：和你的各种证件一样功能的凭证，JWT 恰好是其中一种格式 Cookie 是浏览器中的一个存储技术：历史很久了，不用这个也可以 以上连起来就是，你从自己的小钱包（Cookie） 里掏出了身份证（Token），递给了窗口（服务器）里面，从而达成了一种Session 能力

【回复】回复 @珠峰上晒太阳 :jwt是无状态，他只是一个身份凭证。 如果你没有在服务端保存登录状态则无法控制jwt的有效性。 jwt一经签发，则只有到期才会失效。 在无状态登录模式下，也许你只能通过更改jwt的生成密匙才可以使以前的jwt失效。
【回复】回复 @江心明月照 :再有token有效期不宜过长。最后，再怎么样token也有被截取的可能，以上措施只是增加让截取成本而已。关键在于token最大的目的就是保持登陆状态，减少用户操作；保密性很强的内容还是要靠用户名密码来验证，比如支付，私密空间等，必须输入密码，不可能用token来验证
【回复】回复 @珠峰上晒太阳 :1. 关于copy走token的问题，要有一个前提，用户有义务保证自己的密码安全，不告知他人；同样也有义务保证自己的设备安全，及时锁屏等。现在浏览器设置里面查看自动保存的密码，是需要输入开机密码的，我是建议浏览器在打开控制台功能时，也要输入密码。 当然也可以做一些加固措施，比如把token加密后，存储到localstorage里面，提高窃取成本。 2. 你说的链接是不是tcp链接，tcp链接可以设置超时时间的。一段时间内没有数据交互，就可以主动关闭链接
君子随风巽:
cookie最早，既是验证机制，也是存储方式，验证信息存在本地，且可以由本地生成。 session，服务端生成，本地只存sessionid，sessionid由服务端生成，且验证信息存在服务端。 token，服务端生成，存在本地，相比与session只存一个id，本地存的信息更多，如header和payload，尤其是payload，可以确认用户信息。这样，服务端只要保证唯一密钥不丢失。每次都是临时通过header和payload配合密钥去生成signature验证用户身份的。 其实最重要的也就是signature，但是由于密钥只在服务端，如果本地token不泄露，其他人无法根据header和payload生成正确的signature，也无法通过修改payload去假冒其他用户或者篡改该用户的其他信息。

【回复】这三样大概懂意思了，但是有个最核心的问题，我还是没搞懂。 我登录成功后有个坏蛋截获cookie里的session Id 或者 token，然后他的请求里带上这些凭证，是不是就可以冒充“我”，随便下单了？！[脸红]
【回复】回复 @你说的对对对对 :比如百度网盘，很长时间内，仅凭借存在cookie内的验证信息，就可以拥有对应的网盘访问和对应会员下载权限。不过度盘本身也不是啥太隐私的产品，而且不还有私人空间呢么。 不过支付类工具，可能会有更严格的验证，比如对ip，设备信息之类（设备信息也算可以模拟吧）的。
【回复】回复 @你说的对对对对 :而且我突然想起来了，支付时候一般不还让临时输入密码，或者脸部识别指纹识别之类的验证呢么[doge]。 至于截获，现在使用https的网页或者说应用太多了，截获可能性较低，相比之下，贪小便宜或者图省事用一些第三方工具，直接被人薅了认证信息的可能性更大。
平安山的方悦:
如果cookie没用，我想服务器压力非常大，一楼还说没用，笑死了

【回复】cookie怎么可能没用[doge] 毫不夸张的说，cookie应该是这几个里可靠性最强的[doge]
【回复】是啊，一楼连本地和服务器端最基本有缺点都不知道，有时候几个平台还要共享登陆信息麻烦死[笑哭]
【回复】保存一堆session服务器资源直接没了
SunLei磊:
这种东西还是不要想的太死，当token被set-cookie了，那它是cookie呢还是token呢？当我把token又存本地又存服务器，那他是session还是token呢。本质上session就是让http的无状态特性转变为一个有状态的连接，cookie就是一种浏览器实现规范，token就是一串id。你完全可以在header或者body里面写一个id 值你就通过一个可逆算法给出，你就把他存在一个excel里。这样你就实现了一种session

【回复】回复 @SunLei磊 :cookie是一个存储方式，token是令牌
【回复】回复 @hellonanaaya :no, 标准实现上cookie是一种对于前端的存储手段, 里面可以存sessionID, 后端通过这个id去内存找session. token就更广泛了, 甚至sessionID也可以称做token.
【回复】你这个思路非常有意思，实际使用我发现并没有界限的这么清楚
codeArt:
本质上并没什么区别，cookie是十年前出的保存用户访问状态的一种解决方案，浏览器会自动做些处理，现在表现出来的缺点就是不灵活，而且请求时浏览器自动携带cookie，多数请求并不需要，造成浪费。所以目前多使用token，由开发者控制使用，效果一样，更灵活。cookie基本淘汰了，有时图个方便偶尔用一下。还有cookie、session、tookie就是一个称呼，程序员就喜欢起一些专业术语，本质上就是一个保存信息的字符串。而且这个字符串如何组织，里面存了那些信息，又如何加密，并不是一成不变的，各公司可以根据项目灵活处理。这个字符串也不一定非要处理登陆状态问题，想怎么用取决于开发者。你喜欢，请求时token里面存个“i love you”也是可以的，服务器看到回复个“gun”，只要服务器与客户端制定好了协议。

【回复】有点搞笑了。token首先是纯概念，可以用在各种地方，用各种方法实现，url query string 一样可以当token使。cookie是已经标准化(rfc6265)的一种可以用来储存信息/包括token的机制，session跟token的基础概念差不多，区别在于token本身带有授权的语义。session一词也有多重含义，可以代指抽象模型，也可以特指存储在cookie里的部分特征信息或特征id对应存储在后端的具体状态信息。 当然，你要是觉得没区别就没区别吧
【回复】回复 @鼎先生 :光是“还有cookie、session、tookie就是一个称呼，程序员就喜欢起一些专业术语，本质上就是一个保存信息的字符串。”这句话就错的很离谱且对程序员群体有一定攻击性啊(当然楼主可能不是故意的但是确实大家回复也不友善的原因)。实际上不是主观的要起一些术语标榜自己的专业性，而是因为这些都是有协议的，有规范的。之后你在这样一个本来就是教学性质的视频，下面说这样的教育语气的话，还带本质性错误，这样的频道本来就不应该出现吧。
07760:
求讲一期注册 认证 授权 oidc jwt 令牌 这些

账号已注销:
最近学到了cookie和session，也用这两种技术做过身份认证和保持用户登录状态。cookie的身份认证:服务器获取请求中的用户名和密码，判断和数据库的数据是否一致，如果数据一致，就回写用户名和密码的cookie到浏览器，跳转到主页。如果数据不一致就响应用户或密码错误。cookie的保持登录状态:浏览器请求其他网页时，服务器判断是否有cookie数据，如果有就证明用户是在线的，去拿数据库数据显示到页面。如果没有，那么证明用户不在线，需要重新登陆。session的身份认证:获取用户数据和数据库数据判断，如果数据相同就开辟sessoon，并将数据存入session域，回写sessionID，跳转到主页。如果不相同，就响应用户和密码错误。session的保持登陆状态:浏览器访问其他页面，判断sessionID是否一致，如果id一致就证明用户是在线的，去获取session域里的数据再去拿数据库数据，将数据显示到页面上。如果id不一致，用户并不在线，需要重新登录。

【回复】cookie和session最大的区别是数据存储的位置不同，cookie是将数据存储在浏览器中的，session是将数据存储在服务器中的。所以就单论数据安全性来说，cookie是非常低的，而session是相对较高的。
【回复】cookie这种特性根本不适合保存用户数据，因为当要存储多个用户数据时，操作就会相当繁琐，需要保存多个cookie，服务器还要甄别哪个cookie是哪个用户的。session则很适合用来存储数据，因为服务器会为每个用户开辟独立的session，也就是说用户信息存储在各自的session里，并且sessionID每一个都不一致。
【回复】回复 @80891768182_bili :那下次请求服务器怎么知道你是否已经登录呢？你在服务端创建session，一般会把登录用户信息以sessionId为key，用户信息为value保存在服务器内存，下次请求进来，根据请求里带的sessionId去查询，如果查询得到用户信息，则表明你是用了这个用户登录，则放行，假如查询不到，则跳到登录页面要你重新登录
六级考了424分:
蛋老师，上次面试的时候人家问我，登录那一块对axios封装的时候为什么把token放在请求头里而不是放在cookie里，请问这是为啥

【回复】cookie是浏览器控制自动携带，放在请求头就可以由程序控制是否携带token
【回复】和跨域没关系，如果跨域要带cookie，options预检时设置一下Access-Control-Allow-Credentials响应头就好，主要还是防csrf，可以看一下b站点赞的请求，请求体里面很清楚的就写了csrf_token这个参数
【回复】防止csrf攻击。csrf不会窃取你的信息，只会借用你的cookie伪装成你。而放在cookie外面就好了
家逸爸爸:
我正在看算法的书 我啥都没说 结果接在b站推送蛋老师的视频[哦呼]

【回复】回复 @技术蛋老师 :刚刚我上厕所突然感觉蛋蛋痒，然后就刷到你了
【回复】B站已经可以做到这程度了[歪嘴]
梦想做纯爱领袖:
此时一位被Spring Security，Oauth2.0折磨很久的靓仔路过~[藏狐]

【回复】回复 @守法先锋张三 :折磨了很长一段时间，太复杂了[辣眼睛]，很怀疑这样的效率
【回复】我屮艸芔茻，我被这个security恶心坏了！[大哭]
【回复】它的校验全部被我T了，全部改用自己的校验逻辑，真的太拉了
63924306625_bili:
问个问题，如果在局域网内拿到用户的session或者token信息是不是就可以通过postman这类工具直接冒名访问服务端的数据了

【回复】回复 @SunLei磊 :但是一般能拿到这玩意了说明那个人电脑也被入侵了
【回复】是, 如果没有 别的参数进行判断.别说局域网 互联网也可以
【回复】所以高安全的应用里 经常在token里会包含ip 设备信息等
纪念我的过去:
可以讲一期oAuth2的视频吗？还有可以区分一下token和jwt吗？谢谢

【回复】jwt就是token的一种实现. oauth2最广泛的就是你用qq登录B站, B站直接跳转给qq做登录,qq 返回给B站一个token和一些信息, B站通过这个token给你相对应的东西. 但是你要说sso那种基本就跟oauth2没啥关系, 就是网上那些硬扯.
罐头商店进货中:
黑客拿到session意义很大好吗，过滤稍微松一点都能横向越权了，token绕过只需要知道签名就能直接登录了，松一点改数据包都能直接登录

Achiteya:
老师您好，请问服务端的JWT密文是针对每个用户都生成一个还是所有用户共用一个呢？如果是前者的话那意味着服务端也要保存大量的JWT密文，岂不是并没有解决session的大用户量困扰？

【回复】回复 @技术蛋老师 :好的，谢谢您的讲解
【回复】可以看用户量来决定JWT密文方案，很多方法
爱cheese爱智凡:
请教up一个问题，session那块登录完成后下次登录只用判断有没有设置username，或者判断他为不为空嘛？这个session会被黑客拦截吗？如果被拦截他往session里面设置了一个uesrname=1那这样岂不是蒙混过关了。

【回复】你可以拿到sessionID但没办法操作存在服务器上的session，这就是用session更安全的原因啊，你都能操作session直接黑服务器了都[藏狐]
【回复】使用无状态登录，jwt+ras 载荷部分存放username。而且cookie一般只保存5分钟左右，
【回复】回复 @高墙萌薪 :目前接触到的项目都是验证正确与否，没有验证是谁。。就相当于项目只验证钥匙是否合孔，不验证谁拿到钥匙
吴终身:
里面说的session的会话时间指的是最大存活时间，超过这个时间者抛弃一个session

QQEat:
但是黑客拿到session_id后可以修改自己浏览器的session_id，就相当于登录了，就可以操作账号了

【回复】这是可接受的风险，你自己电脑都被入侵了还扯什么安全，网站没必要做那么多校验，这是用户的问题
【回复】看服务端是如何鉴权吧，对于前后端分离的应用，还得使用目标客户端的登录令牌token ，有些安全级别高一点的，会做ip 鉴定。
【回复】回复 @早上五点三十 :一般不会直接这么做，移动端IP改变很常见（WiFi、数据流量切换，基站切换），老让用户重新登录，那得把用户气死
一枚胖:
那如果他人获取了我的cookie，是不是短时间内可以冒充我自动登录呀？

【回复】对于初学者做的网站是的[doge]
【回复】那要看服务器有没有验证什么的cookie 里如果有加密过的ip 对比你登录的ip 就过不下去了 伪造者就要知道你的ip 这只是一种