Token,Cookie和Session三者的区别

秒速五厘米 2024-03-22 15:58 112阅读 0赞

在做各种接口测试时，经常会碰到请求参数为token的类型，但是可能大部分测试人员对token，cookie，session的区别还是一知半解。

### 概念: ###

cookie是服务器端生成发送给客户端在客户端保存的

session是放在服务器端来和客户端的cookie做匹配的

Token是为了解决客户端频繁向服务端请求数据,服务器端在频繁认证响应的 一种技术

拓展:session登录认证方案：用户从客户端传递用户名、密码等信息，服务端认证后将信息存储在session中，将session\_id放到cookie中发送给客户端。以后访问其他页面，自动从cookie中取到session\_id，再从session中取认证信息。

session登录认证另一类解决方案，将认证信息Token，返回给客户端，存储到客户端。下次访问其他页面，需要从客户端传递认证信息回服务端。

JWT就是这类方案的代表，将认证信息保存在客户端。

cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。

cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。

![eeec3568e117a8a5feceb54ae3fabefa.jpeg][]

Session

session 从字面上讲，就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他就是张三。

session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。

服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

![bbaceba5f786c3a6382a5657a7dfd243.jpeg][]

Token

Token的引入：Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。

Token的定义：Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。

使用Token的目的：Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。

![53ead53c461f5907cca921cd4fe00a33.png][]

原理:

服务器认证以后，生成一个 JSON格式的 对象，发回给客户端，就像下面这样。

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> <p>2</p> <p>3</p> <p>4</p> <p>5</p> </td> 
   <td> <p><code>{ </code></p> <p><code>"用户名":&nbsp;"admin",</code></p> <p><code>"角色":&nbsp;"超级管理员",</code></p> <p><code>"到期时间":&nbsp;"2019-07-13&nbsp;00:00:00"</code></p> <p><code>}</code></p> </td> 
  </tr> 
 </tbody> 
</table>

以后，客户端与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。

为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。

服务器不再保存任何 session 数据，也就是服务器变成无状态了，从而比较容易实现扩展。

实际的 Token是一个很长的字符串，中间用点（.）分隔成三个部分。 就像下面这样

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImp0aSI6IjNmMmc1N2E5MmFhIn0.eyJpYXQiOjE1NjI4MzM0MDgsImlzcyI6Imh0dHA6XC9cL3d3dy5weWcuY29tIiwiYXVkIjoiaHR0cDpcL1wvd3d3LnB5Zy5jb20iLCJuYmYiOjE1NjI4MzM0MDcsImV4cCI6MTU2MjkxOTgwOCwianRpIjoiM2YyZzU3YTkyYWEiLCJ1c2VyX2lkIjoxfQ.NFq1qQ-Z5c4pwit8ZkyWEwX6SBXmnHJcc6ZDgSD5nhU</code></p> </td> 
  </tr> 
 </tbody> 
</table>

三个部分依次如下。

Header（头部）

Payload（负载）

Signature（签名）

写成一行，就是下面的样子。

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>Header.Payload.Signature</code></p> </td> 
  </tr> 
 </tbody> 
</table>

### 形象对比: ###

cookie 举例：服务器看你的身份证，然后给你一个编号，以后，进行任何操作，都出示编号后服务员去看服务器上的身份证库查你是谁。

token 举例：我发给你一张加密的身份证，以后你只要出示这张卡片，我就知道你一定是自己人。

seeion举例: 我发给你一张身份证，但只是一张写着身份证号码的纸片。你每次来办事，我去后台查一下你的 id 是不是有效。

### 区别 ###

#### cookie与session的区别 ####

1、cookie数据存放在客户端上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗

考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能

考虑到减轻服务器性能方面，应当使用COOKIE。

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

5、所以个人建议：

将登陆信息等重要信息存放为SESSION

其他信息如果需要保留，可以放在COOKIE中

一、cookie：

在网站中，http请求是无状态的。也就是说即使第一次和服务器连接后并且登录成功后，第二次请求服务器依然不能知道当前请求是哪个用户。cookie的出现就是为了解决这个问题，第一次登录后服务器返回一些数据（cookie）给浏览器，然后浏览器保存在本地，当该用户发送第二次请求的时候，就会自动的把上次请求存储的cookie数据自动的携带给服务器，服务器通过浏览器携带的数据就能判断当前用户是哪个了。cookie存储的数据量有限，不同的浏览器有不同的存储大小，但一般不超过4KB。因此使用cookie只能存储一些小量的数据。

二、session:

session和cookie的作用有点类似，都是为了存储用户相关的信息。不同的是，cookie是存储在本地浏览器，而session存储在服务器。存储在服务器的数据会更加的安全，不容易被窃取。但存储在服务器也有一定的弊端，就是会占用服务器的资源，但现在服务器已经发展至今，一些session信息还是绰绰有余的。

三、cookie和session结合使用：

web开发发展至今，cookie和session的使用已经出现了一些非常成熟的方案。在如今的市场或者企业里，一般有两种存储方式：

1、存储在服务端：通过cookie存储一个session\_id，然后具体的数据则是保存在session中。如果用户已经登录，则服务器会在cookie中保存一个session\_id，下次再次请求的时候，会把该session\_id携带上来，服务器根据session\_id在session库中获取用户的session数据。就能知道该用户到底是谁，以及之前保存的一些状态信息。这种专业术语叫做server side session。

2、将session数据加密，然后存储在cookie中。这种专业术语叫做client side session。flask采用的就是这种方式，但是也可以替换成其他形式。

![75e3d7ddef31bf350a5918af101088cc.jpeg][]

#### cookie与session的其他不同之处: ####

1、存储位置不同

cookie的数据信息存放在客户端浏览器上。

session的数据信息存放在服务器上。

2、存储容量不同

单个cookie保存的数据<=4KB，一个站点最多保存20个Cookie。

对于session来说并没有上限，但出于对服务器端的性能考虑，session内不要存放过多的东西，并且设置session删除机制。

3、存储方式不同

cookie中只能保管ASCII字符串，并需要通过编码方式存储为Unicode字符或者二进制数据。

session中能够存储任何类型的数据，包括且不限于string，integer，list，map等。

4、隐私策略不同

cookie对客户端是可见的，别有用心的人可以分析存放在本地的cookie并进行cookie欺骗，所以它是不安全的。

session存储在服务器上，对客户端是透明对，不存在敏感信息泄漏的风险。

5、有效期上不同

开发可以通过设置cookie的属性，达到使cookie长期有效的效果。

session依赖于名为JSESSIONID的cookie，而cookie JSESSIONID的过期时间默认为-1，只需关闭窗口该session就会失效，因而session不能达到长期有效的效果。

6、服务器压力不同

cookie保管在客户端，不占用服务器资源。对于并发用户十分多的网站，cookie是很好的选择。

session是保管在服务器端的，每个用户都会产生一个session。假如并发访问的用户十分多，会产生十分多的session，耗费大量的内存。

7、浏览器支持不同

假如客户端浏览器不支持cookie：

cookie是需要客户端浏览器支持的，假如客户端禁用了cookie，或者不支持cookie，则会话跟踪会失效。关于WAP上的应用，常规的cookie就派不上用场了。

运用session需要使用URL地址重写的方式。一切用到session程序的URL都要进行URL地址重写，否则session会话跟踪还会失效。

假如客户端支持cookie：

cookie既能够设为本浏览器窗口以及子窗口内有效，也能够设为一切窗口内有效。

session只能在本窗口以及子窗口内有效。

8、跨域支持上不同

cookie支持跨域名访问。

session不支持跨域名访问。

![d19e8225aa312cff830cfa6c29b32d28.jpeg][]

#### session与token的区别 ####

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

App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那样用cookie来保存session,因此用session token来标示自己就够了，session/state由api server的逻辑处理。 如果你的后端不是stateless的rest api, 那么你可能需要在app里保存session.可以在app里嵌入webkit,用一个隐藏的browser来管理cookie session.

Session 是一种HTTP存储机制，目的是为无状态的HTTP提供的持久机制。所谓Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。 而Token ，如果指的是OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App 。其目的是让 某App有权利访问 某用户 的信息。这里的 Token是唯一的。不可以转移到其它 App上，也不可以转到其它 用户 上。 转过来说Session 。Session只提供一种简单的认证，即有此 SID，即认为有此 User的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方App。 所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。

![8a2eb1ff8557b5a7905bc88b8900d72c.jpeg][]

#### cookie和token的区别 ####

cookie：登陆后，后端生成一个sessionid放在cookie中返回给客户端，并且服务端一直记录着这个sessionid，客户端以后每次请求都会带上这个sessionid，服务端通过这个sessionid来验证身份之类的操作。所以别人拿到了cookie等于拿到了sessionid，就可以完全替代你。

token：登陆后，后端会返回一个token给客户端，客户端将这个token存储起来，然后每次客户端请求都需要开发者手动将token放在header中带过去，服务端每次只需要对这个token进行验证就能使用token中的信息来进行下一步操作了。

相关攻击:

xss攻击：用户通过各种方式将恶意代码注入到其他用户的页面中。就可以通过脚本获取信息，发起请求，之类的操作。

csrf攻击：跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。csrf并不能够拿到用户的任何信息，它只是欺骗用户浏览器，让其以用户的名义进行操作。

csrf例子：假如一家银行用以运行转账操作的URL地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

那么，一个恶意攻击者可以在另一个网站上放置如下代码： <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。

上面的两种攻击方式，如果被xss攻击了，不管是token还是cookie，都能被拿到，所以对于xss攻击来说，cookie和token没有什么区别。但是对于csrf来说就有区别了。

以上面的csrf攻击为例：

cookie：用户点击了链接，cookie未失效，导致发起请求后后端以为是用户正常操作，于是进行扣款操作。

token：用户点击链接，由于浏览器不会自动带上token，所以即使发了请求，后端的token验证不会通过，所以不会进行扣款操作。

![5beef22852c8bb19f88ed93671f03314.jpeg][]

### 误解： ###

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

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

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

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

[Token,Cookie和Session三者的区别 - 典藏笔记 - 执刀人的工具库][Token_Cookie_Session_ - _ -]

[eeec3568e117a8a5feceb54ae3fabefa.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/7bc8b0d1949149249d74cb9ca15e6a2f.png
[bbaceba5f786c3a6382a5657a7dfd243.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/6f625d90c446483592d832c27defb5d8.png
[53ead53c461f5907cca921cd4fe00a33.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/59a4764915b140f4b833d21d52448969.png
[75e3d7ddef31bf350a5918af101088cc.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/54bb0397d9a74b158d618b559fdc24f1.png
[d19e8225aa312cff830cfa6c29b32d28.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/412ddc3ddd0f419d9b7f161ea5736ad3.png
[8a2eb1ff8557b5a7905bc88b8900d72c.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/44286402d1c94e409f964ba017226b95.png
[5beef22852c8bb19f88ed93671f03314.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/8d96254b3291429e8787fd19faca5b3c.png
[Token_Cookie_Session_ - _ -]: http://www.hu6.cc/post/109.html