I would like to understand what is the best way to protect Mosquitto when you open the MQTT broker through web ports in a browser. I am currently using Lighttpd for a websocket layer, according to this blog post .
My use case is unidirectional. I need to send messages to the browser. Therefore, I can use the ACL to prevent the publication of malicious messages.
But how can I stop attackers from subscribing or, better yet, make the connection in the first place?
I know that I can use ID / pw to connect MQTT. Thus, I think that my application server can send the credentials to the browser after the user has authenticated himself, and the Javascript client can then use these credentials to establish the MQTT / WS connection. But, if I have thousands of clients, how do I manage identifiers and passwords? Or do I just need to have multiple identifiers and recycle them periodically? Should I pass this bit to Redis or similarly to mosquitto-auth-plug ?
I wondered if there was a better way by securing a connection within the web server layer. The mod_secdownload module for Lighttpd seems to offer a model in which a URL can be dynamically generated based on a shared secret hash (stored -side server) and timestamp. After user authentication, the application server will pass this URL down, and the client will use it to establish a connection with the MQTT broker. After a while, the URL will expire and the Javascript client will be able to catch this exception and, if the user is still authenticated, may request a new WS connection URL. This is similar to a lot of API authentication. Does it matter here?
Is there a better way?
Thanks, J.