浅谈session,cookie和jwt(Json Web Token)认证方式

一基于cookie和session的会话管理机制
1.session和cookie会话机制的原理
session是存放在服务端的，而cookie是存储在客户端的用户登录成功的时候，生成session_id,以session_id为key，用户信息经过一系列的加密处理生成value,写入session,session信息可以写入文件，数据库、memcached，redis等等，推荐写入redis，提高访问的速度，然后把session_id写入cookie存放在客户端，每次请求的时候，都会携带cookie，需要用户信息的时候，根据cookies里面的session_id直接从文件或者数据库或者memcached里面取出session信息即可。

2 session和cookies的优缺点
1.cooike的安全性不好，攻击者可以利用本地cookie进行欺骗和CSRF攻击
2.使用cookies，在多个域名的情况下会出现跨域的问题
3.session存放在服务器端，短时间内如果有大量的用户，会影响服务器的性能，推荐使用menchched缓存
4.当有多台服务器的情况下，如何共享session也会是一个问题，也就是说，用户第一个访问的时候是服务器A，而第二个请求被转发给了服务器B，那服务器B如何得知其状态。

二.基于JWT的会话管理机制

1.jwt工作原理
首先用户发出登录请求，服务端根据用户的登录请求进行匹配，如果匹配成功，将相关的信息放入payload中，利用上述算法，加上服务端的密钥生成token，这里需要注意的是secret_key很重要，如果这个泄露的话，客户端就可以随意篡改发送的额外信息，它是信息完整性的保证。生成token后服务端将其返回给客户端，客户端可以在下次请求时，将token一起交给服务端，一般来说我们可以将其放在Authorization首部中，这样也就可以避免跨域问题。接下来，服务端根据token进行信息解析，再根据用户信息作出相应的操作。
2.JWT的优缺点

1.登录状态信息续签问题。比如设置token的有效期为一个小时，那么一个小时后，如果用户仍然在这个web应用上，这个时候当然不能指望用户再登录一次。目前可用的解决办法是在每次用户发出请求都返回一个新的token，前端再用这个新的token来替代旧的，这样每一次请求都会刷新token的有效期。但是这样，需要频繁的生成token。另外一种方案是判断还有多久这个token会过期，在token快要过期时，返回一个新的token。

2.用户主动注销。JWT并不支持用户主动退出登录，当然，可以在客户端删除这个token，但在别处使用的token仍然可以正常访问。为了支持注销，我的解决方案是在注销时将该token加入黑名单。当用户发出请求后，如果该token在黑名单中，则阻止用户的后续操作，返回Invalid token错误。这个地方我再稍微补充一下，其实这里的黑名单操作也比较简单，把已经注销的token存入比如说一个set中，那么在每次进行token验证时，先检查在set中是否已经存在，如果已经存在的话，则视为token已经失效，直接返回未授权。这一部分在上面的授权代码中也可以看到，不过我是放到redis缓存中的。

三.总结
目前来说jwt还不能完全代替基于cookie的方式，我们可以使用token防止CSRF攻击，使用redis集群解决session的共享问题等等。