✅技术社区项目—JWT身份验证
通用的JWT鉴权方案
JWT鉴权流程
基本流程分三步:
● 用户登录成功之后，后端将生成的jwt返回给前端，然后前端将其保存在本地缓存;
● 之后前端与后端的交互时，都将iwt放在请求头中，比如可以将其放在Http的身份认证的请求头 Authorization ，也可以通过自定义的请求头来传递
● 后端接收到用户的请求，从请求头中获取iwt，然后进行校验，通过之后，才响应相关的接口:否则表示未登3.买
|说明:技术派沿用session的方案，依然将iwt写入到cookie中
问题1
注意技术派里面的实现，即便jwt校验通过了，我们也依然从redis中去查了一下，判断是否有效
为什么这么设计呢?
● 因为jwt本身无状态，后端完全可以将redis这一层的存储都直接干掉，纯依赖jwt的特性来完成身份鉴权，但是由于它的无状态，后端减少存储压力是一个好处，同样也是一个弊端，后端失去了token的管控权限，如果我们希望提前失效某些用户身份，则无法支持
● 鉴于此，我们依然保留了redis中存储iwt的方案(这是主要原因，当然技术派作为一个让大家获取更多的知识点教学相长的项目，我们会尽可能的将相关知识点给引入进来，且尽量满足大厂项目规范来实现)
问题2
如何防范csrf攻击
使用jwt预防csrf攻击的主要原理就是jt是通过请求头，由is主动塞进去传递给后端的，而非cookie的方式，从而避免csrf漏洞攻击。
但是技术派的jwt也是用cookie进行携带jwt，并不能解决上面这个问题:同样的，session的方案，也可以将sessionld通过请求头的方式传递，按照这个说法也能避免csrf啊
当然上面这么说，完全没有问题，我们就一项技术本身而言，通常是基于其"官配”方案来讨论其优缺点，即以上的对比，基于下面的搭配来进行的
session-cookie 方案
jwt-requestHeader方案
补充：
● 使用Cookie来携带JWT令牌确实不能完全解决CSRF（Cross-Site Request Forgery，跨站请求伪造）攻击。尽管JWT通过Cookie传输可以提供一定程度的安全性，但它并不能防止CSRF攻击的发生。
● CSRF攻击利用了用户的已认证会话，在用户不知情的情况下，向目标网站发送未经授权的请求。即使JWT被存储在Cookie中，攻击者仍然可以通过构造恶意页面或者其他方式来触发用户在目标网站上的请求，从而利用用户的身份进行操作。
● 为了防止CSRF攻击，通常需要采取额外的措施，比如在请求中添加CSRF令牌（也称为同步令牌或者表单令牌），这样服务器可以验证请求是否来自合法的源。另外，确保敏感操作需要额外的确认步骤，比如输入密码或者进行双因素认证，也是防范CSRF攻击的有效方法。
总之，虽然使用Cookie传输JWT可以提高安全性，但要完全防止CSRF攻击，还需要结合其他安全措施。