发现很多人分不清 jwt 和类 session token 的区别？

起因是今天一个群里有兄弟问修改密码后 jwt 怎么失效过期问题，然后一个小伙子说现在所有的接口开发都是使用 jwt ，我一瞬间都有些怀疑是不是自己记忆错乱了，因为我自己向来是非必要不使用 jwt 的，主要是这玩意签发后不可控，而且我抓包过一些大厂的应用，基本没见过头部厂商使用 jwt 做客户端和服务端 API 认证的，服务端与服务端之间有一些，比如 OIDC 里的 jwt ，然后小厂商应用还是有不少用 jwt 的，但明显达不到全使用 jwt 这种说法，半壁江山都很难说。

我质疑了这小伙几句，这小伙子居然嘲讽起我，让我不会走就别学跑，想想自己是不是天才，给我气麻了。

然后我也懒得打嘴炮，决定自己求证一下，然后搜到的内容就更让我焦麻了，因为我理解的 token 是这样的有两种
1 、Json web token (jwt)
2 、类 SESSION 模型 Token (没有统一叫法，原理为自定义生成 token ，token 对应信息在服务端储存，一般 redis 中，原理基本与 SESSION 相同，只不过 session_id 变成了 token ，且不再由后端写入到 cookie 中)

这两种 token 模式对客户端来说都区别不大，唯一的区别是 jwt 可以解读信息，2 不可由客户端解读。

然后我搜到的帖子和讨论给我惊呆了，很多程序员分不清这两种 token 的区别，包括很多后端，令我错愕的好几点:
1 、很多人固执的认为，session 是网页时代的东西了，现在的 spa 页面和 APP 都只能使用 jwt
2 、分不清 token 本身有好几种实现模式。
3 、有的前端虽然在使用 jwt ，但他们不知道 jwt 本身载了内容，也不会去解析，因为后端直接给他们一次签发几个月有效期的。

这种感觉就像我之前发现很多人分不清前端和 web 前端的区别一样，我一直以为这些似乎是常识，但是突然好像发现并不是

tywtyw2002

215 天前

JWT 不是一种 Token 的 format 吗？ RFC 在这里 https://datatracker.ietf.org/doc/html/rfc7519

JWT 的 rfc 只是说了这种 token 的格式和验证算法。

对于 token 是不是 revoke 这个不再 jwt 的设计范围内。

就像 Cloudflare access 用 JWT 格式做鉴权，里面也有各种验证的字段，比如 app_session_hash 等等东西。
https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/application-token/

比较常用的是，后端可以对于重要的 API 根据 session 做二次验证啊。不重要的，直接验证 JWT 是不是有效就好了。

skarner

215 天前

1 、Json web token (jwt)
2 、类 SESSION 模型 Token (没有统一叫法，原理为自定义生成 token ，token 对应信息在服务端储存，一般 redis 中，原理基本与 SESSION 相同，只不过 session_id 变成了 token ，且不再由后端写入到 cookie 中)

=======================================================
1 和 2 总体来说是一回事，1 只是 2 的一种特殊情况。
这 1 和 2 中所谓的 token ，不过是用自己的方式去实现了一遍 session ，不同的是 1 对格式有规范，2 自由度更大

strawberrydafu

215 天前

OIDC 标准里其实说了 token （ jwt ）的 revoke

```
16.18. Lifetimes of Access Tokens and Refresh Tokens
Access Tokens might not be revocable by the Authorization Server. Access Token lifetimes SHOULD therefore be kept to single use or very short lifetimes.

If ongoing access to the UserInfo Endpoint or other Protected Resources is required, a Refresh Token can be used. The Client can then exchange the Refresh Token at the Token Endpoint for a fresh short-lived Access Token that can be used to access the resource.

The Authorization Server SHOULD clearly identify long-term grants to the User during Authorization. The Authorization Server SHOULD provide a mechanism for the End-User to revoke Access Tokens and Refresh Tokens granted to a Client.
```

可能只是很多实现没有做