cookie、session和token是解决“发出请求的用户是谁”问题的三种解决方案。
他们不是完全独立的，是互有关联的。
cookie作为最早解决“发出请求用户是谁”问题的方案，使用时，服务端将用户的信息直接写入cookie，通过请求头下发给用户，用户发出请求时，会将下发信息返回服务端，服务端取出cookie中的信息，判断用户登录情况，eg.当用户登录成功时，将isLogin=true存入cookie，一起下发给客户端，然后当用户发出某个需要登录以后才能才做的请求时，服务端会去检查cookie，判断isLogin字段是否存在，是否为true。
由于明文保存敏感信息在cookie中，存在cookie中信息被篡改的风险，比如存入了用户id和登录状态后，用户id被修改，就可以获取其他用户的权限，这显然是不能被接受的，于是出现了安全性更高的session方法。
session方法实际上是在cookie方式上的一种改进，在用户登录成功后，不再在cookie中存入敏感信息，而是存入一些标识符，即session_id，即一串随机生成的字符串，如session_id=aasdasdwq112131111，将这串字符串作为key，将用户的信息作为value存入到内存或数据库中，当用户发起需要登录权限请求的操作时，服务端从cookie中取出session_id对应的值，将该值作为key，从之前保存的地方取出用户信息，判断登录状态。
这种方式能够在一定程度上保证用户信息的安全，但又会面临新的问题，即用户数量一旦达到千万级，服务端内存的开销是非常大的，而且多个服务器之间session的维护是比较麻烦的，即使使用session服务器方式去处理，也会面临单点登录带来的风险，于是token验证方式产生了。
token方式也是cookie方式的一种延伸，当登录完成时，将一些不敏感的信息，加上秘钥，进行签名，将不敏感信息和签名通过cookie一起下发给客户端（也可以通过其他方式下发），客户端在请求需要登录权限接口时，将之前下发的信息一起发给服务端，服务端对其中不敏感信息进行签名，然后和客户端上传上来的签名进行对比，一致时说明用户登录成功。这种方式就很好的解决了多用户session内存开销过大，服务端单点登录等问题。
session和token本质区别是session是用空间换时间，而token是用时间换空间，各有利弊。
