朋友圈看到一篇文章: 不要用 JWT 替代 session 管理(上):全面了解 Token,JWT,OAuth,SAML,SSO
个人觉得作者没有搞清楚 jwt 与 session 的关系(或者实践经验不足)。jwt 与 session 的关系好比 session 与 cookie 的关系,大家可以搜索一下。
作为一个前端开发工程师怎么搞不懂 jwt 和 session 的关系?我倒觉得你没搞清。作者说的没错,如果事先保存好合法的 jwt,那么 OAuth 验证是完全没有问题的。但多数情况下,合法的 jwt 还是需要登录之后获得。
理论上来说,JWT 机制可以取代 session 机制。用户不需要提前进行登陆,后端也不需要 Redis 记录用户的登陆信息。客户端的本地保存一份合法的 JWT, 当用户需要调用接口时,附带上该合法的 JWT,每一次调用接口,后端都使用请求中附带的 JWT 做一次合法性的验证。这样也间接达到了认证用户的目的
文章作者说的很清楚嘛
jwt 本质上与 cookie 没有本质上的不同:jwt、cookie 都是在客户端保存数据,session 是在服务器端保存的数据。
1、jwt、cookie 保存的数据是否安全取决于使用者。 2、作者那 google API 的调用来举例有失偏颇,网站认证与授权使用 jwt 本身也会用到 session。
后端进行 jwt 合法性验证过程中本身也可能用到 session,无所谓 jwt 替换 session 的问题。
这个有点挑骨头了吧,而且作者明显还有下篇啊。 没必要这么评价别人的文章吧
还是有点鸡蛋挑骨头的意思。调用 API Bearer Token 就 ok 啊。网页 + 服务端当然不能只 jwt,这里你忽略了用户直接调用 Open API 的部分,当然可能还有其他访问令牌。jwt 与 cookie 还是有本质差别的,jwt 可以存在 local storage 和 cookie 中,cookie 反过来可以?但两者都有问题,cookie-session 可能存在 csrf。jwt 可能存在 xss。我没觉得作者写的有啥大问题。讲的也基本正确。单从 sso 角度来考虑,返回可能是 jwt 可能是令牌,但是后续的操作还是需要 cookie-session 认真。单从 api 角度考虑,md5 签名访问,form-urlencoded,OAutho 2.0,bearer token 都可以。STF 的 rest API 使用的是 jwt,我司 form-urlencoded 的 md5 签名及其他。
cookie 存储在本地存储是很常见的,许多移动 app 的 cookie 是存在 sqlite 数据库里面的。