cookie、session、token详解

cookie、session、token详解

当涉及到用户身份验证和跟踪用户状态时，cookie、session和token是常用的概念。

在线购物网站，需要登录的网站查看个人订单；往自己的购物车中放商品或者想要访问一些私人访问权限的文章，这种操作需要明确当前用户身份。

为了解决无状态带来的鉴权问题,要记住某个用户，一般有以下几种解决方案：

Cookie、Session、Token

Cookie

● Cookie是存储在用户计算机上的小型文本文件，由服务器发送到用户的浏览器，然后由浏览器保存。它通常用于跟踪用户的会话信息、用户首选项等。

● Cookie可以包含诸如用户名、购物车内容、会话ID等信息，并且可以在用户下次访问网站时被发送回服务器。

● Cookie在浏览器中存储，可以设置过期时间，可以被用户删除，伪造，因此安全性相对较低。

Session

为了解决Cookie伪造问题，我们通常使用一个secret。这个secret放在服务器上，服务器返回一个带有secret编码的字符串。在服务器端，我们使用这个secret进行反向解密。

这就是我们要讲的第二个对象：Session，它表示会话。

----------->>>

● 会话是指一系列与特定用户或浏览器相关的交互活动。在Web开发中，通常会使用会话来跟踪用户的登录状态和其他相关信息。

● 会话通常使用cookie或URL重写等技术来维护一个唯一的会话ID，该ID用于在服务器端存储与用户会话相关的信息。

● 会话数据通常存储在服务器端，因此相对于cookie来说更加安全。

========================================================

Session是服务器端用来跟踪用户的一种机制，保存在服务器上。当服务器创建一个session时，会在响应头中包含一个set-cookie字段，浏览器会将这个字段保存在本地，并在后续请求中发送Cookie信息。

Session可以设置有效时间。

然而，这种方式会导致服务器需要保存所有用户的session id，如果访问量很大，就会给服务器带来巨大的开销，限制了服务器的扩展能力。

Token

于是有人就一直在思考， 我为什么要保存这个session呢， 只让每个客户端去保存该多好？可是如果不保存这些session id ,不就如同cookie吗？

怎么验证客户端发给我的session id 的确是我生成的呢？

如果不去验证，我们都不知道他们是不是合法登录的用户， 那些不怀好意的家伙们就可以伪造session id , 为所欲为了。

-------------------->>>>

核心：关键点就是验证 ！

-------------------->>>>

定义：访问令牌access token, 用于接口中，用于标识接口调用者的身份、凭证。简单来说就是不要登录。

-------------------->>>>

举例

小F已经登录了系统， 我给他发一个令牌(token)， 里边包含了小F的 user id， 下

一次小F 再次通过Http 请求访问我的时候， 把这个token 通过Http header 带过来

不就可以了。

目的： 减少用户名和密码的传输次数

问题： 这和session id没有本质区别， 任何人都可以伪造， 所以得想点办法， 让别人伪造不了。

-------------------->>>>

解决方案：

那就对数据做一个签名吧， 比如说我用HMAC-SHA256 算法，加上一个只有我才知道的密钥， 对数据做一个签名， 把这个签名和数据一起作为token ， 由于密钥别人不知道， 就无法伪造token了。

对数据使用HMAC-SHA256算法和密钥进行签名，将签名和数据一起作为token发送给客户端。服务器收到token后，使用相同的算法和密钥重新计算签名并与token中的签名进行较，以验证客户端的身份。这种方法不需要保存session id，减轻了服务器负担，并且可以轻松地进行水平扩展。

Token类型： 

● API Token(接口令牌)：用于访问不需要登录的接口

● USER Token(用户令牌)：用于访问需要用户登录之后的接口

● Token的实效性：token可以是一次性的、也可以在一段时间范围内是有效的

● Token一般放在请求头headers或者body参数里面。 一般在接口文档会有说明

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

● 客户端使用用户名跟密码请求登录

● 服务端收到请求，去验证用户名与密码

● 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端

● 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage里

● 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token

● 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

cookie、session、token的异同点

存储位置：

• Cookie：存储在用户的浏览器中。
• Session：通常存储在服务器端，但会话ID会存储在用户浏览器的Cookie中。
• Token：通常存储在用户浏览器中，例如使用localStorage或sessionStorage。

安全性：

• Cookie：相对较低的安全性，容易被窃取或篡改。
• Session：相对较高的安全性，因为会话数据存储在服务器端。
• Token：取决于实现方式，但通常具有较高的安全性，特别是使用JWT等加密算法的情况。

使用场景：

• Cookie：用于在用户浏览器中存储少量数据，例如跟踪用户偏好、购物车内容等。
• Session：用于在服务器端存储用户会话信息，通常用于跟踪用户的登录状态和其他相关信息。
• Token：通常用于API认证，用于无状态的身份验证和授权。

生命周期管理：

• Cookie：可以设置过期时间，可以长期保存在用户浏览器中。
• Session：通常在用户关闭浏览器或长时间不活动时过期。
• Token：可以设置短暂的过期时间，通常在每次请求中发送到服务器。