只要是需要登录的系统，就必然涉及到“身份验证”，那么，前端是如何配合后台做身份验证呢？
一般由两种模式，Cookies和Tokens。前者是传统模式，后者乃新起之秀。先看一张对比图，大致了解二者差异：
cookie-vs-token.png
共同点
- 都是利用HTTP request header来传递身份信息
- 都需要后台给予验证身份的唯一ID（也可理解为唯一的验证信息）
下面分别分析这两种模式。
Cookies
Cookies验证是有状态（stateful）的。这意味着，权限信息（比如session ID）必须同时在客户端和服务端维护。服务端需要根据session cookies信息去数据库查询用户相关信息；客户端每次发起请求时都必须带上Cookies信息作为身份验证。
Cookies有如下特征：
- 不需要前端存储
Cookies由后台设置（response header里的Set-Cookie），浏览器会在后续的请求中自动加上Cookies信息。 - 有CSRF(跨站点伪造请求)风险
Cookies是不支持跨域访问的，一般只能在某个域名及其子域名下被访问。但是，由于Cookies可以通过JS代码获取（document.cookies），由此，可能会引发安全问题，比如著名的CSRF攻击（跨站请求伪造）。 - 移动端用在使用cookie时有各种不便利和局限
移动端平台和Cookies配合并不是太好，可能会在Cookies使用上有局限性。 - Cookies可以在同一域名下或者同一主域不同子域下共享，一旦跨主域，就无法共享
如果遇到跨域共享身份信息的情况，就必须靠服务器协助（例如单点登录：一个身份，需要登录多个主域）
cookie.png
小贴士
API跨域请求时，如果请求方式为JSONP，那么，浏览器会自动在request请求中带上Cookies。
* JSONP利用script标签实现跨越，而script标签的src属性发起的请求类似资源文件请求；
* 浏览器有一个特点：从WEB页面产生的文件请求都会带上COOKIE；
如果是CORS跨域，客户端AJAX请求必须设置withCredentials头信息为true。
Token
Token是无状态的（stateless）。也就是说，服务端不需要在数据库中存储和Token相关的字段，Token本身就已经包含了用户的所有信息（生成Token的方式很多，其中比较著名的是JWTs: JSON Web Tokens）。
客户端一般在request header里面利用Authorization头传递Token值，格式为Bearer {JWT}（该格式并不是绝对的，要根据服务端具体情况来设置）。
Token有如下特征：
- Token值同样需要服务端提供（通过API返回）
和Cookies不同，返回值不需要挂载在Set-Cookie上，而是利用其它response header或者response body返回Token值； - 需要客户端存储
和Cookies不同，浏览器无法自动在下一次请求中自动挂载身份信息。客户端必须自行存储Token值（建议用localstorage），然后在后续请求中通过设置request header来传递Token信息； - 无CSRF风险
- 适合移动端身份认证
- Token支持各类跨域
token.png
客户端如何设置Token？代码如下：
// JS
var res = new XMLHttpRequest();
...
req.setRequestHeader('Authorization',"Bearer " + token);
// JQuery
$.ajax({
url: api,
type: "GET",
headers: { "Authorization": "Bearer " + token}
})
小结
目前，大部分应用还是用Cookies做身份验证（尤其是PC端）；移动端HTML5页面（Hybird App）API的权限验证，更多会采用Token，并且走HTTPS协议。
