zl程序教程

您现在的位置是:首页 >  前端

当前栏目

快速理解 session/token/cookie 认证方式

认证Cookie 快速 方式 理解 session Token
2023-09-27 14:28:47 时间

Web Application 一般以 HTTP 协议作为传输协议, 但 HTTP 协议是无状态的. 也就是说 server-side 与 client-side 一旦数据交换完毕后,两者之间的连接就会被关闭. client-side 再次发送请求时, 需要建立新的连接, 这就意味着 server-side 和 client-side 两者之间无法通过 HTTP 的连接来实现 会话跟踪. 显然, 这是不合理的, 因为这样无法保证完成一次 Web Application 业务流程中所产生的若干次 请求/响应 操作的原子性, 从而会导致业务逻辑混乱. cookie 就是为了解决这一问题所引入的 会话跟踪机制.

实现原理: 由 server-side 为 client-side 发放一张通行证, 并以此来认证 client-side 的身份(出于安全性的考虑, 这张通行证一般是临时的). 而这些通行证就是 cookie, 本质上 cookie 就是一小段文本信息, 里面包含了有如 session_id/login-status/token 等认证相关数据.

session

基于 session 的用户认证借助于请求体对象 req 中的 session 数据来完成.

实现原理: 当 client-side 请求 server-side 并通过身份认证后, server-side 就会生成并保存身份认证相关的 session 数据, 并将对应的 sesssion_id 写入 cookie 然后再响应到 client-side, client-side 会把 cookie 文件保存在本地. 此后, client-side 的所有请求都会附带该 session_id, 以确定 server-side 是否存在对应的 session 数据以及检验 session 数据中的 login-status. 如果存在且 login-status 为 True, 则证明 client-side 是被信任的, 无须再次认证身份. 否则, 需要重新进入身份认证流程.

缺点:


server-side 保存 session 数据会增加运维和存储开销 因为一个 session_id 只能被保存有对应 session 数据的 server-side 完成认证, 所以在拥有多台 server-side 集群架构的场景中会降低其扩展性. 如果原生 App 不具备 cookie 功能模块, 就会加大其接入 session 认证后端的难度.

简而言之, session 有如用户信息档案表, 里面包含了用户的认证信息和登录状态等信息. 而 cookie 就是用户通行证.

token

token(令牌) 由 uid+time+sign[+固定参数] 组成:


time: 当前时间的时间戳 sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串,以防止第三方恶意拼接 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库

由其组成可以看出, token 的认证方式类似于临时的证书签名, 并且是一种 server-side 无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是 server-side 并不会保存身份认证相关的数据, token 只被保存在 client-side 中的 cookie 或 localstorage(数据库).

实现原理: 当 client-side 发送请求 server-side 并完成身份认证后, server-side 会生成但不保存一个 token, 而是将 token 以 cookie 或其他形式响应给 client-side. 此后 client-side 发送请求时都会在 Request-Header 中附带 token, server-side 收到 token 后再分发给其他的 身份认证服务 负责处理认证相关的业务. E.G. Openstack 中的 Keystone 项目会为整个云平台提供身份认证服务.

缺点:


因为 token 一般都是 hash/encrypt 的字符串, 所以会额外附加 加密/解密 的性能开销 有些加密方式同样存在安全隐患
一次性弄清楚 Authentication & Authorization 以及 Cookie、Session、Token 老虎、老鼠、傻傻分不清楚? 满脸、泥土、失败的被俘虏! 通过本文学习,让我们一次性搞清楚 Authentication & Authorization 以及 Cookie、Session、Token 的区别与联系。
一文助你快速理解Cookie,Session,Token的区别 本文详细描述了Cookie,Session,Token的定义、鉴权原理和区别。cookie是由Web服务器保存在用户浏览器上的一小段文本,格式:key=value,包含用户相关的信息。session是依赖Cookie实现的,session是服务器端对象,是浏览器和服务器会话过程中,服务器分配的一块储存空间。服务器默认为浏览器在cookie中设置 sessionid,浏览器在向服务器请求过程中传输 cookie 包含 sessionid ,服务器根据 sessionid 获取出会话中存储的信息,确定身份信息。
cookie、session和token的区别 cookie、session、token没有绝对的好与坏之分,主要还是要结合实际的业务场景和需求来决定采用哪种方式来管理会话,当然也可以三种都用。
接口测试(27)session、cookie和token的区别1 2、但是随着交互式Web应用的兴起,像在线购物网站,需要登录的网站等等,马上就面临一个问题,那就是要管理会话,必须记住哪些人登录系统, 哪些人往自己的购物车中放商品, 也就是说我必须把每个人区分开,这就是一个不小的挑战,因为HTTP请求是无状态的,所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串,每个人收到的都不一样, 每次大家向我发起HTTP请求的时候,把这个字符串给一并捎过来, 这样我就能区分开谁是谁了。如果访问服务器多了, 就得由成千上万,甚至几十万个。
一文带你了解CSRF、Cookie、Session和token,JWT之间的关系 1.Cookie和Session兄弟 由于HTTP协议本身是无状态的,也就是说同一个用户前一次HTTP请求和后一次HTTP请求时相互独立的,无法判断后一次请求的用户是不是刚才的用户。为了记录用户的状态,才有了Cookie。Cookie实际上以key-value键值对的形式存储了一些文本信息数据,它将数据保存在客户端(浏览器)。