Token是什么？和session、cookie相比，使用场景有什么区别？

最新推荐文章于 2024-08-21 15:01:06 发布

jmlqqs

最新推荐文章于 2024-08-21 15:01:06 发布

阅读量2.7k

点赞数 8

分类专栏：安全机制

本文链接：https://blog.csdn.net/jmlqqs/article/details/103632221

版权

安全机制专栏收录该内容

4 篇文章 1 订阅

订阅专栏

讲解一：

在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。