网页游戏， websocket 通信，一般怎么处理用户认证？

資深大佬 : dzmcs 11

使用 websocket 和 protobuf 做通信，用户身份标识一般用 session 还是 jwt ？或者别的什么方式呢

大佬有話說 (23)

資深大佬 : netnr

我觉得优先考虑无状态的方式，自由好扩展
資深大佬 : KuroNekoFan

可以结合起来用啊
資深大佬 : RedBeanIce

不知道主有没有写过 websocket 通信，，如果是前端 H5 websocket，后端 netty，在后端接收的时候，其实也是有一个 channel 的接收的，可以在那里认证。
資深大佬 : sunny352787

都不用，按 tcp 方式验证，建立连接之后先发个认证消息到服务器
資深大佬 : Mutoo

websocket 建立连接后的第一个 protobuf 协议，由 client 发送认证信息（可以是 jwt，可靠性比较高，无状态易扩展），服务端验证有效后保持通讯。无效的话直接断开通讯。后续的通信就不需要再验证了。
資深大佬 : Mutoo

接上，获取 jwt 的方式可以用一般的 oauth 协议。负责登陆的服务器可以跟游戏后端分离（ jwt 的另一个好处）
資深大佬 : aaronlam

@Mutoo 请教一下，那像 jwt 的失效处理，你们一般是怎么处理的呢？是后端有有个 Redis 专门存用户的 jwt 吗？
資深大佬 : aaronlam

@aaronlam 补充一下，准确的说就是，比如：用户修改了密码，我想让他先前所登录生成的 jwt 失效，让其重新登录的这种情况。
資深大佬 : lqw3030

在 websocket 协议升级前的 http 上做
資深大佬 : Leigg

当然不能用 jwt 了，因为你很可能需要实时控制用户的会话生命周期，比如踢下线。
資深大佬 : Yoock

1. 傻一点的办法: 每个包都带验证信息
2. 在每一个 connect 里保存验证信息，有用户登录广播，然后踢掉旧的 connect
資深大佬 : abersheeran

浏览器的 websocket 接口，不能自定义 header，只能通过带 cookie 的方式认证。或者你把认证做进 websocket 交互里，不过更推荐用 cookie 。
資深大佬 : Austaras

讲个邪道：其实 websocket 可以自定义 header，只不过只能自定义 protocol，就用那个当作鉴权
資深大佬 : emeab

@Mutoo 用 jwt 就无法踢下线了。
資深大佬 : v25217

@emeab 可以踢呀，服务器直接断开 websocket 链接就行
資深大佬 : Mutoo

@aaronlam 失效处理有很多种方式，因为登陆验证只需要在第一个协议处理，可以设置很短的 expired 让 jwt 失效，没有保存的意义。之后 websocket 连接本身是有状态的。

踢下线直接断开 websoket 即可，下次登录需要重新验证。

至于修改密码的问题，按标准的 OAuth 的流程来处理就好了。
資深大佬 : Mutoo

接上，登陆验证用的其实就是一个生命周期很短的 access token 。而存在本地的是 refresh token，用于获取新的 access token，有效期相对长一些。

refresh token 可以记录用户上次改密码的时间，用户修改密码的话，下次获取 access token 的时候比较最新修改修改密码时间，如果失效就直接拒绝，让重新登陆获取新的 refresh token 即可。
資深大佬 : qwerthhusn

Upgrade 前做
主資深大佬 : dzmcs

@qwerthhusn 感谢，明白了
資深大佬 : joesonw

Upgrade 的时候可以拿到请求头, query 等这些, 和 http 一样处理呗.
資深大佬 : aaronlam

@Mutoo

喔，有点恍然大悟的感觉，感谢！
以往我以为都是只生成一个 token 。如果是按照你的说法有 access 和 refresh 两个 token，再进行配置短命的 access token，配置 refresh token 里的最新修改密码时间的确可以办到踢下线，不过感觉这样好像没办法做到立即踢下线的效果。。
資深大佬 : Mutoo

@aaronlam 玩家修改密码的时候，给后端一个消息。后端收到消息查看是一玩家是否有连接，有的话发个下线协议，然后主动断开 socket 即可。完全后端可控，不需要前端参与。前端下线后原有的 refresh token 根据上述业务逻辑就自动失效了，需要重新登录。
資深大佬 : aaronlam

@Mutoo 再次感谢！