Token验证与传统的校验方式的区别
因为HTTP的无状态性,工作前通过三次握手建立连接,工作完成后立刻通过四次挥手断开连接,每次连接都是独立存在的,没有任何状态将请求串联成一个整体,因此每次都需要重新验证是身份,即耗费了性能。好比你打开一个网址
进入这个网址的下一个页面的时,又需要你重新写一边账号和密码
所有出现了cookie
Cookie 可以作为一个状态保存的状态机,用来保存用户的相关登录状态,当第一次验证通过后,服务器可以通过 set-cookie 令客户端将自己的 cookie 保存起来,当下一次再发送请求的时候,直接带上 cookie 即可,而服务器检测到客户端发送的 cookie 与其保存的 cookie 值保持一致时,则直接信任该连接,不再进行验证操作
好比你去一家洗脚城,你第一次感觉体验不错,于是办了一张会员卡,这张会员卡以后就是你来这家澡堂子的身份凭证了,代表您是尊贵的会员。
但是Cookie毕竟是存储在客户端的,如果用户本人对Cookie进行更改 那么就可以跳过身份验证直接登录(虽然限现在的大部分Cookie都是加密的)
这样就好像伪造了一张洗脚城的会员卡,用这里面的钱去里面大肆消费,洗脚城损失惨重。
这个时候就需要使用Session
session本意是指客户端与服务器的会话状态,由于凭证存储到了服务端,后来也把这些存在服务端的信息称为session。
用户第一次请求服务器的时候,服务器根据用户提交的相关信息,创建对应的 Session
请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
浏览器接收到服务器返回的 SessionID 信息后,会将此信息存入到 Cookie 中,同时 Cookie 记录此 SessionID 属于哪个域名
当用户第二次访问服务器的时候,请求会自动判断此域名下是否存在 Cookie 信息,如果存在自动将 Cookie 信息也发送给服务端,服务端会从 Cookie 中获取 SessionID,再根据 SessionID 查找对应的 Session 信息,如果没有找到说明用户没有登录或者登录失效,如果找到 Session 证明用户已经登录可执行后面操作
好比你这张会员卡洗脚城也有备份,每次你要使用这张会员卡的时候,洗脚城会拿出备份和你的进行校验,防止有人使用伪造的会员卡去洗脚城中骗吃骗喝骗洗脚
这本可以解决所有的问题 但是Session有几个缺点
1.将 session 存储在服务器里面,当用户同时在线量比较多时,这些 session 会占据较多的内存,校验的时候要花费服务器资源
2.当网站采用集群部署的时候,会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session 是由单个服务器创建的,但是处理用户请求的服务器不一定是那个创建 session 的服务器,那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了
3.当多个应用要共享 session 时,除了以上问题,还会遇到跨域问题,因为不同的应用可能部署的主机不一样,需要在各个应用做好 cookie 跨域的处理
简单来说 就是校验舒服了 当是会浪费大量的服务器资源
这个时候就需要使用token了
第一次登录,服务器不返回给你一个和之前一样的SessionID或其他之类的身份校验而是返回一个token
这里使用JWT
JSON Web Token(简称JWT)是以JSON格式存储信息的Token
JWT由3部分构成:头部,负载和签名
- 头部存储的类型和签名算法(上图中,类型是,加密算法是)
- 负载是要存储的信息(上图中,存储了用户姓名和昵称信息)
- 签名是由指定的算法,将转义后的头部和负载,加上密钥一同加密得到的
使用JWT维护登陆态,他仅给客户端发送一个加密的数据token,在请求的时候带是Toke数据,服务器进行计算校验,就可以知道你的登录信息是真是假,不再需要去专门的调用服务器中存储的Session校验,从而减少服务器的压力
同时他还可以实现跨域问题,已经同源问题 是比传统的校验方式更好的办法
好比会员卡上面有一个大师给你签的名,你每次去洗脚城,经理一看签名就知道是不是真的会员,不需要去拿备份的会员卡校验,因为是大师给签的 所以很难伪造。同时拥有这个签名你可以去这个洗脚城的所有分店消费,不会遇到别的分店还需要去总部校验的麻烦事,分部也看签名就知道是不是会员。
客户端如何存储token呢?
- 存在cookie中,虽然设置HttpOnly可以有效防止XSS攻击中token被窃取,但是也就意味着客户端无法获取token来设置CORS头部,cookie 并不是客户端存储凭证的唯一方式。token 因为它的「无状态性」,有效期、使用限制都包在 token 内容里,对 cookie 的管理能力依赖较小,客户端存起来就显得更自由。但 web 应用的主流方式仍是放在 cookie 里,毕竟少操心
- 存在sessionStorage或者localStorage中,可以设置头部解决跨域资源共享问题,同时也可以防止CSRF,但是就需要考虑XSS的问题防止凭证泄露。
一边在面试中经常有人问求职者,只要对方能回答出来,cookie是一种客户端存储介质,token是认证机制的生成物,就过关了。要是能解释出来为什么需要把token放在cookie中,还可以放在哪里,token是如何生效的,为什么要用token来携带认证信息(HTTP的无状态性),等等就是加分项
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了