微消息队列 MQTT 版通过 Token 鉴权模式向 MQTT 客户端提供临时访问权限。您可通过 MQTT Token 服务来给本地账号系统管理的用户颁发临时的访问凭证,并限制访问权限,以实现对单一客户端、单一资源的细粒度权限控制。本文介绍使用流程以及相关注意事项。

名词解释

术语 说明
Token(临时凭证) 微消息队列 MQTT 版颁发的临时访问凭证,代表单一客户端对特定资源的访问权限。
应用服务器 您管理本地账号的服务器,用来替客户端申请和管理 Token 服务的应用。
MQTT 服务器 微消息队列 MQTT 版权限认证和消息收发服务器,用来处理应用服务器发起的 Token 相关的请求以及消息收发业务。

使用流程

Token 鉴权模式相比签名模式更加复杂,您需要按照下图所示的流程,部署您的应用服务器。而且在初始化时,MQTT 客户端需要具备与您的应用服务器交互(获取和更新 Token)的能力。
图 1. 鉴权流程
token_process_new

具体流程如下:

  1. 客户端启动时,需要先连接应用服务器验证身份。
  2. 客户端向应用服务器申请所需的所有 Topic 的权限。
  3. 应用服务器验证客户端是否有必要操作所需的 Topic 权限,如果验证通过则向微消息队列 MQTT 版服务器申请对应资源的 Token。
  4. 微消息队列 MQTT 版服务器验证申请 Token 的请求,判断合法之后返回对应的 Token。
  5. 应用服务器将返回的 Token 持久化到本地,对每个客户端需要的权限以及 Token 信息进行映射。缓存 Token 有以下优势:
    • 客户端重新启动后再访问时,只要权限范围没有变化,应用服务器可以返回缓存的 Token,避免重复申请。
    • 客户端重新申请 Token 时,如果 MQTT 服务器异常,应用服务器可以尝试返回客户端之前申请的 Token 以实现本地容灾。
  6. MQTT 客户端按照规范将 Token 作为参数设置,连接 MQTT 服务器,服务端验证通过后客户端即可正常收发消息。
  7. 客户端正常收发消息。如果服务端判断 Token 失效,即会触发鉴权失败,断开连接,客户端应该重新发起申请 Token 的请求。

客户端行为约束

  • 客户端从应用服务器拿到的信息除了 Token 本身,还需要获取 Token 的失效时间,以便本地计算何时提前刷新 Token。
  • 必须按照约定形式将 Token 作为连接参数设置到 Password 中,每次连接时上传。
  • 客户端应该知晓自己使用的 Token 的时效性,确保不要使用过期的 Token,否则服务端会断开连接。
  • 客户端可以监听服务端下推的 Token 失效的通知消息,但服务端不保证通知一定触发,该通知仅供排查问题使用。
  • 客户端应该对应用服务器返回的 Token 做持久化,避免每次重连都申请一样的 Token,防止大批量客户端同时连接压垮应用服务器。
  • 客户端更新 Token 可以选择关闭旧的客户端连接,然后重新使用新的 Token 来连接,也可以选择使用 MQTT 提供的系统 Topic 动态上传更新 Token。如果选择动态更新 Token,需要保证本地的配置也同步更新,以供下次连接初始化使用。

应用服务器行为约束

  • 应用服务器必须验证自己的客户端是否合法,避免客户端冒用身份申请 Token。
  • 应用服务器应该对 Token 和客户端的关系、已分配的 Token、对应权限内容以及生效时间进行管理,避免同一个客户端重复调用。
  • 应用服务器将 Token 返回给客户端的同时,也应该告知客户端当前 Token 的操作权限以及过期时间,以便客户端提前刷新 Token。
  • 应用服务器需要做本地容灾,避免因 MQTT 服务器访问短暂不可用而导致业务阻塞的情况。

相关 API

Token 鉴权流程通过相关的 API 来完成。

  • 应用服务器负责 Token 的申请和吊销管理,和微消息队列 MQTT 版服务器之间通过 HTTPS 的 OpenAPI 进行交互。

    每个接口都要求通过 AccessKey 和请求签名做来做身份验证。目前开放申请 Token、吊销 Token 以及校验 Token 接口。详情请参见 Token 应用服务器接口

  • 微消息队列 MQTT 版客户端则包括动态更新 Token、监听 Token 失效信息,以及监听 Token 非法信息三个接口。详情请参见 Token 客户端接口