文中将从Web运用 由传统式身份验证到根据Token的身份验证的发展全过程的视角，详细介绍Session、Cookie、Token。
很早以前，Web 运用基本上作为文本文档的浏览，如网络黄页。即然只是是浏览，因而网络服务器不用纪录实际用户在某一段时间里都浏览了什么文本文档，每一次请求全是一个新的HTTP协议书，对网络服务器而言全是最新的。
根据Session的身份验证
伴随着互动式Web使用的盛行，例如，买东西等必须登陆的网址。引出了一个新的问题，那就是要纪录什么用户登陆了系统软件实现了什么实际操作，即要管理方法会话(什么叫会话?简易的讲假如用户必须登陆，那麼就可以简便的正确理解为会话，假如不用登陆，那麼便是简易的联接。)，例如，不一样用户将不同产品添加到加入购物车中， 换句话说务必把每一个用户区别开。由于HTTP请求是无状态的，因此想到了一个方法，那就是给每一个用户配备一个会话标志(Session id)，简易的讲是一个既不容易反复，又很难被寻找规律性以仿制的随机字符串，促使每一个用户的接到的会话标志都不一样， 每一次用户从手机客户端向服务器端进行HTTP请求的情况下，把这个字符串数组给一并推送回来， 那样服务器端就能区别开谁是谁了，对于手机客户端(浏览器)如何保存这一“真实身份标志”，一般默认设置选用 Cookie 的方法，这一会话标志(Session id)会存有手机客户端的Cookie中。
尽管那样解决了区别用户的问题，但又导致了一个新的问题，那就是每一个用户(手机客户端)只要储存自身的会话标志(Session id)，而服务器端则要储存全部用户的会话标志(Session id)。 假如浏览服务器端的用户慢慢变多， 就必须储存不计其数，乃至上千万个，这对网络服务器说成一个无法进行的花销 。 再例如，服务器端是由2台网络服务器构成的一个群集， 小亮根据网络服务器A登陆了系统软件， 那session id会储存在网络服务器A上， 假定小亮的下一次请求被发送到网络服务器B该怎么办? 网络服务器B可沒有小亮 的 session id。
很有可能会有些人讲，假如使小亮登陆时，自始至终在网络服务器A上开展登陆(sticky session)，岂不解决了这个问题?那假如网络服务器A挂了怎么办呢? 依然会将小亮的请求分享到网络服务器B上。
如此一来，那只有做群集间的 session 拷贝共享资源了， 便是把 session id 在2个设备中间开展拷贝，如下图，但这对云服务器的使用性能和运行内存明确提出了很大的挑戰。
因而，又想起假如将全部用户的Session集中化储存呢，也就想起了缓存文件服务项目Memcached——因为 Memcached 是分布式系统的运行内存目标缓存文件系统软件，因而可以用于完成 Session 同歩。把session id 集中化储存到一台网络服务器上， 全部的网络服务器都来浏览这个地方的数据信息， 如此就规避了拷贝的方法， 可是这类“集千娇百宠于一身”促使又出現了服务器宕机的很有可能， 也就是说这一承担储存 session 的网络服务器挂掉， 全部用户都得再次登陆一遍， 这也是用户无法进行的。
那麼干脆储存Session的网络服务器也弄成群集，提升其稳定性，防止服务器宕机，但无论怎样，Session 引起出的问题五花八门。
因此许多人就在思索， 为何服务器端务必要储存这session呢， 只让每一个手机客户端去储存不行吗?但是服务器端如果不储存这种session id ，又将怎样认证手机客户端推送的 session id 确实是服务器端转化成的呢? 如果不认证，服务器端没法分辨是不是合理合法登陆的用户，对，这儿的问题是认证， session 仅仅处理这一认证问题的而发生的一个解决方法，是不是也有其他计划方案呢?
根据Token 的身份验证
例如， 小亮早已登陆了系统软件，服务器端为他发一个动态口令(Token)， 里边涵盖了小亮的 user id， 后面小亮再度根据 Http 请求浏览云服务器的情况下， 把这个 Token 根据 Http header 带回来不就可以了。
服务器端必须认证 Token是自身转化成的，并非仿冒的。倘若不认证所有人都能够仿冒，那麼这一动态口令(token)和 session id沒有不同之处，怎么让他人仿冒不了?那么就对数据信息做一个签字(Sign)吧， 例如服务器端用 HMAC-SHA256 加密技术，再添加一个仅有服务器端才知道的密匙， 对数据信息做一个签字， 把这个签名和信息一起做为 Token 发送给手机客户端， 客户端接到 Token 之后可以把它储存起來，例如储存在 Cookie 里或是 Local Storage 中，因为密匙除开服务器端一切别的用户都不清楚， 就没法仿冒动态口令(Token)。
如此一来，服务器端就不用储存 Token 了， 当小亮把这个Token发送给服务器端时，服务端应用同样的HMAC-SHA256 优化算法和同样的密匙，对数据信息再测算一次签字， 和 Token 中的签名做一个比照， 假如同样，表明小亮早已登陆过去了， 即验证通过。若不同样， 那麼表明这一请求是仿冒的。
这样一来， 服务器端只必须转化成 Token，而不用储存Token， 仅仅认证Token就好了 ，也就完成了時间获得室内空间(CPU时间计算获得session 储存空间)。没有了session id 的限定， 当用户浏览量扩大， 立即加设备就可以更好地做水准拓展，也很大的增强了扩展性。