透彻理解COOKIE、SESSION、TOKEN——你分清了吗？

最新推荐文章于 2024-08-22 17:02:09 发布

征__程

最新推荐文章于 2024-08-22 17:02:09 发布

阅读量359

点赞数 2

分类专栏： web安全文章标签： web service 计算机网络 cookie session

本文链接：https://blog.csdn.net/LizePing_/article/details/119249662

版权

web安全专栏收录该内容

19 篇文章 1 订阅

订阅专栏

Cookie、Session、Token 你分清了吗？

在这里插入图片描述

COOKIE、SESSION、TOKEN你分清了吗？

什么是Cookie
什么是Session
什么是Token
Cookie 和 Session 的区别
token 和session的区别

之前这三个一直在脑子里（咯勒），老家方言，懂的都懂。最近深入了解了一下cookie，session，token的区别

什么是Cookie

先来扯一下cookie。没有它，就没有现在的网购。你说重要不重要
在这里插入图片描述

cookie的内容主要包括：名字、值、过期时间、路径和域。

cookie机制是采用在客户端保持状态的方案，cookie是保存在本地终端的数据。HTTP是无状态的协议，每个请求都是完全独立的,服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态需要通过 cookie 或者 session 去实现。

cookie 存储在客户端： cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，
它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。

cookie 是不可跨域的： 每个 cookie 都会绑定单一的域名，无法在别的域名下获取使用，
一级域名和二级域名之间是允许共享使用的（靠的是 domain）。

cookie的组成有：名称(key)、值(value)、有效域(domain)、路径(域的路径，一般设置为全局:"")、失效时间、安全标志(指定后，cookie只有在使用SSL连接时才发送到服务器(https))。

下面是一个简单的js使用cookie的例子:

用户登录时产生cookie:

document.cookie = "id="+result.data['id']+"; path=/";

document.cookie = "name="+result.data['name']+"; path=/";

document.cookie = "avatar="+result.data['avatar']+"; path=/";

使用到cookie时做如下解析：

var cookie = document.cookie;var cookieArr = cookie.split(";");var user_info = {};for(var i = 0; i < cookieArr.length; i++) {

user\_info\[cookieArr\[i\].split\("="\)\[0\]\] = cookieArr\[i\].split\("="\)\[1\];

}

$('#user_name').text(user_info[' name']);

$('#user_avatar').attr("src", user_info[' avatar']);

$('#user_id').val(user_info[' id']);

什么是Session

session是另一种纪录服务器和客户端会话状态的机制,session的中文翻译是“会话”，当用户打开某个web应用时，便与web服务器产生一次session。服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。
session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中

session 认证流程：

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的Session

请求返回时将此Session的唯一标识信息SessionID返回给浏览器

浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，
同时 Cookie 记录此 SessionID 属于哪个域名

当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，
如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，
再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，
如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

什么是Token

token的意思是“令牌”，是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查。

访问资源接口（API）时所需要的资源凭证

Cookie 和 Session 的区别

安全性:
Session比Cookie安全,Session是存在服务器端的,Cookie是存在客户端的。
存取值的类型不同：
Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
有效期不同：
cookie的生命周期可以通过cookie.setMaxAge(2000);来设置，如果没有设置setMaxAge,则cookie的生命周期当浏览器关闭的时候，就消亡了，cookie的生命周期是累计的，从创建时，就开始计时，20分钟后，cookie生命周期结束，session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁但是，如果在20分钟内（如在第19分钟时）访问过session，那么，将重新计算session的生命周期。

session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。

单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
特点

token 和session的区别

session和token并不矛盾，作为身份认证token安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击，而session就必须靠链路层来保障通讯安全了。如上所说，如果你需要实现有状态的会话，仍然可以增加session来在服务器端保存一些状态。

Session是一种HTTP存储机制，目的是为无状态的HTTP提供的持久机制。所谓Session认证只是简单的把User信息存储到Session里，因为SID的不可预测性，暂且认为是安全的。这是一种认证手段。

而Token，如果指的是OAuth Token或类似的机制的话，提供的是认证和授权 ，认证是针对用户，授权是针对App。其目的是让某App有权利访问 某用户 的信息。这里的Token是唯一的。不可以转移到其它App上，也不可以转到其它用户上。

Session只提供一种简单的认证，即有此SID，即认为有此User的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方App。所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用API接口，用Token。如果永远只是自己的网站，自己的App，用什么就无所谓了。

token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也需要在客户端写入cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。

传统身份验证

HTTP 是一种没有状态的协议，也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端，客户端使用用户名还有密码通过了身份验证，不过下回这个客户端再发送请求时候，还得再验证一下。

解决的方法就是，当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的 ID 号发送给客户端，客户端收到以后把这个 ID 号存储在 Cookie 里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie ，这样服务端会验证一个这个 Cookie 里的信息，看看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。

上面说的就是 Session，我们需要在服务端存储为登录的用户生成的 Session ，这些 Session 可能会存储在内存，磁盘，或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。

基于 Token 的身份验证

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

客户端使用用户名跟密码请求登录
服务端收到请求，去验证用户名与密码
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
APP登录的时候发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果成功，以某种方式比如随机生成32位的字符串作为token，存储到服务器中，并返回token到APP，以后APP请求时，凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让他重新登录。其中服务器上token设置一个有效期，每次APP请求的时候都验证token和有效期。

那么问题来了：

服务器上的token存储到数据库中，每次查询会不会很费时。如果不存储到数据库，应该存储到哪里呢。
客户端得到的token肯定要加密存储的，发送token的时候再解密。存储到数据库还是配置文件呢？

token是个易失数据，丢了无非让用户重新登录一下，新浪微博动不动就让我重新登录。
所以如果你觉得普通的数据库表撑不住了，可以放到 MSSQL/MySQL 的内存表里（不过据说mysql的内存表性能提升有限），可以放到 Memcache里（讲真，这个是挺常见的策略），可以放到redis里（我做过这样的实现），甚至可以放到 OpenResty 的变量字典里（只要你有信心不爆内存）。

token是个凭条，不过它比门票温柔多了，门票丢了重新花钱买，token丢了重新操作下认证一个就可以了，因此token丢失的代价是可以忍受的——前提是你别丢太频繁，要是让用户隔三差五就认证一次那就损失用户体验了。

客户端方面这个除非你有一个非常安全的办法，比如操作系统提供的隐私数据存储，那token肯定会存在泄露的问题。比如我拿到你的手机，把你的token拷出来，在过期之前就都可以以你的身份在别的地方登录。

打破误解

“只要关闭浏览器，session就消失了”？

不对。对session来说，除非程序通知服务器删除一个session，否则服务器会一直保留，程序一般都是在用户做log
off的时候发个指令去删除session。

然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来保存session
id，而关闭浏览器后这个session
id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存在硬盘上，或者使用某种手段改写浏览器发出的HTTP请求头，把原来的session
id发送给服务器，则再次打开浏览器仍然能够打开原来的session.

恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为session设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以以为客户端已经停止了活动，才会把session删除以节省存储空间。

如果你认为用数据库来存储 token 会导致查询时间太长，可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。

token 完全由应用管理，所以它可以避开同源策略

token 可以避免 CSRF 攻击(因为不需要 cookie 了)

移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

只要关闭浏览器，session 真的就消失了？

不对。对 session 来说，除非程序通知服务器删除一个 session，否则服务器会一直保留，程序一般都是在用户做 log off
的时候发个指令去删除 session。
然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分
session 机制都使用会话 cookie 来保存 session id，而关闭浏览器后这个 session id
就消失了，再次连接服务器时也就无法找到原来的 session。如果服务器设置的 cookie
被保存在硬盘上，或者使用某种手段改写浏览器发出的 HTTP 请求头，把原来的 session id
发送给服务器，则再次打开浏览器仍然能够打开原来的 session。恰恰是由于关闭浏览器不会导致 session 被删除，迫使服务器为
session 设置了一个失效时间，当距离客户端上一次使用 session
的时间超过这个失效时间时，服务器就认为客户端已经停止了活动，才会把 session 删除以节省存储空间。

欢迎大家食用。分享是一种美德，学习中成长
在这里插入图片描述