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

　　在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令牌是无状态的，更利于分布式部署。
　　以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！
　　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。
　　基于Token的认证流程
　　整体的流程是这样的：
　　客户端使用用户名、密码做身份验证；
　　服务端收到请求后进行身份验证；(也可能是统一登录平台、网关)
　　验证成功后，服务端会签发一个Token返回给客户端；
　　客户端收到Token以后可以把它存储起来（可以放在）；每次向服务端发送请求的时候，都要带着Token；
　　Token会有过期时间，过期后需要重新进行验证；
　　服务端收到请求，会验证客户端请求里面的Token，验证成功，才会响应客户端的请求；
　　总结
　　cookie：保存在浏览器种，有大小限制，有状态；
　　session：保存在服务器中，服务器有资源开销，分布式、跨系统不好实现；
　　Token：客户端可以将Token保存到任何地方，无限制，无状态，利于分布式部署。
　　希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
　　Token顾名思义就是令牌、凭证、钥匙 。只有这把钥匙，你才能打开门。token一般都是服务端生成，比如一个web系统，用户登录的时候，服务端校验用户名密码通过以后，会生成一个token，同时会生成refreshToken和一个过期时间。然后将refreshToken和token返回给客户端。客户端会将token保存下来。后续所有的请求都会携带这个token。服务端会判断当前token是否存在已经是否过期。如果token不存在或者过期就会拒绝本次请求。如果token过期怎么办，就用refreshToken刷新时间。当然这里可能还有别的方案。比如只生成token，每次请求的时候都刷新过期时间。如果长时间没有刷新过期时间，那token就会过期。
　　session就是回话，这是服务端的一种操作。当你第一次访问一个web网站的时候，服务端会生成一个session，并有一个sessionid和他对应。这个session是存储到内存中的，你可以向这个session中写入信息，比如当前登录用户的信息。sessionid会被返回到客户端，客户端一般采用cookie来保存。当然这个cookie不用人为写入。用tomcat容器来举个例子。当后端调用HttpServletRequest对象的getSession的方法的时候，tomcat内部会生成一个jsessonid（tomcat sessionid的叫法）。这个jsessonid会随本次请求返回给客户端。响应头信息            HTTP/1.1 200 OK
　　Set-Cookie: JSESSIONID=xxxxxxxxxxxxxxxxxxx
　　这个jessionid就会写到cookie中。之后jessionid就会通过cookie传递到服务端。
　　这里我们就会很清楚了，session的数据是存储到内存中。那问题就来了，如果我们的服务是分布式部署，有多台机器的话，可能我们第一次登陆的时候，我们把用户的信息存储到了session，但是后面的请求到了B机器上，那B机器是获取不到用户的session的。另外就是session存储在内存中，那服务器重启，session就丢失了，这就是他的弊端。现在有一些技术，例如session共享、iphash、session持久等也可以解决上述问题 。cookie是浏览器的一种策略。上述讲到了sessionid就是存储在cookie中的。我们知道http协议是无状态的，cookie就是用来解决这个问题的。cookie中可以用来保存服务端返回的一些用户信息的，例如前文提到的token、sessionid。每一次的请求，都会携带这些cookie。服务端从请求头中取到cookie中的信息，就可以识别本次请求的来源，这样，http是不是就变成有状态的了。这里说几点cookie注意事项。
　　cookie是浏览器的一种策略。上述讲到了sessionid就是存储在cookie中的。我们知道http协议是无状态的，cookie就是用来解决这个问题的。cookie中可以用来保存服务端返回的一些用户信息的，例如前文提到的token、sessionid。每一次的请求，都会携带这些cookie。服务端从请求头中取到cookie中的信息，就可以识别本次请求的来源，这样，http是不是就变成有状态的了。
　　这里说几点cookie注意事项。
　　1、cookie存放在客户端，所以是不安全的。人为可以清除
　　2、cookie有过期时间设定。如果不设置过期时间，说明这个cookie就是当前浏览器的会话时间，浏览器关了，cookie    就存在了。如果有过期时间，cookie就会存储到硬盘上，浏览器关闭不影响cookie。下次打开浏览器，cookie还存在
　　3、cookie有大小的限制，4KB。
　　这个问题，网上有很多的答案，相信都看过了，估计也没有看明白。所以我就不去网上复制了，用自己的话，尽量说通俗，说重点。
　　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。
　　万维网（www：World Wide Web）的诞生起源自1990年12月15日蒂姆·伯纳斯·李利用网际网络实现了超文本传输协议（http：Hyper Text Transfer Protocol）客户端和服务器的第一次通讯。
　　http是运行在TCP之上的一种简单的请求、响应协议，所谓的协议就是形成了固有的套路，客户端指定向服务器发送什么信息，然后服务器就会做出与之对应的回应。
　　举个例子：GET、POST、HEAD等方法中，post一般用于客户端提交表单数据给服务器，或者上次文件给服务器，而head、get则是获取URL中指定的资源。在使用get时请求的参数、值需要附加在URI(URI时URL的一种扩张，在HTTP协议中URI一般都是指URL)后面，利用＂?＂将资源的URI和请求参数、值隔离开来，参数、值之间使用＂&＂隔开。
　　万维网的发展历史
　　要彻底理解session、cookie、token之间的区别，就不得不去翻开过去尘封的历史。仅30年web发生了翻天覆地的变化。
　　早期的web其实是非常简陋的，仅仅实现的是基本的文本浏览而已。用寒酸的表格来做框架定位还仅仅是后话。仅仅只是文本和文本包含的超链接而已，服务器仅仅只是机械式的请求，然后响应，并不需要记录谁在某一个时间段里浏览了什么内容，也不需要记住是谁发的HTTP请求。
　　慢慢的网站就需要登录、留言、发表内容、内容管理、在线购物等等交互，这时web就需要引入会话管理机制，记录谁登录了系统，谁又将商品放入了购物车中等等。由于早期的web本身就是无状态请求，于是有人就想出了一个办法，给每个访问的人发一个不会重复的号码牌，也就是session id（会话标识）。由于session id是服务器发给每个接收端的一串随机字符串，这样就能够区分谁是谁了。
　　session id看似解决web无状态请求的问题，但也造成了不小的困扰。比如在负载均衡组成的集群中，当我们通过机器A登录，session id就会保持在机器A上。但如果下次请求转发到了机器B，就需要将机器A的session id复制到机器B上，所以总是在session复制、粘贴的过程，如果保存了session的机器挂了新的问题接着又产生了。
　　除此之外每个人的设备确实是保存了属于自己的session id，但服务器却要保存所有的session id，这可不一定是几个几十个了，二十成千上万，甚至几十、上百万个。
　　session其实也特别不安全，如果有人伪造了你的session id，也就意味着他可以为所欲为了。可以通过cookie的方式来保存session id，但cookie的区别在于其主要内容包括了名字、值、过期时间、路径、域等信息，cookie可以实现类似于访问者离开店铺或者关闭浏览器，再打开店铺就能马上回复购物车的功能。但cookie一旦过期就会被清理，当访问者再次打开网站时又会重新分配cookie。
　　这么看来session id和cookie在本质上并没有完全的区别，别人想伪造很容易伪造。于是token就出现了，比如用HMAC-SHA256算法加上一个密钥来对数据进行签名，那么别人不知道密钥，那么就没有办法伪造了，签名和数据组合在一起就是token了。
　　token并不需要保存，只需要将发过来的token用同样的HMAC-SHA256算法和密钥再算一次比对相同就表示这个用户已经登录了，并且可以直接取到用户的userID，相反不相同，则会提示认证失败。token的优势是非常明显的，服务器只生产token和验证token，所以服务器就变得非常轻松，没有了各种附带的状态。
　　但由于token中的数据也是明文保存，所以一旦某个人的token被人偷走了，和本人是一样的。
　　总之cookie依旧在，使用web api的互联网大厂更加热衷于token，token相对于session id、cookie会更加安全，并且无状态、可扩展，支持移动设备，可以跨程序调用。
　　以上个人浅见，欢迎批评指正。
　　认同我的看法，请点个赞再走，感谢！
　　喜欢我的，请关注我，再次感谢！
　　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，用于服务器授权访问使用。
　　Token和session都是web网站的会话保持、认证的解决方案；
　　既然都一样为什么还有token的说法。从token产生的背景说起
　　1.移动端应用使得服务器端Session失效
　　2.分布式系统中Session无法共享
　　所以说session对于以上两种情况无效了，所以有了Token的说法那么什么是token,token长什么样子？
　　先给大家一个直观的感受
　　token:PC-3066014fa0b10792e4a762-23-20170531133947-4f6496
　　说白了token保存就是用户的信息（不能保存密码等敏感信息）
　　token的组成：
　　客户端标识-USERCODE-USERID-CREATIONDATE-RONDEM[6位]
　　USERCODE，RONDEM[6位]经过MD5加密就变成了以上字符串token的请求流程
　　请求流程解析
　　1.前端用户发送登录信息至认证系统
　　2.验证用户登录信息，判断用户是否存在
　　3.如果用户存在，生成token信息（客户端标识-USERCODE-USERID-CREATIONDATE-RONDEM[6位]），并存储在redis中
　　4.并将该token返回前端，附加至header验证token
　　客户端
　　将token附加至header
　　服务端
　　从客户端请求header中取出token与redis中的token进行比对，如果一致则允许访问。
　　最后总结一下
　　一般的垂直架构项目使用Session没有任何问题，但是分布式项目或涉及到移动端则考虑使用token。
　　session
　　session的中文翻译是＂会话＂，当用户打开某个web应用时，便与web服务器产生一次session。服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
　　cookie
　　cookie是保存在本地终端的数据。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
　　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＂]);
　　token
　　token的意思是＂令牌＂，是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库
　　cookie 和session的区别
　　1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
　　2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
　　考虑到安全应当使用session。
　　3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
　　考虑到减轻服务器性能方面，应当使用COOKIE。
　　4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
　　5、所以个人建议：
　　将登陆信息等重要信息存放为SESSION
　　其他信息如果需要保留，可以放在COOKIE中
　　token 和session 的区别
　　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，用什么就无所谓了。
　　token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也需要在客户端写入cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。
　　想要全面深入地掌握Token，我们需要先了解这些：Token的概念、身份验证过程、实现思路、使用场景，以及Cookie、Session、Token的区别。
　　内容纲要
　　Token的定义
　　Token的身份验证过程
　　Token的实现思路
　　Token的使用场景
　　Cookie和Session的区别
　　Token 和 Session的区别
　　Token的定义
　　Token是验证用户身份的一种方式，简称做＂令牌＂。最简单的token组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐，以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库。
　　Token的身份验证过程
　　用户通过用户名和密码发送请求。
　　程序验证。
　　程序返回一个签名的Token给客户端。
　　客户端储存Token,并且每次用于每次发送请求。
　　服务端验证Token并返回数据。
　　每一次请求都需要Token,Token应该在HTTP的头部发送，从而保证Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。
　　需要注意的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。
　　Token的实现思路
　　用户登录校验，校验成功后就返回Token给客户端。
　　客户端收到数据后保存在客户端。
　　客户端每次访问API是携带Token到服务器端。
　　服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码。
　　当我们在程序中认证了信息，并取得Token之后，我们便能通过这个Token做许多的事情。我们甚至能基于创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的token）。
　　Token的应用场景
　　当用户注册、首次成功登录之后, 服务器端会生成一个Token值，服务器会将这个Token值保存在数据库中，再将这个Token值返回到客户端。
　　客户端拿到Token 值之后，进行本地保存。
　　当客户端再次发送网络请求时（任一请求），将连同这个Token 值到参数中，一并传送给服务器。
　　服务器接收到客户端的请求，调用Token值，与保存在数据库中的Token值做如下对比：
　　如果两个Token数据相同，即用户曾经登录成功过，当前用户处于登录状态。
　　如果数据库中没有找到这个Token数据，即用户没有登录成功。
　　如果Token数据不同，说明原来的登录信息失效，用户需要重新登录。Cookie和Session的区别
　　存储：Cookie数据存放在客户的浏览器上，Session数据存放在服务器上。
　　安全：Cookie安全性不高，黑客可以通过分析本地的Cookie记录，然后进行Cookie欺骗。
　　性能：Session会在一定时间内保存在服务器上，当访问量较大时，占用服务器，影响系统性能。
　　数据储存量：单个Cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个Cookie。
　　综合以上考量，建议方案：
　　Session和Cookie取长补短、配合使用，将登陆信息等重要信息存放为Session，其他信息如果需要保留，可以放在Cookie中。
　　Token 和 Session 的区别
　　Session和Token并不矛盾，作为身份认证，Token安全性比Session高，因为Token发送的每个请求都带有签名，能防止监听，以及重放攻击。而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的不可预测性，暂且认为是安全的，这是一种认证手段。
　　Session只提供一种简单的认证，即有此SID，以及User的全部权利。是需要严格保密的，这个数据只在使用站点保存，不可共享给其它网站或者第三方App。所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用API接口，则使用Token，如果只是自己的网站或App应用，使用什么都OK。
　　Token，指的是OAuth Token或类似的机制的话，提供的是认证和授权 ，认证是针对用户，授权是针对App。其目的是让某App有权利访问某用户的信息，这里的Token是唯一的，不可以转移到其它App上，也不可以转到其它用户上。
　　Token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件。Cookie就是写在客户端的一个txt文件，记录下用户的访问、登录等信息，下次用户再登录某个网站时，服务器接收到请求，就会自动调用Cookie，自动登录用户名。
　　Session和Cookie差不多，只是Session是写在服务器端的文件，也需要在客户端写入Cookie文件，但是文件里是用户的浏览器编号.Session的状态是存储在服务器端，客户端只有session id，而Token的状态是存储在客户端的。
　　以上，是关于Token、Session、Cookie的知识点介绍，更加深入的详解，感兴趣的童鞋，可查看我持续分享的【BAT架构技术专题合集500+】，回复【架构】，即可领取。
　　如果觉得不错，请点赞支持下~
　　Token是什么？
　　Token是令牌、凭证、钥匙，在Web领域中进行身份验证，关键点在验证！！，说验证就必须了解一下Web领域的发展史呢。刚开始的Web，就是浏览文档的功能，浏览器进行http请求，服务器进行响应，每一次的请求都是一样的，属于无状态的，服务器就是你请求什么，响应什么，不用考虑你是谁这个问题。
　　2.  随着人们需求的改变，比如在线购物系统，需要登陆的网站等，这时候需要进行交互性，服务器接收到请求的时候，要根据你是否登陆，以及判断你是谁，来给你响应，这时候问题就来了，怎么知道每次请求的谁呢，所以就出来了一个会话标识（session id），就是一个随机的字符串，每个人登陆的时候，服务器都会返回一个会话标识，这是再请求的时候，只要带上会话标识，服务器就知道请求的是谁。
　　3.   这样子每个人只要保存自己的session id就可以啦，服务器要保存所有人的session id！！！如果有成千上万的人访问服务器，那对服务器是巨大的开销，严重限制了服务器端的扩展能力，比如机器A跟机器B组成了服务器集群，那么访问了机器A，会话标识在机器A上，如果转到机器B，就不能访问了，也许会说，那复制呢，机器A搬到机器B，也有说统一把标识放在一个机器上，但是万一这个机器挂了呢，那体验就很差了。
　　4. 这个时候就有人想，用户自己保存自己的标识，就是Token，访问的时候带上这个Token，这个Token是用户id+签名，验证时，服务器只要相同的算法和服务器才知道的密钥进行签名，如果结果跟Token中的签名一样，那就可以证明是登陆过的用户。
　　这样一来，服务器不保存session id，只要生成Token，访问时，只要对Token进行判断，Token也是有有效期的，所以也要进行refreshToken的。Token,Cookie,Session三者使用场景的区别？
　　Token主要是Web领域的身份认证，最常见的就是Web API这个功能：单点登陆同步两个平台的数据（基于单点登陆上）日常生活中我们有很多的平台都可以通过自己的微信登陆，这就因为Token的存在，微信官方开放了登陆的API，平台只要调用此API就可以获得Token,之后的认证都是登陆的状态进行的。
　　Cookie就是饼干，它是服务器生产，永久保存在浏览器的数据，以kv的形式，你可以打开你的浏览器（这里以win10 edge为例），点击上方的三个点的按钮，再点击更多工具，再点击开发人员工具，再点击网络，此时内容选择文档，然后刷新页面，找Cookie即可。
　　Session是会话标识，是服务器用来判断正在会话的用户是谁，服务器生产的随机数，保存在服务器中，用户端也要进行保存，虽然能实现会话的共能，但对服务器的扩展能力限制，同时当服务器是两台机器组成以上的时候，会导致两台机器以上保存的session同步问题，会导致用户体验极差。
　　Token跟Session最大的区别就是Token服务端不用保存，同时是通过签名等技术实现的，Session因为是随机数，导致服务器要进行保存。