[HTTP趣谈]身份认证(Cookies vs Tokens)

只要是需要登录的系统，就必然涉及到“身份验证”，那么，前端是如何配合后台做身份验证呢？

一般由两种模式，Cookies和Tokens。前者是传统模式，后者乃新起之秀。先看一张对比图，大致了解二者差异：

cookie-vs-token.png

共同点

• 都是利用HTTP request header来传递身份信息
• 都需要后台给予验证身份的唯一ID（也可理解为唯一的验证信息）

下面分别分析这两种模式。

Cookies

Cookies验证是有状态（stateful）的。这意味着，权限信息（比如session ID）必须同时在客户端和服务端维护。服务端需要根据session cookies信息去数据库查询用户相关信息；客户端每次发起请求时都必须带上Cookies信息作为身份验证。

Cookies有如下特征：

1. 不需要前端存储 Cookies由后台设置（response header里的Set-Cookie），浏览器会在后续的请求中自动加上Cookies信息。
2. 有CSRF(跨站点伪造请求)风险 Cookies是不支持跨域访问的，一般只能在某个域名及其子域名下被访问。但是，由于Cookies可以通过JS代码获取（document.cookies），由此，可能会引发安全问题，比如著名的CSRF攻击（跨站请求伪造）。
3. 移动端用在使用cookie时有各种不便利和局限 移动端平台和Cookies配合并不是太好，可能会在Cookies使用上有局限性。
4. 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有如下特征：

1. Token值同样需要服务端提供（通过API返回） 和Cookies不同，返回值不需要挂载在Set-Cookie上，而是利用其它response header或者response body返回Token值；
2. 需要客户端存储 和Cookies不同，浏览器无法自动在下一次请求中自动挂载身份信息。客户端必须自行存储Token值（建议用localstorage），然后在后续请求中通过设置request header来传递Token信息；
3. 无CSRF风险
4. 适合移动端身份认证
5. 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协议。

参考文章：Cookies vs Tokens: The Definitive Guide