只要是需要登录的系统,就必然涉及到“身份验证”,那么,前端是如何配合后台做身份验证呢?
一般由两种模式,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可以在同一域名下或者同一主域不同子域下共享,一旦跨主域,就无法共享
如果遇到跨域共享身份信息的情况,就必须靠服务器协助(例如单点登录:一个身份,需要登录多个主域)
小贴士
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?代码如下:
// 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
微信公众号:
网友评论