通用的JWT鉴权方案

JWT鉴权流程

基本流程分三步:
● 用户登录成功之后，后端将生成的jwt返回给前端，然后前端将其保存在本地缓存;
● 之后前端与后端的交互时，都将iwt放在请求头中，比如可以将其放在Http的身份认证的请求头 Authorization ，也可以通过自定义的请求头来传递
● 后端接收到用户的请求，从请求头中获取iwt，然后进行校验，通过之后，才响应相关的接口:否则表示未登3.买

|说明:技术派沿用session的方案，依然将iwt写入到cookie中

问题1
注意技术派里面的实现，即便jwt校验通过了，我们也依然从redis中去查了一下，判断是否有效
为什么这么设计呢” /> session-cookie 方案
jwt-requestHeader方案

补充：

● 使用Cookie来携带JWT令牌确实不能完全解决CSRF（Cross-Site Request Forgery，跨站请求伪造）攻击。尽管JWT通过Cookie传输可以提供一定程度的安全性，但它并不能防止CSRF攻击的发生。
● CSRF攻击利用了用户的已认证会话，在用户不知情的情况下，向目标网站发送未经授权的请求。即使JWT被存储在Cookie中，攻击者仍然可以通过构造恶意页面或者其他方式来触发用户在目标网站上的请求，从而利用用户的身份进行操作。
● 为了防止CSRF攻击，通常需要采取额外的措施，比如在请求中添加CSRF令牌（也称为同步令牌或者表单令牌），这样服务器可以验证请求是否来自合法的源。另外，确保敏感操作需要额外的确认步骤，比如输入密码或者进行双因素认证，也是防范CSRF攻击的有效方法。

总之，虽然使用Cookie传输JWT可以提高安全性，但要完全防止CSRF攻击，还需要结合其他安全措施。