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

Working mechanism

When a Message Queue for MQTT client sends and receives messages, the Message Queue for MQTT broker authenticates the username and password of the client. 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 set correctly 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 signature calculation result for the client ID. The calculation uses AccessKey secret as the key and the result is a string 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 signature calculation result for the client ID. The calculation uses DeviceAccessKey secret as the key and the result is a string 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.
Notice AccessKey ID and AccessKey secret are extremely sensitive data that are associated with the values of the UserName and Password parameters. To prevent data leakage, we recommend that you embed your AccessKey ID and AccessKey secret in the code of your backend application instead of the client to obtain the requested values of the UserName and Password parameters. The backend application calculates the signature and delivers the result to the client.

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 section describes the three modes and the corresponding 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 use the same account to calculate signatures. 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.

    • Applicable 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 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 theft, signatures are calculated 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 string to sign. 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 the permissions of each Message Queue for MQTT client must be refined or Message Queue for MQTT clients only need to be granted temporary permissions. The token-based authentication mode 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.

    • Applicable scenarios

      Users have independent local account systems and need 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 different users or different Message Queue for MQTT clients. This requirement cannot be met by using Alibaba Cloud accounts in the signature authentication mode. Fixed permissions do not meet the requirements of mobile devices that must be protected against cracking and hijacking. Temporary permissions make the control and granting of permissions on a per-client basis more flexible.

    • Token usage

      Token-based authentication is relatively complex. Users must have the account (device) management capability and manage the permissions and permission validity period of each device. Users apply 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 token fraud issues when a client is untrusted. In the unique-certificate-per-device authentication mode, each client ID has a unique username and password, so that you can manage Message Queue for MQTT clients separately.

    • Applicable scenarios

      Users have high security requirements. In scenarios such as Internet of things (IoT) devices 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 the 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 established rules. For more information about the calculation method, see Overview of unique-certificate-per-device authentication.