This topic describes how the Message Queue for MQTT broker authenticates a Message Queue for MQTT client and compares different authentication modes.

How it works

When a Message Queue for MQTT client sends and receives messages, the Message Queue for MQTT broker authenticates the client based on the UserName and Password parameters. The UserName and Password parameters have different meanings in different authentication scenarios. You can choose a proper authentication mode based on the actual scenario when you develop a Message Queue for MQTT client. In addition, the UserName and Password parameters must be correctly set based on the corresponding rules.

The following table lists the calculation methods and application scenarios of the UserName and Password parameters in each authentication mode.

Authentication mode Mode name UserName Password Scenario
Signature authentication Signature

The UserName parameter consists of the authentication mode name, AccessKey ID, and instance ID, which are separated with vertical bars (|).

For example, if a Message Queue for MQTT client whose client ID is GID_Test@@@0001 uses the instance ID mqtt-xxxxx and the AccessKey ID YYYYY, set the UserName parameter for connecting this client to Signature|YYYYY|mqtt-xxxxx.

The client ID signature encoded in Base64. For more information about the setting method, see Signature authentication. Permanent authorization, which is applicable to secure and trusted clients.
Token-based authentication Token The content of the uploaded token. For more information about the setting method, see Overview of token-based authentication. Temporary authorization, which is applicable to untrusted clients.
Unique-certificate-per-device authentication DeviceCredential

The UserName parameter consists of the authentication mode name, DeviceAccessKeyId, and instance ID, which are separated with vertical bars (|).

For example, if a Message Queue for MQTT client whose client ID is GID_Test@@@0001 uses the instance ID mqtt-xxxxx and the DeviceAccessKeyId YYYYY, set the UserName parameter for connecting this client to DeviceCredential|YYYYY|mqtt-xxxxx.

The DeviceAccessKeyId is a parameter in the access credential issued by the Message Queue for MQTT broker for the device. For more information, see Overview of unique-certificate-per-device authentication.

The client ID signature encoded in Base64. For more information about the setting method, see Overview of unique-certificate-per-device authentication. Permanent authorization, which is applicable to secure and trusted clients and allows the broker to update or disable issued device access credentials at any time.

Types and comparison of authentication modes

Message Queue for MQTT supports signature authentication, token-based authentication, and unique-certificate-per-device authentication. These three authentication modes cover scenarios of fixed permissions and non-fixed temporary permissions. The following information describes the three modes and scenarios:

  • Signature authentication (fixed permissions)

    The signature authentication mode is the default authentication mode recommended by Message Queue for MQTT. In this mode, Message Queue for MQTT clients of the same type are granted the same permissions and calculate signatures by using the same account. The Message Queue for MQTT broker identifies the accounts and permissions of the Message Queue for MQTT clients by comparing the signatures. The signature authentication mode is easy to understand and use.

    • Scenarios

      The used Message Queue for MQTT clients can be logically classified into the same type, belong to the same account, and have the same permissions. The runtime environment of each Message Queue for MQTT client is relatively controllable. You do not need to worry about malicious attacks against devices, such as cracking and stealing.

      Message Queue for MQTT clients of the same type are managed by the same account, which can be an Alibaba Cloud account or a Resource Access Management (RAM) user. Therefore, the Message Queue for MQTT clients only need to calculate signatures based on the corresponding AccessKey secret. Permissions are managed in the console by the account administrator.

    • Signature calculation

      To prevent signature stealing, signatures are calculated by using the independent information of each Message Queue for MQTT client. Message Queue for MQTT requires each Message Queue for MQTT client to use its unique client ID as the to-be-signed content. For more information about the signature calculation method, see Signature authentication.

  • Token-based authentication (temporary permissions)

    The token-based authentication mode allows you to use temporary credentials for access. This mode is applicable to scenarios where permissions of each Message Queue for MQTT client must be refined or Message Queue for MQTT clients must be granted only temporary permissions with a limited validity period. The token service allows you to set the resources that can be accessed by a single Message Queue for MQTT client, the permission level that is assigned to the client, and the permission expiration time.

    For more information about the process and precautions of token-based authentication, see Overview of token-based authentication.

    • Scenarios

      The business party has an independent local account system and needs to grant different permissions to different Alibaba Cloud accounts and RAM users, or even must assign an independent account and permissions to each Message Queue for MQTT client. The RAM system of Alibaba Cloud cannot meet the requirements.

      Though the Message Queue for MQTT clients belong to the same Alibaba Cloud account, they must assume different roles assigned by local accounts. The local accounts are owned by the business department or a single Message Queue for MQTT client. This requirement cannot be met by using Alibaba Cloud accounts in signature authentication mode. The use of fixed permissions cannot meet the requirements of mobile devices that must be protected against cracking and hijacking. The use of temporary and non-fixed permissions makes it more flexible to control permissions on a per-client basis and grant permissions on a per-resource basis.

    • Token usage

      Token-based authentication is relatively complex. The business party must have the account (device) management capability and manage the permissions and permission validity period of each device. The business party applies for tokens on secure and controllable management nodes and issues the tokens to Message Queue for MQTT clients. For more information about usage methods, see Overview of token-based authentication.

  • Unique-certificate-per-device authentication

    Unique-certificate-per-device authentication allows Message Queue for MQTT clients to use independent usernames and passwords for identification. This helps you resolve the token fraud issues when a client is untrusted. In unique-certificate-per-device authentication mode, the username and password are bound to the client ID. You can separately manage them.

    • Scenarios

      The business party has high security requirements. In scenarios such as Internet of things (IoT) where tokens cannot be updated in real time, unique-certificate-per-device authentication supports persistent authentication without requiring frequent passive updates of access credentials.

    • Device access credential usage

      In unique-certificate-per-device authentication mode, the application server applies for a unique device access credential for each Message Queue for MQTT client. When a client sends an authentication request to Message Queue for MQTT, information in the access credential is calculated and used as connection parameters based on the agreed rules. For more information about the calculation method, see Overview of unique-certificate-per-device authentication.