您需要代理代理或网络服务器...

首先，您绝对需要在某处连接到您的代理的身份验证服务，以使用特定主题 ( /auth/RFID,...)执行 2FA 。然后它将允许客户端发布信息（见下文）。

我在这里看到的第一个问题是，订阅此主题的任何人都可以阅读该主题的信息，但您可以锁定主题！

然后，您可以告诉（强制）您的所有设备将信息发布到/proxy/mytopic. 借助 mqtt 的 clientId 功能，auth 服务可以检查从该主题发送的消息是否来自之前使用 2FA 的经过身份验证的设备，然后代表设备将其自己的消息发布到/proxyout/mytopic负载中带有设备 id 的位置。

现在的问题是检查是否可以接收经过身份验证的消息的设备，因为 MQTT 完全是关于批量发布的。auth 服务需要有一个经过身份验证的设备列表，并检查它们是否有资格接收。再次，有效载荷加密和解密设备端......

我认为我的解决方案对 MQTT 功能来说太过分了。因此，您应该使用套接字或 Web 服务器...

即将推出的 MQTT v5 规范增加了对AUTH控制数据包的支持，允许质询/响应身份验证。由于 MQTT v5 尚未最终确定，支持可能仍会发生变化，但假设 AUTH 将保留某种形式并且可以使用它添加 2FA 似乎是合理的。

您可以在OASIS MQTT 委员会文档页面查看规范的当前工作草案。

根据规范，连接消息可以选择提供用户名和密码。这是根据保存在代理上某处的 ACL 进行验证的。因此，这是您可以利用的第一个身份验证因素。如果身份验证通过，来自代理的 CONNACK 消息将响应。

要实现身份验证的第二个因素，最好的方法应该是使用另一个因素发送自定义连接消息。在这种情况下的 CONNACK 消息应该是指第二个认证因素的成功或失败。因此，代理和客户端应该在规范之上实现自定义消息。

为了在 MQTT 网络中实现 2FA，我创建了以下连接到 Broker 的身份验证服务。

1. 身份验证器
2. 令牌生成器
3. 令牌验证器

当 MQTT 客户端通过 SSL/TLS 连接到代理时，它首先将自己的 ID 发布到device_id主题，ID 验证器验证它是真实的客户端，然后调用令牌生成器生成令牌并将令牌发布到锁定的主题device_token 上。

客户端设备获取此令牌并进一步将其发布到主题verify_token。一旦主题在verify_token上发布，令牌验证器就会比较主题device_token和verify_token 中的值，如果匹配，则将设备的 id 添加到已验证的设备池并允许设备发布数据。这提高了安全性，因为只有经过验证的设备才能连接到主题以发布数据。

我还使用 MQTT_KEEPALIVE 配置选项在没有发送或接收数据时保持客户端处于活动状态，以保持客户端设备在设备池中处于活动状态，并防止在将其添加到设备池后再次对其进行验证。但是为了安全起见，我每 24 小时将设备设置为 2FA。