This topic describes the principles and types of client authentication for ApsaraMQ for MQTT to help you select the appropriate authentication feature.
Authentication principle
When an ApsaraMQ for MQTT client sends or receives messages, the server authenticates the client based on the UserName and Password parameters. The meaning of these parameters varies based on the authentication scenario. When you develop an MQTT client, you must select an authentication pattern that fits your scenario and calculate the UserName and Password values according to the specifications of that pattern.
The following table describes how to calculate the UserName and Password for each authentication pattern and the common scenarios for each pattern.
Authentication pattern | Pattern name | UserName | Password | Scenarios |
Temporary token authentication | Token | Consists of the authentication method name, AccessKey ID, and instance ID, separated by vertical bars (|). For example, if a client has a ClientId of GID_Test@@@0001, uses the instance ID mqtt-xxxxx, and uses the AccessKey ID YYYYY, set the UserName for signature-based authentication to "Signature|YYYYY|mqtt-xxxxx". | The uploaded token. For more information, see Token authentication pattern. | Temporary authorization. This pattern is suitable for scenarios where clients are not secure. |
Device-specific credential authentication | DeviceCredential | Consists of the authentication pattern name, DeviceAccessKeyId, and instance ID, separated by vertical bars (|). Example: If a client has a ClientId of GID_Test@@@0001, uses the instance ID mqtt-xxxxx, and has the DeviceAccessKeyId YYYYY, set the UserName for the device-specific credential pattern to "DeviceCredential|YYYYY|mqtt-xxxxx". DeviceAccessKeyId is a parameter in the access credential that the ApsaraMQ for MQTT server issues to the device. For more information, see Device-specific credential authentication pattern. | The Base64-encoded signature of the Client ID. The signature is calculated using the DeviceAccessKey secret as the key. For more information, see Device-specific credential authentication pattern. | Permanent authorization. This pattern is suitable for scenarios where clients are secure and trusted, and the server can update or disable issued device access credentials at any time. |
The AccessKey ID and AccessKey secret are sensitive information. They are used to calculate the UserName and Password for the client. To prevent information leaks, do not hardcode the AccessKey ID and AccessKey secret in your client code. Instead, store this information in your backend application. Your backend application can then calculate the UserName and Password and send them to the client.
Authentication pattern classification and comparison
ApsaraMQ for MQTT supports three authentication patterns: token validation, and device-specific credential validation. The following sections describe the details and common scenarios for each pattern.
Token pattern (temporary permissions)
You can use the token pattern to define fine-grained permissions for each MQTT client or grant temporary, time-limited permissions. This pattern uses temporary credentials for access. The token service lets you set the accessible resources, permission level, and time-to-live (TTL) for a single client.
For more information about the token authentication flow and important notes, see Token authentication pattern.
Scenarios
Use this pattern if your business has its own local account system and you need to further segment identities within your Alibaba Cloud account. You may even need to assign an independent account and permission scope to each MQTT client. In this case, using only the Alibaba Cloud Resource Access Management (RAM) user system is not sufficient to manage MQTT clients.
The MQTT clients run under the same Alibaba Cloud account but must be distinguished by local roles, such as business department or individual client. The account-level permissions of the signature pattern are not sufficient in this case. For mobile applications where you must consider the risk of cracking and hijacking, a fixed permission model is too restrictive. A more flexible approach is needed if access control must be granular to a single client and resource, and all permissions must be temporary.
Token usage
Using the token pattern is relatively complex. This pattern requires you to have your own account or device management system. You are responsible for managing the permissions and validity period for each device. You must request tokens from a secure control plane node and distribute them to your MQTT clients. For more information about how to use tokens, see Token authentication pattern.
Device-specific credential pattern
The device-specific credential pattern allows each MQTT client to use a unique username and password for identity verification. This helps prevent token impersonation in insecure client scenarios. In this pattern, the username and password are bound to the ClientId, and you can manage them independently.
Scenarios
Use this pattern if your business has high security requirements. It is also suitable for scenarios, such as the Internet of Things (IoT), where it is inconvenient to update tokens in real time. The device-specific credential pattern provides persistent authentication and does not require frequent updates of access credentials.
Device access credential usage
In the device-specific credential pattern, the client's application server requests a unique device access credential for each client. When the client sends an authentication request to ApsaraMQ for MQTT, it calculates the connection parameters based on the information in the access credential according to a specific convention. For more information about the calculation method, see Device-specific credential authentication pattern.