### token token 也称作令牌，由uid+time+sign\[+固定参数\] token 的认证方式类似于**临时的证书签名**, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景；所谓无状态就是服务端并不会保存身份认证相关的数据 token在客户端一般存放于localStorage，cookie，或sessionStorage中。在服务器一般存于数据库中 #### 组成 * uid: 用户唯一身份标识 * time: 当前时间的时间戳 * sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接 * 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库 ### token认证流程 token 的认证流程与cookie很相似 * 用户登录，成功后服务器返回Token给客户端。 * 客户端收到数据后保存在客户端 * 客户端再次访问服务器，将token放入headers中 * 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码 ### token优点 * 在Token中包含足够多的用户信息，JWT能轻松实现单点登录，因为用户的状态已经被传送到了客户端。 * 不存在Cookie跨域的限制问题，也不存在Cookie相关的一些攻击漏洞，例如CSRF。 * 因为有签名，所以JWT可以防止被篡改。 * 适用于API的安全机制，适用于移动客户端与PC客户端的开发，此时Cookie是不被支持的；Token方案则简单有效，可以用一套Token认证代码来应对浏览器类客户端和非浏览器类客户端。 * Token已经标准化，有成熟的标准化规范——JSON Web Token（JWT），多种主流语言也都提供了支持（如.NET、Ruby、Java、Python、PHP）。 ## token可以抵抗csrf，cookie+session不行 假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单，该表单提交src为`http://www.bank.com/api/transfer`，body为`count=1000&to=Tom`。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击