cookie 存储在本地存储是很常见的，许多移动 app 的 cookie 是存在 sqlite 数据库里面的。

还是有点鸡蛋挑骨头的意思。调用 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 签名及其他。

这个有点挑骨头了吧，而且作者明显还有下篇啊。
没必要这么评价别人的文章吧

后端进行 jwt 合法性验证过程中本身也可能用到 session，无所谓 jwt 替换 session 的问题。

jwt 本质上与 cookie 没有本质上的不同：jwt、cookie 都是在客户端保存数据，session 是在服务器端保存的数据。

1、jwt、cookie 保存的数据是否安全取决于使用者。
2、作者那 google API 的调用来举例有失偏颇，网站认证与授权使用 jwt 本身也会用到 session。

理论上来说，JWT 机制可以取代 session 机制。用户不需要提前进行登陆，后端也不需要 Redis 记录用户的登陆信息。客户端的本地保存一份合法的 JWT, 当用户需要调用接口时，附带上该合法的 JWT，每一次调用接口，后端都使用请求中附带的 JWT 做一次合法性的验证。这样也间接达到了认证用户的目的

文章作者说的很清楚嘛

作为一个前端开发工程师怎么搞不懂 jwt 和 session 的关系？我倒觉得你没搞清。作者说的没错，如果事先保存好合法的 jwt，那么 OAuth 验证是完全没有问题的。但多数情况下，合法的 jwt 还是需要登录之后获得。