这是一个创建于 215 天前的主题，其中的信息可能已经有所发展或是发生改变。
起因是今天一个群里有兄弟问修改密码后 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 前端的区别一样，我一直以为这些似乎是常识，但是突然好像发现并不是
我质疑了这小伙几句，这小伙子居然嘲讽起我，让我不会走就别学跑，想想自己是不是天才，给我气麻了。
然后我也懒得打嘴炮，决定自己求证一下，然后搜到的内容就更让我焦麻了，因为我理解的 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 前端的区别一样，我一直以为这些似乎是常识，但是突然好像发现并不是
 |
101
encro 214 天前
@dyllen
@zpf124 jwt 还带了一个 j ，就是 json ，通常都是可以设置过期时间和自动过期的。 传统的 php,java 等等 session id 都只是一个 key ，这个 key 通常通过 url 或则 cookie 的一个特殊标志传输，然后存储在文件系统/内存/redis/db 里面。 jwt 里面可以带一些信息，这些信息因为存在加密机制，服务端会对有效性进行验证，起到防止修改作用（不需要通过服务器存储 key 以及 data!）。 所以，结论是：相比传统的通过 url,head 传输的 session id ，jwt 提供了一个统一的、方便的、适用多端方案，且不需要服务器存储 key 以及 data ，无需存储即意味几乎无成本分布式（除了 cpu 加解密运算和传输头信息）。 |
 |
102
zpf124 214 天前
@encro
我也和你说了， 许多人用 jwt 不是要解析校验里面的信息，他们也不会把 jwt 校验通过当作登录成功的判断标准，仅仅是拿 jwt 格式的 token 当 key 去 redis/mysql 里查相关信息，自己实现了一遍 session 管理。 楼主提到的内容也是 jwt 无法失效、也不应该用 jwt 做撤销功能而被而被二把刀嘲讽。 如果要实现撤销功能，那就是中心化的，就需要有会话管理查询的地方，那就是自己重新套着 jwt 的皮实现了一遍 session 管理。 那么就不可能 “不需要服务器存储 key 以及 data ，无需存储即意味几乎无成本分布式（除了 cpu 加解密运算和传输头信息） ” |
 |
103
also24 214 天前
|
|
104
encro 214 天前
@zpf124
这种东西，说白了懂的自然懂，研究几个框架，看了各自代码实现之后，自然知道用谁合适了，我用很多框架（超过 5 个）都只需要 1-20 行代码左右就能增加一种流行的认证方式。 对于 SPA/小程序/APP ，我当然选择 jwt/token 模式，传统 mvc 我就用 session 。因为都是框架原生带的啊。 支持另外一种也就增加几行配置的事情。 现在 jwt 流行就是因为大家写 SPA/APP 多，框架都集成了 jwt 方案，不用自己考虑怎么生成 token ，大家都是因为方便，对于习惯用框架的人来说，手写 token 认证就是 LOW 。。。强行在 app 使用 Session 也是 LOW 爆了。。。什么适合就用什么。 总结就是： 传统 mvc：用 session 多端 app: 用 jwt 或者自定义一种 token 服务端通信：token |
 |
105
ShuWei 213 天前
@Curtion 你这说法吧，反正我是不太喜欢，说不上对或者错，只是我觉得如果对 token 撤销非常敏感的话，其实建议不要使用 jwt ，jwt 本身就是为了让服务端不需要维护状态而设计的，根据实际情况，可以采取比如缩短有效期、自动刷新之类的方式来缓解撤销问题，但是如果对撤销非常敏感，没必要 jwt ，自己随便生成一个 token 下发就好了，可能性能还更好，逻辑也更简单，毕竟 jwt token 长度还不短
|
 |
106
di94sh 213 天前
|
 |
108
MrSheng 213 天前  1
@hongfs #96
如果必须要实现退出功能，那肯定需要在服务端存储相关数据，这种有状态服务的需求选择硬上 JWT 不合理，客户端会疑惑明明 token 显示有效却无法使用。如果非得想用 JWT ，那么应该设置合理的过期时间，然后定时使用 refresh_token 签发新的 JWT 。 实现简单永远不应该成为烂设计的借口。 |
|
109
MrSheng 213 天前
@tomwu618 #100
“jwt 同时满足 token 和认证信息的表示，形象来说一路请求传递多种信息，session 却只能起到 token 的作用” 这种理解不对，“session 却只能起到 token 的作用” 是因为信息都在服务器存着呢，不需要客户端传过来，自然也就不需要认证。 |
 |
111
nobject 210 天前
最近在看 open connect 的规范，如果用户登录，他最终生成 id_token,access_token 与 refresh_token ，而且 token 也是用 jwt ，在我看来，只需要 id_token 到传到后端，jwt 解出用户 id 即可
但像 open connect 的规范这样通过的协议，也会有各种补充的规范用于 session 的管理，作单点登录或登出的，所以有些不是没明白 jwt 的作用，而是单单 jwt 并不好实现这些，还需要中心化的存储去帮忙实现 |
 |
112
dyllen 196 天前
jwt 如何做登出功能？总得存储失效的 jwt 吧？用了存储又说失去了 jwt 的意义，不是 jwt 了，那怎么做 jwt 登出呢？
客户端销毁，服务端不做失效 jwt 验证？ |
|
113
zpf124 174 天前 1
@dyllen
这问题就像是问 “可乐如何才能让人醉酒呢，总得加酒精吧，加了酒精又说可乐失去了意义，不是可乐了，那可乐怎么才能让人喝醉？” 如果想要高酒精度，那为什么不去喝酒呢，非得往可乐瓶里灌。 当然觉得好不好和有没有人这样做没关系， 茅台咖啡不是还挺火么，但不影响不接受的人说他不能算咖啡。 |
 |
114
eastcukt 172 天前
看了讨论，学到很多了
|
Select Language