Ⅰ token和session和cookie的区别是什么
一、表达意思不同
1、token：（某些机器中用以代替纸币的）代币，专用辅币；象征，标志；礼券，代金券；（语言学）符号；（计算机）令牌，记号；（火车通行的）路签；装点门面的，装样子的；象征性的，作为标志的。
2、session：（某项活动的）一段时间，一场；（议会等的）会议，（法庭的）开庭；学年，上课时间；（酒吧中）演奏会（尤指演奏爱尔兰音乐）；（尤指录音师的）灌录音乐时间；（音乐家）伴奏的。
3、cookie：曲奇饼，小甜饼；……样的人；（浏览网页后存储在计算机的）缓存文件；<苏格兰>淡面包；漂亮的年轻女子。
二、固定搭配不同
1、token：as a token of作为…的标志；by the same token同样地；出于同样原因。
2、session：session key会话密钥；对话关键码。
3、cookie：fortune cookie签饼；福饼。
例句
1、Thepenalty forfailurewillbe high. But, by thesametoken, therewards forsuccesswillbe great.
失败就要付出沉重的代价，同样，成功就会获得很大的回报。
2、It turnedout to beaveryinterestingsessionwith a livelydebate.
结果成了一次充满激烈辩论、非常有意思的会议。
3、Onenightyoujusthave to haveacookieandyouknowthere .
有一天晚上，你就是需要吃一块饼干，而你知道橱柜里有一袋你最喜欢的饼干。
Ⅱ 服务器Token不存储可以吗,由客户端每次带上Token,客户端各自存储Token
Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
两种使用方式：
用设备号/设备mac地址作为Token（推荐）
客户端：客户端在登录的时候获取设备的设备号/mac地址，并将其作为参数传递到服务端。
服务端：服务端接收到该参数后，便用一个变量来接收同时将其作为Token保存在数据库，并将该Token设置到session中，客户端每次请求的时候都要统一拦截，并将客户端传递的token和服务器端session中的token进行对比，如果相同则放行，不同则拒绝。
分析：此刻客户端和服务器端就统一了一个唯一的标识Token，而且保证了每一个设备拥有了一个唯一的会话。该方法的缺点是客户端需要带设备号/mac地址作为参数传递，而且服务器端还需要保存；优点是客户端不需重新登录，只要登录一次以后一直可以使用，至于超时的问题是有服务器这边来处理，如何处理看若服务器的Token超时后，服务器只需将客户端传递的Token向数据库中查询，同时并赋值给变量Token，如此，Token的超时又重新计时。
用session值作为Token
客户端：客户端只需携带用户名和密码登陆即可。
客户端：客户端接收到用户名和密码后并判断，如果正确了就将本地获取sessionID作为Token返回给客户端，客户端以后只需带上请求数据即可。
分析：这种方式使用的好处是方便，不用存储数据，但是缺点就是当session过期后，客户端必须重新登录才能进行访问数据。
Ⅲ token和sessionid的区别是什么
cookie和session都是用来跟踪浏览器用户身份的会话方式。cookie与session的区别是，cookie数据保存在客户端，session数据保存在服务器端。简单的说，当你登录一个网站的时候，如果web服务器端使用的是session,那么所有的数据都保存在服务器上面，客户端每次请求服务器的时候会发送当前会话的sessionid，服务器根据当前sessionid判断相应的用户数据标志，以确定用户是否登录，或具有某种权限。由于数据是存储在服务器上面，所以你不能伪造，但是如果你能够获取某个登录用户的sessionid，用特殊的浏览器伪造该用户的请求也是能够成功的。sessionid是服务器和客户端链接时候随机分配的，一般来说是不会有重复，但如果有大量的并发请求，也不是没有重复的可能性，我曾经就遇到过一次。登录某个网站，开始显示的是自己的信息，等一段时间超时了，一刷新，居然显示了别人的信息。如果浏览器使用的是cookie，那么所有的数据都保存在浏览器端，比如你登录以后，服务器设置了cookie用户名(username),那么，当你再次请求服务器的时候，浏览器会将username一块发送给服务器，这些变量有一定的特殊标记。服务器会解释为cookie变量。所以只要不关闭浏览器，那么cookie变量便一直是有效的，所以能够保证长时间不掉线。如果你能够截获某个用户的cookie变量，然后伪造一个数据包发送过去，那么服务器还是认为你是合法的。所以，使用cookie被攻击的可能性比较大。如果设置了的有效时间，那么它会将cookie保存在客户端的硬盘上，下次再访问该网站的时候，浏览器先检查有没有cookie，如果有的话，就读取该cookie，然后发送给服务器。如果你在机器上面保存了某个论坛cookie，有效期是一年，如果有人入侵你的机器，将你的cookie拷走，然后放在他的浏览器的目录下面，那么他登录该网站的时候就是用你的的身份登录的。所以cookie是可以伪造的。当然，伪造的时候需要主意，直接cookie文件到cookie目录，浏览器是不认的，他有一个index.dat文件，存储了cookie文件的建立时间，以及是否有修改，所以你必须先要有该网站的cookie文件，并且要从保证时间上骗过浏览器，曾经在学校的vbb论坛上面做过试验，别人的cookie登录，冒用了别人的名义发帖子，完全没有问题。更有效的方法就是自己定义一个浏览器，我们称之为黑客浏览器，比如我们可以自己改造firefox浏览器，可以自定义sessionid，自定义cookie值，那样就可以随心所欲了。网络安全又将面临严峻的挑战。--------------------------------------------------------------------------------两个都可以用来存私密的东西，同样也都有有效期的说法。区别在于。session是放在服务器上的，过期与否取决于服务期的设定，cookie是存在客户端的，过去与否可以在cookie生成的时候设置进去。1、cookie数据存放在客户的浏览器上，session数据放在服务器上2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用COOKIE4、单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。5、300个的限制我没听说6、所以个人建议：将登陆信息等重要信息存放为SESSION其他信息如果需要保留，可以放在COOKIE中
Ⅳ bearer token 是什么意思
一种令牌类型。Oauth2.0的官网有说明（OAuth 2.0 Bearer Token Usage）
RFC6749
RFC6750
Bearer Type Access Token：
BEARER类型的token是在RFC6750中定义的一种token类型，OAuth2.0协议RFC6749对其也有所提及，算是对RFC6749的一个补充。BEARER类型token是建立在HTTP/1.1版本之上的token类型，需要TLS（Transport Layer Security）提供安全支持，该协议主要规定了BEARER类型token的客户端请求和服务端验证的具体细节。
MAC Type Access Token：
前面介绍了BEARER类型的token，RFC6750明确说明该类型token需要TLS（Transport Layer Security）提供安全支持。虽然现今大部分站点都已经或正在由HTTP向HTTPS迁移，但是仍然会有站点继续在使用HTTP，在这类站点中BEARER类型的token存在安全隐患，这个时候MAC类型的token正是用武之地，MAC类型的token设计的主要目的就是为了应对不可靠的网络环境。
MAC类型相对于BEARER类型对于用户资源请求的区别在于，BEARER类型只需要携带授权服务器下发的token即可，而对于MAC类型来说，除了携带授权服务器下发的token，客户端还要携带时间戳，nonce，以及在客户端计算得到的mac值等信息，并通过这些额外的信息来保证传输的可靠性。
其实很多API服务并没有使用https加密连接（却使用了BEARER类型的token），所以你可以利用一些抓包工具进行抓包分析，可以看到一些应用请求附带的token，你拿这个token也可以访问相应的第三方api，可能有的token时效比较短，用不了多久就会过期。
Ⅳ Token Cookie和Session的区别
Cookie
cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。
cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
Session
session 从字面上讲，就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他就是张三。
session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。
服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
Token
token的意思是“令牌”，是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库
Ⅵ 什么是Http无状态Session、Cookie、Token三者之间的区别
HTTP无状态协议，是指协议对于交互性场景没有记忆能力。
在点击一个纯的html网页，请求获取服务器的html文件资源时，每次http请求都会返回同样的信息，因为这个是没有交互的，每一次的请求都是相互独立的。第一个请求和第二个请求也没有先后顺序，返回处理哪个，结果都是同样的资源页面，因为这种场景是无交互的，无论是什么人请求这个地址，服务器都是返回那个相同的响应。
在无交互场景中上面那样，当然也不会有太大的问题。但是对于涉及到动态交互的场景，就显得很尴尬了，何为交互？有来又有往，对于一模一样的两个接口，不同的人在请求第二个接口时可能会基于请求第一个接口的结果而有所不同。
现在我们来想一个复杂的场景，如在购物网站上买一个书包，流程如下：
所谓的登录只是验证你是否是一个合法用户，若是合法则跳转到信息的页面，不合法则告知用户名密码错误。
但是我们在第一步给服务器发完/login接口后，服务器就忘记了。。。忘记了你这个人，到底有没有经过认证。
所以在添加商品时/cart 你还是需要将你的账号密码和商品信息一起提交给 addCart接口，再让服务器做验证。
第三步同理。
所以当我们说涉及到交互时，情形就完全不一样了，因为这三步是有依赖关系的，第一步验证登录者是一个合法用户，验证通过给你返回200/OK，但是只要服务器给返回了响应，那么一个http的请求和响应就结束了。服务器怎么知道10秒钟之前你刚刚登录过呢？不好意思，服务器不知道你有没有登陆过，他只是对外提供一个登录接口，要想证明你是合法用户必须调/login接口。
第二步，将商品加入到购物车中时，你会调用/cart接口，但是注意，这个行为是和第一步是有关联关系的，是谁将什么物品加入到购物车中了？这个谁，有没有在网站上注册账号呢，是不是一个合法用户呢？所以说在添加购物车的时候，我们还需要将账号密码再次加入到请求参数中，每做一次操作购物车操作时，都需要再把之前已经传输过的账号密码，再反反复复的传输一遍又一遍，这是因为服务器不知道你是不是在20秒之前刚登陆过。
上面的无状态是指的，无登录状态，即服务器不知道某个用户是否已登录过了。因为愚蠢的服务器不知道客户端是否已登录过了,所以每次都要在交互场景(会话)中请求中带上上一次的请求信息，如账号、密码。明明只需要在/login接口中，才需要对比数据库中的账号密码和客户端传的是否一致来确定合法性。这下在添加购物车中也需要再一次地进行同样的重复且没有必要的操作，即降低了响应速度，又对用户不友好(因为每次都需要填账号，密码)。
缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另外人们常说的“会话”概念则是上面的交互行为的另一种表述方式。
通过上面我们知道了Http中无状态是一个什么概念，以及在无状态情况下，要进行添加购物车功能，所带来的困难。
客户端与服务器进行动态交互的Web应用程序出现之后，HTTP无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持HTTP连接状态的技术就应运而生了，一个是Cookie，而另一个则是Session。HTTP本身是一个无状态的连接协议，为了支持客户端与服务器之间的交互，我们就需要通过不同的技术为交互存储状态，而这些不同的技术就是Cookie和Session了。
由于HTTP是一种无状态的协议，服务器 单纯从网络连接上 无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己的通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。
Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时， 浏览器把请求的网址连同该Cookie一同提交给服务器 。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
很多网站都会使用Cookie。例如，Google会向客户端颁发Cookie，Bai也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Bai颁发的Cookie呢？或者Google能不能修改Bai颁发的Cookie呢？
答案是否定的。Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Bai的Cookie。Google也只能操作Google的Cookie，而不能操作Bai的Cookie。
Cookie在客户端是由浏览器来管理的。浏览器能够保证Google只会操作Google的Cookie而不会操作Bai的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Bai的域名不一样，因此Google不能操作Bai的Cookie。
1.在登录网站的时候选择记住密码
2.点击之后观察服务器上的相应内容
3.查看Chrome中的Cookie设置
4.观察服务器返回的Cookie内容
5.再次访问时，发现不需要输入密码即可直接登录，观察请求头信息
cookie并不是单纯为了实现 session机制而生的。而是1993 年，网景公司雇员 Lou Montulli 为了让用户在访问某网站时，进一步提高访问速度，同时也为了进一步实现个人化网络，发明了今天广泛使用的 Cookie。cookie还有一个很广泛的用途就是记住用户的登录账号和密码，这样当用户以后再次需要登录同一个网站或系统的时候就不需要再次填写这两个字段而是直接点击“登录”按钮就好。这就相当于给了一些“甜头”给用户，这就回应了“cookie”这个词语的字面意思了。
实现方法是把登录信息如账号、密码等保存在Cookie中，并控制Cookie的有效期，下次访问时再验证Cookie中的登录信息即可。
我是 “翎野君” ，感谢各位朋友的： 点赞 、 收藏 和 评论 ，我们下期见。
Ⅶ 哪些用不了session ,必须得用token的
比如现在人们常用的购物app软件。
session和token都是用来保持会话，功能相同。session是服务端存储的一个对象，主要用来存储所有访问过该服务端的客户端的用户信息（也可以存储其他信息），从而实现保持用户会话状态。但是服务器重启时，内存会被销毁，存储的用户信息也就消失了。token适用于项目级的前后端分离（前后端代码运行在不同的服务器下）
其实token和session不是同一个领域的概念。token是一个字符串，而session是指一个会话，两者既不冲突又不可互相替代。
Ⅷ h5页面在微信上登录不保存token
可以通过localStorage来实现。
localStorage会可以将第一次请求的数据直接存储到本地，这个相当于一个5M大小的针对于前端页面的数据库，相比于cookie可以节约带宽就可以了。
localStorage与sessionStorage的唯一一点区别就是localStorage属于永久性存储，而sessionStorage属于当会话结束的时候，sessionStorage中的键值对会被清空。
Ⅸ 前后端分离为什么不用session来保存登录状态，用 token based 验证 用意何在
后端服务器有两种基本的身份验证：
是基于Cookie的身份验证，使用服务器端的cookie来对每次请求的用户进行身份验证。
较新的方法，基于令牌Token-Based的认证，依赖于被发送到服务器上每个请求的签署令牌。
为什么基于令牌token-based的方式更好呢？理由如下：
跨域/CORS:cookies+CORS并不能跨不同的域名.而基于令牌能够使用AJAX调用服务器，在任何域名下你都可以使用HTTPheader头部来传输用户信息。
无态(代表服务器端可伸缩):没有必要将会话保存，令牌token自己是一个自我包容的实体，包含用户各种信息，其他状态信息可以保存在cookie或客户端本地存储器中
CDN:能够适用来自CDN任何应用部件(e.g.javascript,HTML,images,etc.),你的服务器只是一个API.
解耦:你不必和一个特定的验证格式Schema绑定，令牌token能在任何地方产生，这样的你的API可以在任何地方以同一种验证方式调用验证。
对移动Mobile友善:当你在一个原生平台(iOS,Android,Windows8,etc.)时，cookies依赖于一个安全API，并不是好主意，因为你得和一个cookie容器打交道，而基于令牌则简单多。
CSRF:因为你不依赖cookies,你就不需要跨请求保护，(e.g.it有可能来自<iframe>请求一个POST，需要重用一个存在的验证。).
.性能:一个网络往返（如发现在数据库中的会话）可能会比计算的HMACSHA256验证令牌耗费更多时间。
登录页面不是一个特殊情况，如果你如果您正在使用量角器来写你的功能测试，你不需要来处理登录的任何特殊情况。
基于标准:你的API能接受一个标准的JSONWebToken(JWT).这个标准后面有多个库包(.NET,Ruby,Java,Python,PHP)，许多公司支持(e.g.Firebase,Google,Microsoft).，比如Firebase允许他们的客户使用任何身份验证机制，只要你使用预先定义的属性生成一个JWT，并使用共享密钥签署，就能调用它们的API.
Ⅹ token是什么意思
是计算机术语：令牌，令牌是一种能够控制站点占有媒体的特殊帧，以区别数据帧及其他控制帧。token其实说的更通俗点可以叫暗号，在一些数据传输之前，要先进行暗号的核对，不同的暗号被授权不同的数据操作。基于
Token
的身份验证方法
使用基于
Token
的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：
1.客户端使用用户名跟密码请求登录
2.服务端收到请求，去验证用户名与密码
3.验证成功后，服务端会签发一个
Token，再把这个
Token
发送给客户端
4.客户端收到
Token
以后可以把它存储起来，比如放在
Cookie
里或者
Local
Storage
里
5.客户端每次向服务端请求资源的时候需要带着服务端签发的
Token
6.服务端收到请求，然后去验证客户端请求里面带着的
Token，如果验证成功，就向客户端返回请求的数据