This topic provides answers to some commonly asked questions about the authentication of ApsaraMQ for MQTT in the client and cloud.
Authentication in the client
- How do I determine whether I require token-based authentication and unique-certificate-per-device authentication for my business scenario?
- Why is the client disconnected and the "resource auth failed" error returned after I use token-based authentication?
- Can I grant multiple permissions to different types of resources when I apply for a token?
- Why did the authentication still fail even after an operation is performed to initiate the token-based authentication?
- How do I monitor the token?
- What is the number of resources for which I can call the ApplyToken operation in a batch?
- Why is the "deviceCredential num exceed" error returned when I call the access credential operation?
- What is the signature calculation method that is used for the password in the unique-certificate-per-device authentication mode?
Authentication in the cloud
How do I determine whether I require token-based authentication and unique-certificate-per-device authentication for my business scenario?
- Token-based authentication
The token-based authentication mode allows you to use temporary credentials for access. This mode is applicable to scenarios where the permissions of each Message Queue for MQTT client must be refined or Message Queue for MQTT clients only need to be granted temporary permissions. The token-based authentication mode allows you to set the resources that can be accessed by a single Message Queue for MQTT client, the permission level that is assigned to the client, and the permission expiration time.
- Unique-certificate-per-device authentication
Unique-certificate-per-device authentication allows Message Queue for MQTT clients to use independent usernames and passwords for identification. This helps you resolve token fraud issues when a client is untrusted. In the unique-certificate-per-device authentication mode, each client ID has a unique username and password, so that you can manage Message Queue for MQTT clients separately.
Why is the client disconnected and the "resource auth failed" error returned after I use token-based authentication?
The token that you used has no permission to publish or subscribe to the specified topic. You can call the ApplyToken operation to authorize the token.
Can I grant multiple permissions to different types of resources when I apply for a token?
No, only one permission can be granted to the same type of resources. For example, if you want to grant write permissions to Topic A and read permissions to Topic B, you must call the ApplyToken operation twice.
Why did the authentication still fail even after an operation is performed to initiate the token-based authentication?
You can publish and subscribe to messages only after the client confirms that the token is successfully updated. If you attempt to publish and subscribe to messages when the token is not successfully updated, the authentication may fail.
How do I monitor the token?
You can monitor the $SYS/tokenInvalidNotice topic to receive notifications about authentication failures. The causes of these failures are included in the code. For example, if a message is about to expire, a message that reminds the user about the token expiration is pushed to the client five minutes before the token expires. The client is automatically disconnected after the token expires. The following sample code shows a notification that indicates the authentication failure is caused by an expired token:
$SYS/tokenExprireNotice,body is {"exprireTime":1655798142873,"type":"RW"}What is the number of resources for which I can call the ApplyToken operation in a batch?
By default, you can use each token to perform operations on up to 100 resources at a time. If you are using a Message Queue MQTT Platinum Edition instance, you can apply to increase the maximum number of resources on which each token can perform operations. To do so, contact ApsaraMQ for MQTT technical support.
Why is the "deviceCredential num exceed" error returned when I call the access credential operation?
The quota that is provided for the access credentials for a device is equal to the maximum number of connections that is specified in the instance specification. When the upper limit is reached, you cannot apply for access credentials for new devices. You can upgrade the instance specification to increase the quota for access credentials. For more information, see Upgrade or downgrade the configurations of an instance.
When you use the unique-certificate-per-device authentication mode, we recommend that you call the UnRegisterDeviceCredential operation to delete the access credentials that are no longer required at the earliest opportunity to save the quota.
What is the signature calculation method that is used for the password in the unique-certificate-per-device authentication mode?
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 Base64-encoded string is used as the password.
Why am I able to publish messages after I configure the Deny mq:PUB permission for a group?
After you grant the Deny mq:PUB permission to a specified group, the group can continue to publish messages.
You must reconnect to the client. Group permissions are verified only after the client is reconnected.
Do custom permission policies support multi-level topics?
Yes, custom permission policies allow you to grant permissions to multi-level topics.