This topic describes the principle and types of authentication of Message Queue for MQTT clients.
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 definitions of the Username and Password parameters vary depending on different scenarios of permission verification. A proper authentication mode must be selected based on the actual scenario during Message Queue for MQTT client development. In addition, the Username and Password parameters must be correctly set based on the corresponding specifications.
- Authentication modes
Mode Description Scenario Signature Signature verification Permanent authorization, which is applicable to secure and trusted clients. Token Token-based permission verification Temporary access authorization, which is applicable to untrusted clients.
The Username parameter consists of the authentication mode, 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, the Username parameter for connecting this Message Queue for MQTT client must be set to Signature|YYYYY|mqtt-xxxxx in signature authentication mode and to Token|YYYYY|mqtt-xxxxx in token-based authentication mode.
Permission verification mode Password Scenario Signature verification The client ID signature encoded in Base64. For more information about the setting method, see the document about signature calculation. Permanent authorization, which is applicable to secure and trusted clients. Token-based permission verification Uploaded token content. For more information about the setting method, see the document about token calculation. Temporary access authorization, which is applicable to untrusted clients.
Types and comparison of authentication modes
Message Queue for MQTT supports signature authentication and token-based authentication, which respectively correspond to fixed permissions and non-fixed temporary permissions. The following information describes the two 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.
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.
From the service perspective, Message Queue for MQTT clients of the same type are managed by the same account, which can be an Alibaba Cloud account or a 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
Signatures are calculated by using each Message Queue for MQTT client's independent information to prevent signature stealing. 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 the 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 are accessed by a single Message Queue for MQTT client, the permission level that is assigned to the Message Queue for MQTT client, and the permission expiration time.
For more information about the process and precautions of token-based authentication, see Overview of token-based authentication.
The service party has an independent local account system and must split the identities of Alibaba Cloud accounts for the second time, or even must assign an independent account and permissions to each Message Queue for MQTT client. In this case, the RAM user system of Alibaba Cloud cannot meet the requirements for refined Message Queue for MQTT clients.
Though the Message Queue for MQTT clients belong to the same Alibaba Cloud account, they must assume different roles assigned by local accounts (owned by the service 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 protect 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
The token-based authentication mode is relatively complex. The service party must have the account (device) management capability, manage the permissions and permission validity period of each device, apply for tokens on secure and controllable management nodes, and deliver the tokens to Message Queue for MQTT clients. For more information about usage instructions, see the document about the token service.