This article introduces ApsaraMQ for MQTT the principle and classification of client authentication, which allows you to use the corresponding authentication function.
Authentication principle
Use ApsaraMQ for MQTT when an MQTT client sends and receives messages, the MQTT broker authenticates the MQTT 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 during MQTT client development based on the actual situation, and the Username and Password parameters must be set correctly based on the corresponding specifications.
- Authentication modes
Mode Description Scenarios Signature Signature verification Permanent authorization, applicable to secure and trusted clients Token On-demand token permission verification On-demand authorization, applicable to untrusted clients - Username
The username parameter consists of the authentication mode, AccessKeyId, and InstanceId, which are separated by vertical bars (|).
For example, if the ClientId of a client is GID_Test @, the instance ID is timestamp, and the AccessKeyId is yyyyyyy, the UserName should be set to "Signature | YYYYY | Timestamp" in Signature mode and to "Token | YYYYY | Timestamp" in Token mode.
- Password
Permission verification mode Password Scenarios Signature verification Client ID signature encoded in Base64. for the setting method, see the document about signature calculation. Permanent authorization is applicable to secure and trusted clients. On-demand token permission verification Uploaded Token content. For the setting method, see the document about Token calculation. Temporary Authorization. This operation applies when the client is not secure.
Types and comparison of authentication modes
According to the above classification, ApsaraMQ for MQTT currently, two authentication methods are supported, namely signature verification and Token verification. They correspond to two scenarios with fixed permissions and non-fixed on-demand permissions, respectively. They are subdivided and analyzed as follows.
- Signature authentication (fixed permissions)
The signature mode is ApsaraMQ for MQTT this authentication mode specifies that MQTT clients of the same type have the same permissions and use the same account for signature calculation. The MQTT Broker identifies the accounts and permissions of the MQTT clients through signature comparison. The signature authentication mode is easy to understand and use.
- Scenarios
The used 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 MQTT client is relatively controllable. You do not have to worry about malicious attacks against devices, such as cracking and stealing.
From the service perspective, MQTT clients of the same type are managed by the same account, which can be a primary account or a sub-account. Therefore, the MQTT clients only need to calculate signatures based on the account AccessKeySecret. Permissions are managed in the console by the account administrator.
- Signature calculation
To prevent signature stealing, the independent information of each client is required for signature calculation. ApsaraMQ for MQTT Define a client ID unique to each client as the to be signed. For the signature calculation method, see Signature authentication.
- Scenarios
- Token authentication (on-demand permissions)
The token authentication mode supports access through on-demand credentials and is applicable in the scenario where the permissions of each MQTT client need to be classified with a small granularity or MQTT clients need to be assigned only on-demand permissions with a limited validity period. The token service allows you to set the resources that are accessed by a single MQTT client, the permission level that is assigned to the MQTT client, and the permission expiration time.
For more information about the process and precautions of Token authentication, see Overview of token authentication.
- Scenarios
The service party has an independent local account system and needs to split the identities of Alibaba Cloud accounts for the second time, or even needs to assign an independent account and permissions to each MQTT client. In this case, the RAM user system of Alibaba Cloud cannot meet the requirement for refined classification of MQTT clients.
Though the MQTT clients belong to the same Alibaba Cloud account, they need to play different roles assigned by local accounts (owned by the service department or a single 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 terminals that need to protect against cracking and hijacking. Use of only on-demand and non-fixed permissions makes it more flexible to control permissions on a per-client basis and assign permissions on a per-resource basis.
- Token Usage
The token authentication mode is relatively complex. The service party needs to have the account (device) management capability, manage the permissions and permission validity period of each device, apply for tokens on secure and controllable application servers and authorization servers, and deliver the tokens to MQTT clients. For usage instructions, see the document about the token service.
- Scenarios