This topic provides answers to frequently asked questions about client-side and server-side authentication for ApsaraMQ for MQTT.
Client-side authentication
How do I choose between token-based authentication and unique-certificate-per-device authentication?
Can I grant multiple types of permissions when I request a token?
Why does authentication fail even after I grant permissions using a token?
What is the maximum number of resources that I can operate on in a single ApplyToken API call?
Server-side authentication
How do I choose between token-based authentication and unique-certificate-per-device authentication?
Token-based authentication
Use token-based authentication when you require fine-grained control over individual client permissions—or when you need to grant temporary, time-limited access. With tokens, you define exactly which resources a client can access, what permission level it has, and when the permission expires.
Unique-certificate-per-device authentication
Unique-certificate-per-device authentication lets each MQTT client authenticate with its own username and password. This prevents token spoofing when clients are untrusted. In this mode, usernames and passwords bind to specific Client IDs, so you can manage each client separately.
When you use the Token authentication mode, the client connection drops and returns the "resource auth failed" error.
The token does not have the required permission to publish to or subscribe to the specified topic. You can call the ApplyToken API operation to grant the required permissions to the token.
Can I grant multiple types of permissions when I request a token?
No, you cannot. You can grant only one type of permission to a batch of resources at a time. For example, to grant write permissions to TopicA and read permissions to TopicB, you must call the ApplyToken API operation twice, once for each permission.
Why does authentication fail even after I grant permissions using a token?
The client must wait for confirmation of the token update before it can publish or subscribe. Otherwise, authentication may fail.
How do I monitor tokens?
Five minutes before a token expires, a notification is pushed to the client. The client is automatically disconnected when the token expires. To receive these notifications, you can monitor the $SYS/tokenInvalidNotice topic. You can determine the cause of the authentication failure by checking the code included in the notification.
$SYS/tokenExprireNotice,body is {"exprireTime":1655798142873,"type":"RW"}What is the maximum number of resources that I can operate on in a single ApplyToken API call?
By default, you can use one token to operate on a maximum of 100 resources at a time. If you are using a Platinum instance, you can request to increase this limit. To request an increase, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918.
Why is the "deviceCredential num exceed" error returned when I call the API operation to register an access credential?
The quota for device access credentials is the same as the maximum number of connections allowed for the instance type. If this quota is reached, you cannot request access credentials for new devices. To increase the quota, you can upgrade your instance. For more information, see Upgrade or downgrade an instance.
When you use unique-certificate-per-device authentication, you should promptly call the UnRegisterDeviceCredential API operation to unregister credentials for devices that are no longer in use. This action frees up the quota.
What is the signature calculation method for the password in unique-certificate-per-device authentication?
Charset charset = Charset.forName("UTF-8");
Mac mac = Mac.getInstance("HmacSHA1");
mac.init(new SecretKeySpec(secretKey.getBytes(charset), algorithm));
byte[] bytes = mac.doFinal(text.getBytes(charset));
return new String(Base64.encodeBase64(bytes), charset);The resulting Base64-encoded string is the password.
Why can a group still publish messages after I configure the deny permission for publishing?
If you grant the deny publish permission (Deny mq:PUB) to a specified group, the group can still publish messages.
You need to reconnect the client because Group permissions are verified only when the client reconnects.
Do custom policies support multi-level topics?
Custom policies allow specifying permissions for multi-level topics.
How can a client listen for and update an expiring token?
For more information, see Client listens for expiring token information (no subscription required).
By default, an MQTT client that uses token-based authentication can receive notifications about expiring tokens in the messageArrived method of mqttClient.setCallback. No extra subscription is required.
After you receive the notification, you can publish the new token to the $SYS/uploadToken topic to update the token on the server side.
What is the limit on access credentials for unique-certificate-per-device authentication?
The limit on access credentials for unique-certificate-per-device authentication is the same as the maximum number of connections allowed for the instance. To increase the limit on access credentials, you must increase the maximum number of connections for the instance.
Note the following:
1. The limit on access credentials for unique-certificate-per-device authentication is calculated separately from the number of online connections.
2. After you request an access credential for unique-certificate-per-device authentication, it continues to use the quota until you delete it.
For more information, see Unique-certificate-per-device authentication mode.
Why does unique-certificate-per-device authentication not support mq:PUB?
When you use unique-certificate-per-device authentication, you cannot use mq:PUB to restrict a client to have only the permission to send messages. To configure mq:PUB and mq:SUB permissions separately, you must use signature-based authentication or token-based authentication.
Is signature-based authentication restricted by the RAM permissions of an AccessKey?
Yes, it is. Signature-based authentication is restricted by RAM permissions.
Is token-based authentication restricted by the RAM permissions of an AccessKey?
Token-based authentication is not governed by RAM permissions. If you have permission to call the ApplyToken operation and successfully obtain a token for the specified resource, you can use that token.
How do I configure RAM permissions for token-related OpenAPI operations?
Because the RevokeToken and QueryToken API operations cannot distinguish between instances, you must configure the RAM policy as follows:
{ "Effect": "Allow", "Action": [ "mq:RevokeToken", "mq:QueryToken" ], "Resource": "acs:mq:*:*:*" }