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

我觉得优先考虑无状态的方式，自由好扩展

可以结合起来用啊

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

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

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

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

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

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

在 websocket 协议升级前的 http 上做

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

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

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

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

@Mutoo 用 jwt 就无法踢下线了。

@emeab 可以踢呀，服务器直接断开 websocket 链接就行

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

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

至于修改密码的问题，按标准的 OAuth 的流程来处理就好了。

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

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

Upgrade 前做

@qwerthhusn 感谢，明白了

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

@Mutoo

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

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

@Mutoo 再次感谢！