Session与JWT方式认证

认证就是让服务器知道你是谁，授权就是服务器让你知道你什么能干，什么不能干
认证授权俩种方式：Session-Cookie与JWT

Session

服务器只有一台，客户端却有千千万。怎么能够让服务器知道当前请求服务的是哪台客户端呢？我们举个生活中的例子：
你去图书馆（服务端）借书（请求服务）。先得办卡（登录获取session_id）吧，放兜里（cookie）。去刷卡处刷卡看看卡是不是伪造的，看看卡里的信息和数据库比对下看看有没有过期等等（检查session_id是否被篡改，是否失效根据session_id查询下内存或者数据库(通常是内存数据库)里对应的有没有过期）。过期不给进重新办卡（重新登录认证），没过期就给进（返回你请求的结果）

流程就是这样子：
当 client通过用户名密码请求server并通过身份认证后，server就会生成身份认证相关的 session 数据，并且保存在内存或者内存数据库。并将对应的 sesssion_id返回给client，client会把保存session_id（可以加密签名下防止篡改）在cookie。此后client的所有请求都会附带该session_id（毕竟默认会把cookie传给server），以确定server是否存在对应的session数据以及检验登录状态，权限啦巴拉巴拉......如果通过校验就该干嘛干嘛，否则重新登录咯。
前端退出的话就清cookie。后端强制前端重新认证的话就清或者修改session。

JWT

这里就不介绍jwt的三部分组成、由什么组成、怎么生成加密了。
日常的举个生活中的例子吧：
你去游乐园（服务端）玩耍（请求服务）。先得买门票（登录获取token）吧，放兜里（cookie、header......）。去检票口检票看看票有没有过期（检查token是否失效）。过期不给进重新买票（重新登录认证），没过期就给进（返回你请求的结果）
有没有觉得和Session有什么不一样？server不用存储信息了。一切都存在客户端。个人觉得这就是最大的不同。
这里大致列下俩者区别，一些比如JWT更简单、APP对支持不易的一些已经解决或者细究觉得很扯的或者大同小异的不在此列

	Session	JWT
安全性	得考虑CSRF攻击	无需考虑
存储	需要俩端都存储	客户端存储即可
可控性	服务端可随时修改权限....	只能等待Token过期

安全性

首先这个还真不算什么。现在WEB框架该都内置了防CSRF。而且既然知道有这个编写代码注意下也是应该的。

存储

这个还真是，JWT真心可以，不过得看情况。如果考虑可控性，那你简直想哭。

可控性

服务端存储认证相关信息还是很有必要的。举个栗子。如果你发现你账号被异地登录，你肯定想着换密码呀。换了以后发现我去，怎么又被异地登录。因为Token未过期，人家还是可以使用。这就很麻烦了。服务端根本不能控制。这时候你会记得session得好。

其他

还真没什么好说的，可能有人觉得JWT加密解密开销大、有人觉得JWT太长占空间、session太老了该让位了、JWT只需要存储Token在客户端方便、JWT加密感觉好安全不一而足......