现在SPA(Single Page Application, 单页面应用)和前后端分离已经是主流. 基于Token的验证非常适合这种构架.

Difference between Token-based Auth and Cookie-based Auth

基于Cookie的验证

基于Cookie的验证是有状态的 (stateful). 前后端都要为验证保存状态: 后端要保存active session的信息, 前端要用cookie保存sessionId. 流程如下:用户输入登录信息

服务器验证后, 创建session并保存到数据库

带着sessionId的cookie保存到浏览器中

接下来的所有请求, 后台通过cookie携带的sessionId以找到对应的session.

用户登出时, 前后端都要销毁session

基于Token的验证

近些年SPA, web API, 和IoT(Internet of Things, 物联网)的崛起带动了基于Token的验证, 通常就是指JWT(Json Web Token)

JWT是无状态的(stateless), 后端不必保存有关session的信息. 后端只需要验证每次请求中携带的Token即可验证请求的真实性.

Token通常以Bearer {JWT}的形式保存在Authentication header中, 也可以放到POST body或query parameter中.

流程如下:用户输入登录信息

服务器验证后, 返回一个签名(signed)的token. 该token存储在前端, 通常在localStorage中, sessionStorage或cookie也可以.

接下来的请求中token被加到Authentication Header中, 或者POST body / query parameter中.

后台解码JWT, 若token合法, 则处理请求

用户登出后, token从前端销毁, 无需与后端交互.

基于Token的验证的优势

无状态, 可扩展, 解耦合

基于Token的验证是无状态的, 后端无需存储状态. 每个token自己都保存了足够的验证所需要的信息.

后台的任务只剩下对token签名和验证token两项. 如果使用auth0之类的第三方服务进行token签名, 后台则只需要验证token.

跨域问题

Cookie适用于单域名或者子域名的情况, 但是跨域的话就麻烦了. 基于Token的验证则不关心域名.

在JWT中存储数据

使用Cookie时, 你只保存一个sessionId. 但是你可以在Token中保存一些别的元数据. JWT文档中规定了一些预留/共有/私有的claim(声明, 即JWT的字段). 这意味着你可以在JWT中保存诸如userId, expiration, email, permission之类的信息.

性能

基于Cookie的验证需要依赖数据库保存session信息, 查询数据库往往比验证token要耗时得多. 而且JWT允许你存储一些常用信息, 比如用户权限, 这样又省去一些数据库查找开销.

移动设备

原生平台上, cookie的使用会遇到一些问题/限制. 但是Token在iOS或者Android上实现都非常简单. 对IoT设备这种没有cookie store概念的终端, Token更是最佳选择.

常见问题

JWT大小

JWT最大的问题是大小. 最小的JWT也比存储sessionId的cookie要大. 因此不要向JWT中加入太多claim.

JWT的存储

最常见的是存储在localStorage中. 但是localStorage中的数据无法被另一个域名或者子域名访问.

存在cookie中的一个问题是, cookie的最大尺寸是4kb, 你无法保存很多claim.

存在sessionStorage的话, 一旦用户关闭浏览器, 登录信息就被清空了.

XSS和XSRF攻击

要注意Cross Site Scripting (XSS)和Cross Site Request Forgery (XSRF or CSRF)两种攻击.

XSS攻击发生在当用户可以在你的网站/app运行自己的代码的时候. 常见情况就是你不对用户输入进行清理, 导致用户输入的恶意代码被执行. Angular等常见的框架会自动清理用户输入, 阻止用户代码的执行. 如果你没用具有这类功能的框架, 你可以选择一些插件比如caja.

对于XSRF攻击, 如果你用localStorage就不用担心. 但是如果你用cookie的话, 就要防范这类攻击. XSRF的攻击方式和解决方法见这里.

让token有较短的过期时间, 可以确保当token被偷时, 它没多久就会失效. 另外你可以维护一个被盗token的黑名单. 最后, 终极大招就是修改签名算法, 这样所有的token都会失效, 所有用户都要重新登录. 这是非正常时期的手段, 轻易勿用.

Token会被编码, 但不会被加密

Token中的header和payload是base64url编码的(注意不是base64), 它本身是用HMACSHA256算法进行签名的. 这意味着, 你存储在payload中的信息是公开的, 非加密的. 所以绝不要在token中存储密码之类的隐私信息.

如果你非要存储隐私信息, 可以使用JWE(JSON Web Encryption), 它让token无法被除了服务器以外的所有人解读. JOSE提供了一个很好的JWE框架, 还有对很多流行框架如NodeJS和Java的SDK.

参考

作者：柳正来

链接：https://www.jianshu.com/p/000f5896d6fd