大多数区块链开发者忽视了token设计的重要性，如何设计token机制，某种程度上决定了项目的未来走向。目前区块链行业已经形成基本共识，即带token的区块链项目大致分为公链和应用（DApp）两类，token的设计又分为两种思路，一种是公司发行股份，一种是中央银行发行货币，这两种方式互相结合，形成了区块链项目中单token或双token机制的设计方法。在此，我们按照项目的类别，来阐述区块链项目的token设计方法。
 
公链token的设计方法
 公链token的形态多样，有些token可被看作股份，也有些可被看作货币或是商品。公有区块链的早期用户中有两个重要的角色，一个为矿工（记账人），一个为消费者。为了推广自己的区块链项目，开发者给系统设定了某种激励规则，使得早期使用该系统的用户能够得到奖励。新发行的token分配方式与该条链使用的共识机制有关。大部分采取PoW机制的区块链项目，会把新产生的token全部分配给矿工，不过也有DASH这样的例外，该项目采取工作量证明+服务量证明的混合模式，把区块奖励分别分配给矿工（45%）、主节点（45%）以及基金会（10%）这三者。而另一个颇具代表性的DPoS项目Steem区块链，选择将新发行的90%的token都奖励给潜在消费者（即代币持有者），只有一小部分新发行token被授予矿工。
 
（1）token总量有上限
 总量有上限的token，最具代表性的是比特币。在一开始设计token时，要为token设定一个总量值，由于公有链未来市场潜力较大，市值可能落在10-1000亿之间，宜根据估值将总币量设定在1000万-10亿之间，以便以法币计价时，每个币的价格在1-10000元之间，有利于投资者间的沟通和交易。类似比特币这种总量2100万个币，100%给矿工的项目较少，因为区块链项目背后都有开发团队，大部分项目会像Filecoin一样，通过ICO等方式，将总量的x%保留给团队，总量的y%给私募或ICO投资者，剩下的z%奖励给矿工。一般来说，奖励给矿工的部分将随块高呈指数递减，直至所有用于奖励的token发放完毕，按照指数递减来设计token，有利于激励早期用户，与按块平均分配可奖励的token相比，更能促使项目快步发展，同时，早期衰减也不宜过快，以防止同期大量token流入市场，冲击价格。
 
token总量有上限的区块链项目是基于这样一个假设：早期的奖励能够吸引矿工群，作为既得利益者，矿工倾向于帮助社区持续发展，提升token价格，一旦形成社区氛围，并吸引来足够的使用者，系统可以不再付出奖励，让整个体系出于使用目的而不是激励目的自行运转。这样的风险在于，如果所有用于激励的代币用完，如果仍然未吸引足够的消费者，矿工也离去，整个系统将趋于死亡。此外，随着系统奖励的耗尽，最终支撑网络运转的是消费者，这意味着消费者需要付出更多交易费／使用费来为区块链网络的使用和安全买单，一旦消费者们倾向于花费较少甚至不花费任何成本去使用系统资源，就可能导致挖矿的“公地悲剧”。
 
以比特币为例：
 比特币总量被限定为约2100万个，无ICO，0%归投资人或团队，100%归矿工，出块速度为10分钟一个块，初始每个块奖励50BTC，每隔21万个块奖励减半。由于区块链中没有时间概念，只有块高概念，因此，我们可以根据出块速度估算出大约每隔4年，出块奖励会减半，直至到达693万块高（约为2140年）时，所有BTC奖励发放完毕。届时，矿工收入只能依赖于从消费者处获得的手续费（记账费）。比特币挖矿奖励的具体公式如下：
 21万500.50+21万*50*0.51+21万500.52+…+21万*50*0.5n= 2100万
 
设计公链总量有上限的token时一共有4个可调整的关键参数：
 
token总量
投资人、团队、基金会、矿工等利益相关群体的分配比例
每个块由系统奖励的数量
指数衰减参数（衰减间隔，衰减系数）
 token奖励释放公式如下：
 xab0+x*a*b1+xab2+…+x*a*bn = y
 
其中，
 
x为奖励衰减的块间隔
a为每个块的初始奖励
b为衰减系数
y为token总量
 
（2）token总量无上限（通胀模型）
 目前能够或者有潜力形成应用生态的主流公链，比如ETH、EOS，均为有一定通胀率的公链体系。在一开始，创始团队会在代码中利用出块奖励数设置一定的通胀率，使得系统能够自动发行token。新发行的token分配方式与该条链使用的共识算法有关。当总量无上限体系与PoW共识机制结合时，由于挖矿的硬件门槛较高，阻止了个人参与新发行token的分配，使得不承担矿工角色的普通持币人权利被持续稀释。当总量无上限体系与PoS或DPoS共识机制结合时，新发行的token会直接或间接分配给现有的持币人，因此可以消除token长期稀释给币价带来的负面影响。此外，基于PoW和PoS的新发行token分配是完全基于代码的客观分发机制，而DPoS引入了主观分发方式，即被普通持币人授权的矿工／代表人（相当于公司董事会），可能拥有分配新发行token的权利，或是被授予与普通持币人比更高的新token分配比例。
 
以EOS为例：
 EOS初始总量为10亿个，有ICO，10%归开发团队，90%归ICO投资者所有。系统的年通胀率为5%，其中超级节点（矿工／代理人）奖励1%，剩下的4%由官方创始团队管理，用于后续的建设。
 以ETH为例：
 ETH初始总量约为7200万个（ICO时募集资金未设置硬顶，募到多少BTC就发行多少ETH），有ICO，16.53%归以太坊基金会，83.47%归ICO投资者所有。采用PoW挖矿，每个块奖励5ETH，每天出块约5400个，每天奖励约27000ETH，所有新发行的ETH100%奖励给矿工。
 
设计公链总量无上限的token时一共有4个可调整的关键参数：
 
token初始总量
投资人、团队、基金会、矿工等利益相关群体的分配比例
每个块由系统奖励的数量／通胀率
由于通胀而新发行的token奖励给矿工和其他利益相关方的比例
 
（3）token总量上限+总量无上限结合
 有些币会采取混合挖矿的方式来发行新token，并奖励给矿工或持有人，最典型的混合挖矿案例为同时采取PoW+PoS共识的点点币（Peercoin）。在混合挖矿体系中，新token的产出来自两方面，一方面是类似比特币的模式（也可以设计成无总量上限的模式，这样PoW+PoS结合就是双重通胀系统），这部分token总量有限，随着块高增加，新发行的token数减少，直至到达上限，另一方面采取PoS模式，新发行的token可以与持币人所持币量有关，也可以与币龄有关，比如点点币即根据用户的持币量和币龄将挖矿奖励设置为1%，即点点币在PoS下的这部分币每年有1%的通胀率。
 
（4）稳定币（双token机制）
 在现代货币理论中，货币被认为是商品交换的媒介或是价值贮藏的手段，在区块链世界中，只有价格稳定的token才可被当作体系内的“货币”来使用。因此，一部分公链除了设计代表区块链系统所有权且具备激励特性的token外，还设计有价格稳定的token作为生态内的“货币”来使用，形成了双token的设计模式。在这个过程中，可以通过（1）发行借据锚定美元等稳定资产（2）以其它token作为基础资产抵押（3）算法央行 这三种方式实现token的稳定性，较具代表性的稳定币有Tether、Steem Dollars（SBD）等。在Steem区块链中，开发者设计了股份币SP／Steem，用来进行社区激励，并发行了可被视作可转换票据的债务工具SBD，通过锚定美元来实现央行的职能。对于某个采取通胀模型发行token的区块链项目，具备成为稳定币的潜力，并可通过调节“利率”大小（块奖励数）和公开市场操作（比如回购）来调节token供需。但是，如果一开始即利用调节供需的方式将token设计成稳定币，又会因为缺乏升值前景而面临社区激励不足的困境，因此，现阶段大部分采用通胀模型发行token的项目并没有采取任何措施去调节token供需，也并没有尝试保持token购买力的稳定，当所有权（升值性）与功能（流动性）无法在同一token上体现时，大多项目选择实现token的升值性（商品／股份），并另外引入稳定币（货币），来形成双token的生态模型。
 
没有设计稳定币的公链，长久来看，由于只拥有“所有权”，并不拥有自己的“货币”，因此无法自成王国。如果把公链看作一个国家，一个新的国家立国，应当如何吸引当地人使用本国发行的货币而不是美元来作为价值中介？未来，一个真正良性的区块链项目生态体系，必然会像国家一样发行稳定币作为内生货币来使用，体系内参与工作的人通过付出劳动时间来赚取稳定货币。
 应用型token的设计方法
 （1）token总量有上限
 应用型token的设计普遍采取积分+股份相结合的形式，可以完全把token看作项目所有权的代表。应用型token总量固定，一方面，类似积分的特性，许多团队许诺token持有者可以享受使用token换取某种服务或抵扣某种费用的权利，比如某些交易所提出的token抵扣交易手续费等，此外，团队还可以制定运营方案，利用积分发放的方式来免费发放token，以此提升社区活跃度。另一方面，因为token具备股份特性，使得token的持有者可以通过项目团队主导的token分红、token回购销毁等方式来享有项目发展的红利。在为应用设计token时，要注意应用的市值通常较小，大部分市值可能落在1亿-100亿之间，因此，应用型token的发行数量不宜超过100亿，应根据估值将总币量设定在1000万-100亿之间，以便以法币计价时，每个币的价格在0.01-1000元之间，有利于投资者间的沟通和交易。
 
以BNB（币安币）为例：
 BNB总量被限定为2亿个，50%归ICO投资人所有，40%归团队，剩下10%归私募投资人所有。持有BNB的用户，在币安平台上交易，在前5年可以享有逐年递减的手续费折扣优惠。此外，项目团队会在每季度拿出当季净利润的20%用于回购BNB，并将回购来的BNB销毁，直至所有BNB总量为1亿个为止。
 
设计应用总量有上限的token时一共有4个可调整的关键参数：
 
token总量
投资人、团队、基金会、矿工等利益相关群体的分配比例
积分运营方案：运营活动中token的免费发放／使用系统时实行费用抵扣
股份分红方案：将净利润用于回购token再销毁／将净利润按照持币比例直接分配给持币人（净利润通常为另一种token，比如BTC、ETH等）
 
（2）token总量无上限（股份增发）
 无论是现实中的公司，还是区块链项目，都可能存在再融资的需求，这时可能面临配股、增发或是发行可转债等情景。由于应用型token基于公链创建，所有特性受制于公链所能提供的功能。比如在公链项目Waves中，提供了资产增发的选项，基于Waves发行的应用型token，均可实现token增发的功能。
 总结
 公链的token经济模型设计较为复杂，目前大部分区块链项目所采取的token设计方式也并非最完美的方案，公有区块链项目通常野心勃勃，试图建造一个自成体系的生态王国，而自身发行的token，则是这种体系下的“法定货币”，项目开发者尝试解决许多在现实经济体系下仍未完美解决的问题，尽管技术是如此重要，但是经济模型的完备与否将对区块链项目的长久发展产生影响。现阶段，采用——直接发行token+稳定币的方式比总量有上限的发行方式更具优势，这种方式发行的双token更接近“股份+货币”而非“商品”，有利于生态体系的建立，而token在后续分发机制下的持续分配，也代表着项目对于激发各利益群体参与项目积极性的尝试，如何权衡各方利益，也是各区块链项目对人性中共识的探索。
 
小鱼企业级区块链底层主链，致力于打造最具易用性的区块链基础工具。基于区块链底层技术特性，通过安全可靠的去中心化信任机制、高效稳健的系统性能，贴合所需的行业场景，便捷地部署基础链、智能合约，快速落地区块链应用及搭建区块链商业生态。为您提供安全、高效、低成本的区块链应用基础设施。
 
相比之下，应用型token可以被直接视作股份，设计者们可以直接根据现实中公司股份的发行方式来设计token，使用证券特性更为完备的公链来发行股份token，更利于项目长足地发展。历史上许多有名的公链项目，例如Nxt、Peercoin和Waves等，都曾尝试以金融资产的发行为切入点，来为应用型项目提供底层证券服务。
 
www.xyqkl.cn

Refresh_token机制：
 
Refresh_token的作用是刷新AccessToken。认证服务器会提供一个刷新接口，我们传入Refresh_token和client_id，认证服务器通过后会返回一个新的AccessToken。但是为了安全，Oauth2.0引入了两个措施：
 1，要求refresh_token必须保存在客户端的服务器上，调用refresh_token的时候一定是从服务器到服务器的访问。
 2，OAuth2引入了Client_Secret机制。每一个Client_id,都对应一个Client_Secret。这个Client_Secret会在客户端申请Client_id时，随Client_id一起分配给客户端。客户端把他们都保存在服务器上，刷新Refresh_token时，需要验证这个Client_Secret。

前言：
 一直想写一篇博客，对token进行详解一下，也是对以前学的知识进行整理，所以今天在此记录一下。另外自己开通的博客还在备案中，等开通成功后，将会在自己的博客上发表，敬请期待。
 
什么是token?
 
我们在登陆设计的时候就要设置token。为什么要设置token呢。没有token会怎样呢？HTTP是无状态的，一次请求结束，连接断开，等待下一次服务器再次收到请求，他就不知道这个请求是哪个用户发过来的。所以对于应用而言，我们需要他是有状态管理的，以便于服务端能够准确知道是哪个用户发起的，从而判断该用户是否有权限继续这个请求。
 所以token也就是一个令牌，亦是一种服务端无状态的认证方式。
 
什么是session、什么是cookie?
 
前面介绍了token,也在这里介绍一下session和cookie，因为这三个都是在登陆设计会出现的。
 什么是Cookie呢，他是一个非常具体的东西，就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现得一种数据存储功能。Cookie有服务器生成，发送给浏览器，浏览器把cookie以键值对形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器，由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie是有限制的。
 如果服务器返回的一个cookie，没有指定其expire time，那么表明此cookie有效期只是当前的session，即是session cookie，当前session会话结束后，就过期了。对应的，当关闭（浏览器中）该页面的时候，此cookie就应该被浏览器所删除了。
 什么是Session呢？当我们和别人交谈的时候，这就是一个会话。而与我们交谈的人也会因某些特征而被区分。服务器要知道当前发出请求给自己是谁，所以为了区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个身份标识。默认都采用cookie的方式。
 
token的使用
 
token的本质就是一个唯一标识符的字符串，可以有UUID生成，也可以有用户ID根据算法进行加密生成，取到token之后在进行解密，取出用户的ID。
 token的保存可以放到数据库里或者缓存，但是放进数据库会严重消耗服务器的资源，所以建议放到redis缓存中，这样简易操作，并且加快了查询速度。
 我在网上看到了一种token过期的处理方式，也在这里说一下把：
 
方式一
 前端登陆获取token后，每次请求都会携带token;
 前端每次携带token发起请求时，后端都把这个token的有效期更新为最大。
 如果很久没有使用，导致token过期，前端请求时后端会返回指定的状态码，前端根据状态码跳转到登陆页面。
 
总结
 
session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookie
cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。
token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。
 
分享一个用户登陆功能设计思路
 
1. 用户登录注册
 
登录注册页面前端部分内容，关注的重点还是用户账号和密码在js代码里要做对应正则的匹配，这是验证的第一步，保证用户输入格式的正确性同时也从一方面减少用户向后台发送没必要的错误请求。前端向后端请求的方式使用POST
 
2.用户密码安全性
 
密码要如何保存， 明文存入数据库？当然非常非常非常不推荐， 由于大多数客户的习惯都是使用相同的密码， 如果明文在发生信息泄露的情况下容易发生撞库的事情。所以在密码的保存上最好在后台使用“密钥 + 不可逆加密算” 如 sha1，sha256等有hash算法的不逆的加密算法进行加密后再存入数据库。
 
3. 登录状态的保存
 
由于http协议是无状态的， 所以要记录用户的登录状态就要靠后台相应数据的维护来记录， 我们通常都是登录成功后在seesion中保存登录用户， 然后将用户登录通过cookie返回到客户端， 通过比对cookie和seesion信息来验证用户是否登录。
 
4. 防止cookie被盗用
 
为了防患cookie被盗用的情况还要在cookie中添加token、登录序列。这两个都是使用MD5进行加密的随机字符串， 作用就是在每次登录验证时， 同时验证token和登录序列还有ip地址， 因为在每次登录验证成功时都会刷新token， 如果cookie被盗用在正主使用旧cookie时出现登录序列相同， token不同而且ip地址多次变更的情况就要记录下此用户账户异常， 并且删除后台session里的登录记录，并提醒用户。
 
5. 密码找回功能
 
因为后台密码是加密没法提供明文密码的找回， 所有可以设计通过手机短信验证或者邮箱验证， 验证成功后通过直接设置新密码的形式来进行， 对于重置密码的url地址为了安全起见要通过加入时间戳和唯一随机数来保证这个链接只在某个事件内有效， 如果在密码修改成功或者事件过期， 就把这个唯一随机数给删除， 保存密码方式同上。
 
6. 防止恶意攻击
 
最有效的手段就是加入验证码， 同时记录某个用户在或ip在某个时段内如果尝试的失败登录次数超过一定阈值就限制其在几分钟内不能继续登录。

Cookie是浏览器用来保存用户信息的文件，可以保存比如用户是谁，购物车有哪些商品等。
 
Session是一次会话，会话是指我们访问网站的一个周期。
 
比如用户打开一个浏览器访问某个位的站点。
在这个站点点击多个超链接查看各个网页，然后关闭浏览器，整个过程称之为一个会话。
token是服务器返回的一个临时签名数据, 可以使用这个签名数据表面用户身份. 
 
 
 
为什么会有这三个东西呢?  都是一个目的, 服务器需要知道和自己通话的人是谁, 专业一点就是 服务器需要用某种机制来识别具体的用户.
 
这要从HTTP协议开始说起, HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话, 自然无法识别用户, 所以诞生了Cookie,session和token。
 

 
早期的时候, 我们访问浏览器的时候，浏览器会发送一个HTTP请求到服务器端；
 
服务器会发送一个HTTP响应到客户端，其中包括Set-Cookie，意思就是浏览器建立一个cookie保存服务器指定的内容，比如用户信息和用户操作信息；
 
浏览器保存好信息之后，下次我们再次访问网站的时候，浏览器再发送HTTP请求到服务器端时都会携带之前保存的cookie；
 
服务器端会从收到的cookie中识别用户身份，就能让页面为你提供专门属于你的内容了。
 
cookie 可以让服务端跟踪每个客户端的访问，但是每次客户端的访问都必须传回这些 Cookie，如果 Cookie 很多，这无形地增加了客户端与服务端的数据传输量，
 
 
 
cookie具有以下特点
 
cookie存储的数量和字符数量都有限制，只能存储几十个，不超4096左右个字符。
 Cookie具有不可跨域名性
 
 
　　很多网站都会使用Cookie。例如，Google会向客户端颁发Cookie，Baidu也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Baidu颁发的Cookie呢？或者Google能不能修改Baidu颁发的Cookie呢？
 
 
　　答案是否定的。Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操作Google的Cookie，而不能操作Baidu的Cookie。
 
 
　　Cookie在客户端是由浏览器来管理的。浏览器能够保证Google只会操作Google的Cookie而不会操作Baidu的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Baidu的域名不一样，因此Google不能操作Baidu的Cookie。
 
 
需要注意的是，虽然网站images.google.com与网站www.google.com同属于Google，但是域名不一样，二者同样不能互相操作彼此的Cookie。
 
 
cookie虽然不可跨域名, 但是存储在用户浏览器里也是不安全的，任何人都能直接查看。
 
我们以谷歌浏览器为例查看cookie，我们右击找到检查，点击打开浏览器控制台，或者按F12
 
 
找到Console
 
 
 
在其中输入document.cookie即可查看
 

session在计算机网络应用中被称为“会话控制”。不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。在服务端保存Session的方法很多，内存、数据库、文件都有。
 
1. 客户端浏览器访问网站的时候,
 
2. 服务器会向客户浏览器发送一个每个用户特有的会话编号sessionID，让浏览器写入到cookie里(大多数情况)。服务器同时也把sessionID和对应的用户信息、用户操作记录在服务器上，这些记录就是session。
 
3. 客户端浏览器再次访问时，会发送cookie给服务器，cookie中就包含sessionID。
 
4. 服务器从cookie里找到sessionID，再根据sessionID找到以前记录的用户信息就可以知道他是谁, 之前操控哪些、访问过哪里。
 
 
 
从流程上看cookie和session看起来就是一套东西啊,  其实是不一样的, cookie是文件, 可以存任意东西, sessionID只不过是存的一种数据, 而session数据保存在服务器, 只不过session常见实现方式是借助cookie,  但是可以不用cookie, 使用URL地址重写来实现session。
 

随着Web，应用程序，以及移动端的兴起，session验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。
 
基于服务器验证方式暴露的一些问题
 
 
Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
 
 
可扩展性：在服务端使用Seesion存储登录信息，伴随而来的是可扩展性问题, 多个服务器之间如何同步sessionID。
 
 
CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
 
 
CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。
 
在这些问题中，可扩展性是最突出的。
 
比如说服务端用两个机器组成了一个集群， 小F通过机器A登录了系统， 那sessionID会保存在机器A上， 假设小F的下一次请求被转发到机器B怎么办？ 机器B可没有小F的 sessionID啊。
 
有时候会采用一点小伎俩： session sticky ， 就是让小F的请求一直粘连在机器A上， 但是这也不管用， 要是机器A挂掉了， 还得转到机器B去。
 
那只好做session 的复制了， 把sessionID在两个机器之间搬来搬去， 快累死了。

 后来有个叫Memcached的支了招： 把session id 集中存储到一个地方， 所有的机器都来访问这个地方的数据， 这样一来，就不用复制了， 但是增加了单点失败的可能性， 要是那个负责session 的机器挂了， 所有人都得重新登录一遍， 估计得被人骂死。

 也尝试把这个单点的机器也搞出集群，增加可靠性， 但不管如何， 这小小的session 对服务端来说是一个沉重的负担.
 
因此有必要去寻求一种更有行之有效的方法。于是有人就一直在思考， 我为什么要保存这可恶的sessionID呢， 只让每个客户端去保存该多好？
 
可是如果不保存这些sessionID , 怎么验证客户端发给我的sessionID 的确是服务端生成的呢？ 如果不去验证，我们都不知道他们是不是合法登录的用户， 那些不怀好意的家伙们就可以伪造sessionID , 为所欲为了。
 
嗯，对了，关键点就是验证 ！ 
 
比如说， 小F已经登录了系统， 服务端给他发一个令牌(token)， 然后把小F的 user_id和token在数据库(确切说是Redis+数据库)里做关联， 下一次小F 再次通过Http 请求访问我的时候， 把这个token 通过Http header 带过来不就可以了。
 
Token 中的数据是明文保存的， 还是可以被别人看到的， 所以不能在其中保存像密码这样的敏感信息, 一般用UUID随机生成一个不重复的字符串就行了, 还有其他方式生成token,比如JWT(Json Web Token)的Token认证, 对 "UserID+时间戳+签名信息"  然后使用MD5, SHA算法加密。
 
当然， 如果一个人的token 被别人偷走了， 那服务器也没办法， 服务器也会认为小偷就是合法用户， 这其实和一个人的sessionID 被别人偷走是一样的。
 
这样一来， 服务器就不保存sessionID 了，只是生成token , 然后验证token ， 用CPU计算时间获取了我的session 存储空间 ！
 
解除了sessionID这个负担， 可以说是无事一身轻， 我的机器集群现在可以轻松地做水平扩展， 用户访问量增大， 直接加机器就行。 这种无状态的感觉实在是太好了！
 
在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中，token是多用户下处理认证的最佳方式。
 
那些使用基于Token的身份验证的大佬们, 大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。
 
 
 
 
 
基于Token的身份验证的过程如下:
 
 
用户通过用户名和密码发送请求。
 
 
服务端验证,  返回生成的token 给客户端,  同时给数据库和Redis里关联token和用户信息。
 
 
客户端储存token,并且其后的每一次请求都添加token, token应该在HTTP的头部发送从而保证了Http请求无状态。
 
 
服务端查询Redis+数据库, 验证token并返回数据。
 
 
Tokens的优势
 
无状态
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
 
安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。
 
token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。
 
可扩展性
Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。
 
使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。
 
支持多平台跨服务器
只要用户有一个通过了验证的token，数据和资源就能够在任何平台(Android,ios, h5)任何服务器上被请求到。
 

最后做个三者的比较: 
 
cookie : 
 
1. cookie由服务器生成，保存在客户端浏览器。
 
2. 容易被劫持，不安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗。
 
3. cookie可以被用户禁止
 
4. 容量小, 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
 
session
 
1. session是由应用服务器维持的一个服务器端的存储空间, 没有对存储的数据量的限制，可以保存更为复杂的数据类型.
 
2. session 默认被存在在服务器的一个文件里, 但是实际中可以放在 文件、数据库、或内存中都可以。
 
3. 当用户量增多时，会对服务器造成较大压力。
 
4. Session的实现方式大多数情况用Cookie保存的，但是也可以使用URL地址重写。
 
5. 较安全,用户验证这种场合一般会用 session, 比如金融银行类的产品, 
 
token
 
1.无状态、可扩展
 
2.支持移动设备
 
3.跨服务器调用
 
4.安全