本文主要介绍云消息队列 MQTT 版客户端鉴权的原理和分类，以便您使用相应的鉴权功能。
鉴权原理
使用云消息队列 MQTT 版的客户端收发消息时，服务端会根据MQTT客户端设置的UserName和Password参数来进行鉴权。针对不同的权限验证场景，UserName和Password参数具备不同的含义。MQTT客户端开发应该根据实际场景选择合适的鉴权模式，按照对应的规范计算正确的UserName和Password。
各鉴权模式下UserName和Password的计算方法和应用场景如下表所示。
权限验证模式 | 模式名称 | UserName | Password | 适用场景 |
签名验证 | Signature | 由鉴权模式名称、AccessKey ID、Instance ID三部分组成，以竖线（|）分隔。 举例：一个客户端的ClientId是GID_Test@@@0001，使用了实例ID是mqtt-xxxxx，使用了AccessKey ID是YYYYY，则签名模式的UserName应该设置成“Signature|YYYYY|mqtt-xxxxx”。 | 以AccessKey Secret为密钥，对Client ID签名的Base64编码结果，具体设置方法，请参见签名鉴权模式。 | 永久授权，适用于客户端安全受信任的场景。 |
临时Token权限验证 | Token | 上传的Token内容，具体设置方法，请参见Token鉴权概述。 | 临时授权，适用于客户端不安全的场景。 | |
一机一密验证 | DeviceCredential | 由鉴权模式名称、DeviceAccessKeyId、Instance ID三部分组成，以竖线（|）分隔。 举例：一个客户端的ClientId是GID_Test@@@0001，使用了实例ID是mqtt-xxxxx，DeviceAccessKeyId是YYYYY，则一机一密模式的UserName应该设置成“DeviceCredential|YYYYY|mqtt-xxxxx”。 DeviceAccessKeyId为MQTT服务端为设备颁发的访问凭证中的参数，详细信息，请参见一机一密概述。 | 以DeviceAccessKey Secret为密钥，对Client ID签名的Base64编码结果，具体设置方法，请参见一机一密概述。 | 永久授权，适用于客户端安全受信的场景，并且服务端可以随时更新或禁用已发放的设备访问凭证。 |
AccessKey ID和AccessKey Secret为敏感信息，且和客户端的UserName和Password计算结果强相关。为了避免客户端信息泄露，请勿将AccessKey ID和AccessKey Secret信息直接写入客户端代码中，建议将该信息写入到后端应用中，由后端应用计算UserName和Password后下发给客户端。
鉴权模式分类和比较
按照上文分类，云消息队列 MQTT 版目前支持了签名校验、Token校验及一机一密校验三种验证方式，这三种方式覆盖了固定权限以及非固定的临时权限的场景，具体细分和适用场景分析如下所述：
签名模式（固定权限）
签名模式是云消息队列 MQTT 版推荐使用的默认鉴权模式，该模式下约定同一类型的MQTT客户端拥有同样的权限范围，这些客户端使用相同的账号来做签名计算，服务端通过签名比对即可识别出客户端对应的账号以及拥有的权限范围。该模式理解成本低，使用简单。
适用场景
使用的MQTT客户端逻辑上可以划分为同一类，逻辑意义上都属于一个账号，具备同样的权限范围，且每个MQTT客户端运行的环境相对可控，不需要考虑设备被破解盗用等恶意攻击的场景。
因为在业务层面上，对一类的MQTT客户端都划分到一个账号（可以是主账号或者子账号），所以客户端只需要根据对应的账号AccessKey Secret计算签名即可，权限范围由账号的管理员在产品的控制台进行统一管理。
签名计算
为防止签名被盗用，需要取每个客户端独立的信息进行签名计算，云消息队列 MQTT 版约定每个客户端使用自己独一无二的ClientId来作为待签名内容。关于该类型签名的具体计算方法，请参见签名鉴权模式。
Token模式（临时权限）
如果业务上需要对每个MQTT客户端的权限进行细致划分，或者仅需要对客户端授予临时的有时间期限的权限，则可以通过Token模式这种临时凭证访问方式实现。通过Token服务，您可以设置单一客户端访问的资源内容、权限级别和权限过期时间。
关于Token鉴权的流程和注意事项，请参见Token鉴权概述。
适用场景
业务方拥有自己独立的本地账号系统，需要对阿里云账号的身份做二次拆分，甚至需要对每个MQTT客户端分配独立的个体账号和权限范围。在这种情况下MQTT客户端的细分使用阿里云的RAM账号系统无法满足。
因为运行的MQTT客户端的业务虽然隶属于同一个阿里云账号，但是还需要有本地账号（业务部门或者单一客户端）的角色区分。此时签名模式下划定的阿里云账号维度就无法满足。特别是在移动端场景，客户端如果需要考虑破解劫持的风险，固定的权限模式管理相对比较受限，如果权限控制需要细化到单一客户端，且权限粒度需要细化到单一资源，所有的权限都是临时的非固定的，则更加灵活。
Token使用
使用Token模式相对比较复杂，按照上文描述，需要业务方自己拥有账号（设备）管理能力，业务方需要自己管理每个设备的权限范围和时效性，由业务方在安全可控的管理节点来申请Token并发放给MQTT客户端使用。具体的使用方法，请参见Token鉴权概述。
一机一密模式
一机一密给予MQTT客户端能够以独立的用户名、密码来进行身份识别的能力，帮助您解决客户端在不安全场景下，存在Token冒认的问题。且在一机一密模式下，用户名、密码与ClientId绑定，您可独立管理。
适用场景
业务方对安全性要求较高，且类似于IoT这种不便实时更新Token的场景，一机一密能够提供持久化验证能力，不需要频繁的被动更新访问凭证。
设备访问凭证使用
一机一密模式下，客户端应用服务器为每个客户端申请独一无二的设备访问凭证，客户端向云消息队列 MQTT 版发起认证请求时，按照约定的规范对访问凭证中的信息进行计算并作为连接参数，具体的计算方法，请参见一机一密概述。