本文主要介绍云消息队列 MQTT 版客户端鉴权的原理和分类，以便您使用相应的鉴权功能。
鉴权原理
使用云消息队列 MQTT 版的客户端收发消息时，服务端会根据MQTT客户端设置的UserName和Password参数来进行鉴权。针对不同的权限验证场景，UserName和Password参数具备不同的含义。MQTT客户端开发应该根据实际场景选择合适的鉴权模式，按照对应的规范计算正确的UserName和Password。
- 鉴权模式
模式名称 模式说明 适用场景 Signature 签名验证 永久授权，适用于客户端安全受信任的场景 Token 临时Token权限验证 临时授权，适用于客户端不安全的场景 - UserName
由鉴权模式名称、AccessKey ID、InstanceId三部分组成，以竖线（|）分隔。
举例：一个客户端的ClientId是GID_Test@@@0001，使用了实例ID是mqtt-xxxxx，使用了AccessKey ID是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客户端都划分到一个账号（可以是阿里云账号或者RAM用户），所以客户端只需要根据对应的账号AccessKey Secret计算签名即可，权限范围由账号的管理员在产品的控制台进行统一管理。
- 签名计算
为防止签名被盗用，需要取每个客户端独立的信息进行签名计算，云消息队列 MQTT 版约定每个客户端使用自己独一无二的ClientId来作为待签名内容。关于该类型签名的具体计算方法，请参见签名鉴权模式。
- 适用场景
- Token模式（临时权限）
如果业务上需要对每个MQTT客户端的权限进行细致划分，或者仅需要对客户端授予临时的有时间期限的权限，则可以通过Token模式这种临时凭证访问方式实现。通过Token服务，您可以设置单一客户端访问的资源内容、权限级别和权限过期时间。
关于Token鉴权的流程和注意事项，请参见Token鉴权概述。
- 适用场景
业务方拥有自己独立的本地账号系统，需要对阿里云账号的身份做二次拆分，甚至需要对每个MQTT客户端分配独立的个体账号和权限范围。在这种情况下MQTT客户端的细分使用阿里云的RAM用户系统无法满足。
因为运行的MQTT客户端的业务虽然隶属于同一个阿里云账号，但是还需要有本地账号（业务部门或者单一客户端）的角色区分。此时签名模式下划定的阿里云账号维度就无法满足。特别是在移动端场景，客户端如果需要考虑破解劫持的风险，固定的权限模式管理相对比较受限，如果权限控制需要细化到单一客户端，且权限粒度需要细化到单一资源，所有的权限都是临时的非固定的，则更加灵活。
- Token使用
使用Token模式相对比较复杂，按照上文描述，需要业务方自己拥有账号（设备）管理能力，业务方需要自己管理每个设备的权限范围和时效性，由业务方在安全可控的管理节点来申请token并发放给MQTT客户端使用。具体的使用方法参考Token服务章节的文档。
- 适用场景