Token是什么?和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令牌是无状态的,更利于分布式部署。

讲解二:

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

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。

讲解三:

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

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

访问令牌(Access token)表示访问控制操作主体的系统对象
邀请码,在邀请系统中使用
Token, Petri 网(Petri net)理论中的Token
密保令牌(Security token),或者硬件令牌,例如U盾,或者叫做认证令牌或者加密令牌,一种计算机身份校验的物理设备
会话令牌(Session token),交互会话中唯一身份标识符
令牌化技术 (Tokenization), 取代敏感信息条目的处理过程
cookie主要是网站用于在浏览器临时存放的数据,包括浏览器缓存数据以及服务器设定的一些数据,主要存放在浏览器端。

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

传统上的会话登陆和鉴权主要用session加cookie实现,随着分布式系统的快速演进,尤其是微服务的应用,token+cookie的授权访问机制得到亲睐,通常在用户登录后,服务器生成访问令牌(Access token),浏览器存储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保存到任何地方,无限制,无状态,利于分布式部署。

TokenCookieSession 都是用于在客户端服务器之间传递信息的方式,但是它们在实现应用场景上有所不同。 1. TokenToken 是一种轻量级的身份验证授权机制,通常使用 JWT(JSON Web Token)格式进行编码传递。Token 是一种无状态的机制,不需要在服务器端保存任何信息,而是将认证授权的信息编码为 Token,发送给客户端保存。客户端在后续请求中携带 Token,服务器接收到请求后解码 Token,以验证用户身份请求权限。由于 Token 的无状态特性,使得它可以被广泛使用于分布式系统中。 2. CookieCookie 是一种在客户端保存数据的机制,它是通过在客户端的浏览器中存储一些数据来实现的。Cookie 通常用于维持用户的会话状态,比如用户登录后,在后续的请求中都会带上 Cookie 信息,以便服务器判断用户的身份请求权限。Cookie 存在一些安全性问题,比如可以被窃取篡改,因此需要采取一些安全措施,比如使用 HTTPS 协议传输。 3. SessionSession 是一种在服务器端保存用户会话信息的机制。当用户第一次访问服务器时,服务器会为用户创建一个 Session,生成一个 Session ID,并将 Session ID 保存在 Cookie 中,发送给客户端。客户端在后续请求中携带 Session ID,服务器接收到请求后根据 Session ID 获取用户的会话信息。Session 可以保存一些敏感信息,比如用户的登录状态、购物车信息等,因此需要采取一些安全措施,比如对 Session ID 进行加密验证。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值