token相关

Token 是在服务端产生的，如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位

Token 能解决哪些问题呢？有如下几点：

• Token 完全由应用管理，所以它可以避开同源策略。

• Token 可以避免 CSRF 攻击(http://dwz.cn/7joLzx)。

• Token 可以是无状态的，可以在多个服务间共享。 

        Token 是在服务端产生的，如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。现在的很多的网站都会有记录密码的功能，正是借助了token进行了安全验证，并读取存放在客户端的cookies中的token的值与上次存入到数据库中的值是否一致，如果一致则可安全登录，否则则会用户输入密码，无论token一致或不一致，在成更登录后都会重新改变token的值，并同时存到客户端的cookies中。

       

无状态 Token

 

如果我们把所有状态信息都附加在 Token 上，服务器就可以不保存。但是服务端仍然需要认证 Token 有效。

 

不过只要服务端能确认是自己签发的 Token，而且其信息未被改动过，那就可以认为 Token 有效——“签名”可以作此保证。

 

平时常说的签名都存在一方签发，另一方验证的情况，所以要使用非对称加密算法。

 

但是在这里，签发和验证都是同一方，所以对称加密算法就能达到要求，而对称算法比非对称算法要快得多（可达数十倍差距）。

 

更进一步思考，对称加密算法除了加密，还带有还原加密内容的功能，而这一功能在对 Token 签名时并无必要——既然不需要解密，摘要（散列）算法就会更快。你可以指定密码的散列算法，自然是 HMAC。

 

上面说了这么多，还需要自己去实现吗？不用！JWT 已经定义了详细的规范，而且有各种语言的若干实现。

 

不过在使用无状态 Token 的时候在服务端会有一些变化，服务端虽然不保存有效的 Token 了，却需要保存未到期却已注销的 Token。

 

如果一个 Token 未到期就被用户主动注销，那么服务器需要保存这个被注销的 Token，以便下次收到使用这个仍在有效期内的 Token 时判其无效。有没有感到一点沮丧？

 

在前端可控的情况下（比如前端和服务端在同一个项目组内），可以协商：前端一旦注销成功，就丢掉本地保存（比如保存在内存、Local Storage 等）的 Token 和 Refresh Token。

 

基于这样的约定，服务器就可以假设收到的 Token 一定是没注销的（因为注销之后前端就不会再使用了）。

 

如果前端不可控的情况，仍然可以进行上面的假设，但是这种情况下，需要尽量缩短 Token 的有效期，而且必须在用户主动注销的情况下让 Refresh Token 无效。

 

这个操作存在一定的安全漏洞，因为用户会认为已经注销了，实际上在较短的一段时间内并没有注销。如果应用设计中，这点漏洞并不会造成什么损失，那采用这种策略就是可行的。

 

在使用无状态 Token 的时候，有两点需要注意：

• Refresh Token 有效时间较长，所以它应该在服务器端有状态，以增强安全性，确保用户注销时可控。

• 应该考虑使用二次认证来增强敏感操作的安全性。

 

到此，关于 Token 的话题似乎差不多了——然而并没有，上面说的只是认证服务和业务服务集成在一起的情况，如果是分离的情况呢？

 

                                                                                                                                                                                                                

转载于:https://www.cnblogs.com/zhaona123/p/8549780.html