DVWA的Token机制

Tocken的生成机制比较类似于Session ID，但是更加多样化，可以任意定制而不需要依赖于应用服务器本身的约束，甚至可以完整处理无状态请求，并且还能保持请求被验证。

一Tocken和Session的相同之处

通常情况下来说，Session ID的生成器是基于服务器端的Session机制，并且有固定的失效时间，在失效时间前，客户端只要通过Cookie在请求中将Session ID发回给服务器，服务器便完成了校验，而不关心是否真实的用户发送的请求。在这一点上，Token也可以实现，比如下图的处理流程与Session完全一致。

虽然上图的流程是相同的，但是内含的处理逻辑可能完全不一样，比如Session通过保存到服务器来进行检验，而Token很有可能是直接解密来进行校验的。（看具体的Token的实现方式）

另外，Session变量的存储需要内存或硬盘空间，并且无法支持多服务器多应用共享Session，比如你的企业中有PHP和Java开发的多套应用系统，那么如果内部员工要使用多个应用，就需要在每个应用中去登录，非常麻烦。

而我们期望不同系统可以实现一站式登录或者单点登录，提高用户体验和安全性如下图

要实现以上效果，则需要依赖于Token而不是Session。Token可以是一段用户名+服务器事件，用户ID+网卡MAC，用户名+签名的加密字符串，也可以是一段随机值，可以有特定的有效期，也可以每一个请求与都不一样。Token的加密可以使用后对称加密也可以使用非对称加密，完全取决于Token认证服务器的业务需要。如下图，通过认证服务器也可以实现单点登录（SSO:Single SignOn）

在使用过程中，Session的状态维持通常是基于请求的Cookie字段完成，是解决HTTP无状态的理想方案。而Token可以选择维持状态或者不维持状态。需要维持状态的情况下，可以选择使用服务器存储方案（与Session类似），如果不需要维持状态，则只需要将Token进行解密即可完成验证（每次服务器都要解密）。另外，Token值通常是直接放在GET或者POST请求的参数中发给服务器的，而不是请求头里的Cookie。

（1）存储型Token或Session：消耗存储空间，但是不消耗解密的CPU资源

（2）解密型Token：不消耗存储空间，但是消耗CPU资源进行解密运算（通常使用对称加密，非对称加密对CPU的资源消耗的更多）