Phylogeny
1 Long, long ago, Web browsing is basically a document only, since it is the view, as a server, who need not be recorded in a certain period of time what documents are viewed, every request is a new HTTP protocol, it is to ask plus response, especially since I do not remember who had just made a HTTP request, each request is new for me. This time is very Hi skin.
2, but with the rise of interactive Web applications, like online shopping site, website, etc. need to log in, and immediately faced a problem, that is to manage the session, who log must remember who go to their shopping put the car in the commodity, which means I must separate area for everyone, this is not a small challenge,Because HTTP request is stateless, so come up with ways is to give everyone to send a session identifier (session id), It means a random string that is different for each person received, each time you initiate to me when HTTP requests, this string to take along came together, so I can distinguish who is who
3, so it is very Hi skin, but the server is not leather Hey, everyone just needs to keep the session id, session id and the server you want to save everyone! If access to the server and more, and have made hundreds of thousands, even hundreds of thousands.
This is said to be a huge server overhead, severely limits the scalability of the server, for example, I use two machines form a cluster, small machine A through F logged into the system, and that session id will be stored on machine A, assuming that F is a small request is forwarded to the machine B how to do? Session id machine B may not small F ah.
Sometimes uses a little trick: session sticky, is to make a small request F has been sticking on the machine A, but this is not effective, and if the machine A hang, had to go to the machine B to go.
That had to make a copy of the session, the session id moved around between two machines quickly exhausted.
Later, a man named Memcached support of a trick: the session id stored centrally in one place, all the machines are used to access the data of this place, this way, they do not copy, but it increases the likelihood of a single point of failure, if that session is responsible for the machine hung up, everyone had to log in again and again, it is estimated Masi people.
Also try to put this machine also come up with a single point cluster, increase reliability, but no matter what, this little session for me is a heavy burden
4, so some people have been thinking about why I want to save this nasty session it, just let each client to preserve nice?
But if you do not save the session id, how to verify a client's session id sent to me indeed is my generation it if they do not verify, we do not know that they are a legitimate user is not logged on, those guys can ill forgery session id, do whatever they want.
Ah, yes, the key point is to verify!
For example, a small F has logged into the system, I sent him a token (token), which contains a proposed user id small F, the next time I visit small F again through Http request, when this token via Http header with not over it.
But this session id and there is no essential difference ah, anyone can be forged, so I have to do something about, so that others can not fake.
Then the data to make it a signature, for example, I algorithm HMAC-SHA256, a plus only I know the key, the data make a signature, the signature and the data together as a token, because the others do not know the key , the token can not be forged.
This token I do not save, when this small token to F me over when I use the same HMAC-SHA256 algorithm and the same key, the data re-calculated once the signature, and the signature token make a comparison, If so, I know that a small F has logged over, and can be taken directly to the user id small F, if not identical, the data portion certainly been tampered with, I'll tell the sender: Sorry, no certification.
Token data is stored in plain text (although I will do next with the Base64 encoded, but not encrypted) , it can still be seen by others, so I can not in which to save sensitive information such as passwords.
Of course, if a person's token is stolen someone else, then I have no idea, I would think the thief is a legitimate user, and this is actually a person's session id was stolen someone else is the same.
As a result, I will not save the session id, I just generate token, then verify that token, I use my CPU time to obtain my session storage space!
The lifting of the session id of this burden can be said that nothing out of danger, my machine clusters can now easily do horizontal scaling, user traffic increases, plus the machine directly on the line. This stateless feeling is wonderful!
Cookie
A cookie is a very specific thing, A data refers to the browser which can be permanently stored, is merely a data storage function of the browser implementation.
cookie generated by the server, sent to the browser, the browser cookie saved to a text file in a directory to kv form, will send the cookie to the server the next time you request the same site。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
Session
session 从字面上讲，就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他就是张三。
session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。
服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
Token
在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中，tokens 是多用户下处理认证的最佳方式。
以下几点特性会让你在程序中使用基于Token的身份验证
1.无状态、可扩展
2.支持移动设备
3.跨程序调用
4.安全
那些使用基于Token的身份验证的大佬们
大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。
Token的起源
在介绍基于Token的身份验证的原理与优势之前，不妨先看看之前的认证都是怎么做的。
基于服务器的验证
我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。
在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。
随着Web，应用程序，已经移动端的兴起，这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。
基于服务器验证方式暴露的一些问题
Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。
CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。
在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
基于Token的验证原理
基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。
这种概念解决了在服务端存储信息时的许多问题
NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
基于Token的身份验证的过程如下:
1.用户通过用户名和密码发送请求。
2.程序验证。
3.程序返回一个签名的token 给客户端。
4.客户端储存token,并且每次用于每次发送请求。
5.服务端验证token并返回数据。
每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。
需要主要的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。
实现思路：
1.用户登录校验，校验成功后就返回Token给客户端。
2.客户端收到数据后保存在客户端
3.客户端每次访问API是携带Token到服务器端。
4.服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码
5.当我们在程序中认证了信息并取得token之后，我们便能通过这个Token做许多的事情。
我们甚至能基于创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的token）
Tokens的优势
无状态、可扩展
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成一些拥堵。
但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。
安全性
请求中发送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。
多平台跨域
我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。
Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.
As long as a user has passed the authentication token, data and resources can be requested at any domain to.
Access-Control-Allow-Origin: *
Based on the time standard created token, you can set some options. We will be more fully described in a future article, but the standard usage Tokens will be reflected in the JSON Web.
Recently used applications and documents are JSON Web Tokens of supply. It supports a number of languages. This means that in the future you can really use to convert your authentication mechanism.
Transfer: a thorough understanding of cookie, session, token - ink Yan Dian - blog Park