Authentication overview
ApsaraMQ for MQTT authenticates clients using signature-based or token-based patterns. Choose the pattern that matches your security requirements.
Authentication principles
When an ApsaraMQ for MQTT client sends or receives messages, the server authenticates the client based on the `UserName` and `Password` parameters. These parameters have different meanings depending on the authentication pattern. Select the pattern that fits your scenario and calculate the `UserName` and `Password` values accordingly.
- Authentication patterns
Pattern name Description Scenarios Signature Signature validation Permanent authorization for secure, trusted clients. Token Temporary token authentication Temporary authorization for clients that are not secure. - UserName
The `UserName` consists of three parts separated by vertical bars (|): authentication pattern name, AccessKey ID, and instance ID.
For example, if a client has a ClientId of `GID_Test@@@0001`, an instance ID of `mqtt-xxxxx`, and an AccessKey ID of `YYYYY`, the `UserName` for the signature pattern is `Signature|YYYYY|mqtt-xxxxx`. The `UserName` for the token pattern is `Token|YYYYY|mqtt-xxxxx`.
- Password
Authentication pattern Password Scenarios Signature validation Base64-encoded signature of the `clientId`, as specified in the signature calculation documentation. Permanent authorization for secure, trusted clients. Temporary token authentication The uploaded token content, as specified in the token calculation documentation. Temporary authorization for clients that are not secure.
Signature vs. token authentication
ApsaraMQ for MQTT supports two authentication methods: signature validation (fixed permissions) and token validation (temporary permissions).
- Signature pattern (fixed permissions)
The signature pattern is the default and recommended authentication method for ApsaraMQ for MQTT. All clients of the same type share one account for signature calculation. The server verifies each client's identity and permissions by validating the signature.
- Scenarios
Use this pattern when all clients belong to the same account with shared permissions, and the runtime environment is secure (no risk of device cracking or theft).
Assign a group of clients to a single Alibaba Cloud account or RAM user. Each client calculates the signature using that account's AccessKey secret. The account administrator manages permissions in the console.
- Signature calculation
To prevent signature theft, ApsaraMQ for MQTT requires each client to sign its unique `ClientId` as described in Signature authentication pattern.
- Scenarios
- Token pattern (temporary permissions)
The token pattern defines fine-grained, time-limited permissions per client. You can specify the accessible resources, permission level, and TTL for each client through the token service.
The authentication flow and constraints are detailed in Token authentication overview.
- Scenarios
Use this pattern when you maintain a local account system and need per-client identity separation beyond what RAM users provide.
Clients under a single Alibaba Cloud account may still need role distinctions by business unit or individual client. The signature pattern operates at the account level and cannot provide this granularity. The token pattern is especially suited for mobile scenarios where cracking or hijacking is a concern, because it assigns temporary, scoped permissions per individual client.
- Token usage
The token pattern requires your own account or device management system. You manage the permission scope and validity period for each device, request tokens from a secure, controllable control-plane node, and distribute them to clients.
- Scenarios