本文主要介绍微消息队列 MQTT 客户端鉴权的原理和分类,以便您使用相应的鉴权功能。

鉴权原理

使用微消息队列 MQTT 的客户端收发消息时,服务端会根据 MQTT 客户端设置的 Username 和 Password 参数来进行鉴权。针对不同的权限验证场景,UserName 和 Password 参数具备不同的含义。MQTT 客户端开发应该根据实际场景选择合适的鉴权模式,按照对应的规范计算正确的 UserName 和 Password。

鉴权模式

模式名称 模式说明 适用场景
Signature 签名验证 永久授权,适用于客户端安全受信任的场景
Token 临时 Token 权限验证 临时授权,适用于客户端不安全的场景

Username

由鉴权模式名称、AccessKeyId、InstanceId 三部分组成,以 “|” 分隔。

举例:一个客户端的 ClientId 是 GID_Test@@@0001,使用了实例 ID 是 mqtt-xxxxx,使用了 AccessKeyId 是 YYYYY,则签名模式的 UserName 应该设置成 “Signature|YYYYY|mqtt-xxxxx”,Token 模式的 UserName 应该设置为 “ Token|YYYYY|mqtt-xxxxx”。

Password

权限验证模式 Password 适用场景
签名验证 对 clientId 签名的 Base64 编码结果,具体设置方法参考签名计算文档 永久授权,适用于客户端安全受信任的场景
临时 Token 权限验证 上传的 Token 内容,具体设置方法参考 Token 计算文档 临时授权,适用于客户端不安全的场景

鉴权模式分类和比较

按照上文分类 ,微消息队列 MQTT 目前支持了签名校验以及 Token 校验两种验证方式,这两种方式分别对应了固定权限以及非固定的临时权限两种场景,具体细分和适用场景分析如下所述。

签名模式(固定权限)

签名模式是微消息队列 MQTT 推荐使用的默认鉴权模式,该模式下约定同一类型的 MQTT 客户端 拥有同样的权限范围,这些客户端使用相同的账号来做签名计算,服务端通过签名比对即可识别出客户端对应的账号以及拥有的权限范围。该模式理解成本低,使用简单。

  • 适用场景

    使用的 MQTT 客户端逻辑上可以划分为同一类,逻辑意义上都属于一个账号,具备同样的权限范围,且每个 MQTT 客户端运行的环境相对可控,不需要考虑设备被破解盗用等恶意攻击的场景。

    因为在业务层面上,对一类的 MQTT 客户端都划分到一个账号(可以是主账号或者子账号),所以客户端只需要根据对应的账号 AccessKeySecret 计算签名即可,权限范围由账号的管理员在产品的控制台进行统一管理。

  • 签名计算

    为防止签名被盗用,需要取每个客户端独立的信息进行签名计算,微消息队列 MQTT 约定每个客户端使用自己独一无二的 ClientId 来作为待签名内容。关于该类型签名的具体计算方法,请参见签名鉴权模式

Token 模式(临时权限)

如果业务上需要对每个 MQTT 客户端的权限进行细致划分,或者仅需要对客户端授予临时的有时间期限的权限,则可以通过 Token 模式这种临时凭证访问方式实现。通过 Token 服务,您可以设置单一客户端访问的资源内容、权限级别和权限过期时间。

关于 Token 鉴权的流程和注意事项,请参见Token 鉴权概述

  • 适用场景

    业务方拥有自己独立的的本地账号系统,需要对阿里云账号的身份做二次拆分,甚至需要对每个 MQTT 客户端分配独立的个体账号和权限范围。在这种情况下 MQTT 客户端的细分使用阿里云的子账号系统无法满足。

    因为运行的 MQTT 客户端的业务虽然隶属于同一个阿里云账号,但是还需要有本地账号(业务部门或者单一客户端)的角色区分。此时签名模式下划定的阿里云账号维度就无法满足。特别是在移动端场景,客户端如果需要考虑破解劫持的风险,固定的权限模式管理相对比较受限,如果权限控制需要细化到单一客户端,且权限粒度需要细化到单一资源,所有的权限都是临时的非固定的,则更加灵活。

  • Token 使用

    使用 Token 模式相对比较复杂,按照上文描述,需要业务方自己拥有账号(设备)管理能力,业务方需要自己管理每个设备的权限范围和时效性,由业务方在安全可控的管理节点来申请 token 并发放给 MQTT 客户端使用。具体的使用方法参考 Token 服务章节的文档。