-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: No Action
-
Affects Version/s: 5, CSD01
-
Fix Version/s: None
-
Component/s: core
-
Labels:None
The initial AUTH packet can only be sent by the client to re-authenticate. There are use cases for a server-initiated AUTH packet.
An example would be if login credentials are revoked on the broker side (e.g. due to administrative interventions). There is currently no way to force the client to re-send the AUTH packet. A server side AUTH challenge may help in such cases, so the client has a chance to provide valid credentials in case the original secrets are not valid anymore.
Another use case would be OAUTH 2.0. The JWT as Access Token may expire and the broker can notify the client that a new token is required.
The proposal in MQTT-431 is sufficient, this issue can be marked as duplicate.
The arguments for such a feature were already stated in MQTT-431. An additional argument I'd add would be that in case of administrative revocation of authentication credentials, a re-authentication request by the broker for specific clients may be useful in scenarios where it's undesired to disconnect the client in order to enforce a re-authentication.
This issue was discussed at the MQTT TC on 2017-09-28. After some discussion it was decided to stay with the earlier TC decision and not provide a method for the server to request the client to re-authenticate.
The server is of course free to disconnect (with or without first sending a DISCONNECT packet) if the authentication for this client expires.
This same issue was discussed in the TC as
MQTT-431. There was a proposal to add the ability of the server to request the client to initiate reauthentication. The decision of the TC was to close that issue without any action.1. What do we think is different now that the TC would come to a different opinion?
2. Do you think that the proposal in
MQTT-431is what is desired?