具体步骤如下:
- 客户端启动时,需要先连接自己的应用服务器验证身份。
- 客户端向应用服务器申请自己所需的所有 Topic 的权限。
- 应用服务器验证客户端是否有必要操作所需的 Topic 的权限,如果验证通过则向 MQ 认证服务器申请对应资源的 Token。
- MQ 认证服务器验证申请 Token 的请求,判断合法之后返回对应的 Token。
- MQTT 客户端将应用服务器返回的 Token 持久化到本地,对每个客户端需要的权限以及 Token 信息做一个映射。
- 客户端重新启动进行访问时,应用服务器可以返回缓存的 Token,避免重复申请;
- 客户端重新申请 Token,认证服务器如果无响应,应用服务器可以尝试返回客户端之前申请的 Token。
MQTT 客户端连接 MQTT 消息服务器。
客户端在收发消息之前必须通过 QoS1 方式上传自己的 Token。上传 Token 通过发送一条特殊的消息来实现,具体消息格式参考下文。
客户端正常收发消息。如果服务端判断 Token 失效,即会触发鉴权失败,客户端应该重新发起申请 Token 的请求。
在 Token 失效前 5 分钟,服务端也会推送一次即将失效的通知,客户端可以监听该消息以便提前更换 Token。
客户端行为约束
- 发送 Pub/Sub 报文前,必须先采用 MQTT 控制报文来上传 Token。
- 必须以同步发送模式上传 Token,且消息 QoS 必须设置为 1,以保证服务端未返回之前不会收发消息,否则会报错甚至断开链接。
- 必须监听 Proxy 可能下推的 Token 失效的通知消息。
- 收到 Token 失效的消息后,客户端必须重新申请 Token。
- 客户端应该对应用服务器返回的 Token 做持久化,避免每次重连都申请一样的 Token。
- 客户端发现连接被断开时应该先判断自己的 Token 是否失效,如果失效需要先重新申请 Token 再重连。判断标准可以参考服务端下推的消息,以及 Token 的有效周期。
应用服务器行为约束
- 应用服务器必须验证自己的客户端是否合法,避免客户端冒用身份申请 Token。
- 应用服务器应该对 Token 和客户端的关系进行管理,避免同一个客户端重复调用。
- 应用服务器需要做本地容灾,避免因访问认证服务器短暂不可用导致的业务阻塞。
相关 API
MQTT 的 Token 鉴权流程通过相关的 API 来完成。
Token 的申请和吊销管理交由应用服务器负责,和 MQ 认证服务器之间通过 HTTPS 的 Open API 进行交互。每个接口都要求通过 AccessKey 和请求签名做来做身份验证。目前开放申请 Token、吊销 Token 以及校验 Token 接口。
MQTT 客户端则包括上传 Token、监听 Token 失效信息,以及监听 Token 非法信息三个接口。