一开始用的第一种方式，我们19年就出现过这种问题，IMServer收到客户端的token需要去主站业务服务再登录验证下token，有段时间对主站压力很大（频繁且集中登录）

引用：一夕 发表于 2019-03-13 16:52
版主采用jwt来解决长链接重新建立时，频繁和sso通讯验证身份问题。我怎么感觉归根结底时原来的token，信息 ...

是IMServer本身没有这些用户验证信息，必须去SSO做验证，导致IMServer和SSO之间多了一步交互，在可能会频繁出问题的弱网情况下，这一步就会造成很多问题了。还一种思路是可以考虑把token相关的数据外置化到Redis等外部存储中，这样IMServer就可以直接请求Redis来验证了

不错

引用：danielstock 发表于 2020-05-26 12:30
@JackJiang thanks.

不客气

@JackJiang thanks.

引用：danielstock 发表于 2020-05-26 00:08
@JackJiang

如果网络不好，频繁断开，是不是在重新建立长连接的时候，就使用前面得到的jwt token，请求i ...

是的

@JackJiang

如果网络不好，频繁断开，是不是在重新建立长连接的时候，就使用前面得到的jwt token，请求im server验证（仅验证签名合法性就好了），不必再发送请求到sso了。

是这个意思吗. 谢谢了。

引用：sunnyzeng 发表于 2020-03-12 11:39
都是干货，实战中得出的经验最宝贵了，感谢作者。

说的对

都是干货，实战中得出的经验最宝贵了，感谢作者。

引用：elan 发表于 2019-11-26 19:47
@JackJiang
站长，请教一下，为啥大家都喜欢在token前面加上Bearer ？  啥缘由？

找到原因了，oauth规范里jwt的部分规定就是这样
https://jwt.io/introduction/

@JackJiang
站长，请教一下，为啥大家都喜欢在token前面加上Bearer ？  啥缘由？

引用：一夕 发表于 2019-03-13 16:52
版主采用jwt来解决长链接重新建立时，频繁和sso通讯验证身份问题。我怎么感觉归根结底时原来的token，信息 ...

JWT可以验证，只是理论上没那种高安全而已

版主采用jwt来解决长链接重新建立时，频繁和sso通讯验证身份问题。我怎么感觉归根结底时原来的token，信息负载太少，没办法使IMService验证client身份合法。

学习一下

很实用，学习了，值得一试