[OASIS Issue Tracker] (MQTT-507) Allow Server-sent AUTH packets

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67352#comment-67352 ] 

Dominik Obermaier commented on MQTT-507:
----------------------------------------

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. 

> Allow Server-sent AUTH packets
> ------------------------------
>
>                 Key: MQTT-507
>                 URL: https://issues.oasis-open.org/browse/MQTT-507
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 5, CSD01
>            Reporter: Dominik Obermaier
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)