MQTT Authentication from Javascript client

785 views
Skip to first unread message

Sam Matthews

unread,
May 9, 2014, 1:44:33 PM5/9/14
to mq...@googlegroups.com
Hello everyone,

I have been working on a project - mostly for fun - using MQTT as a vehicle for chat messaging.  I know it's not very original, but it has been a great learning experience.  The basic architecture is as follows...

Broker : Mosca embedded in node HTTP server over secure websockets
Client : Paho javascript client
Backend: Mongo
Host: OpenShift

It took me a long time to get all the pieces in place but it does actually function and can be reached at:

There is one gaping hole in my app and that is I am not really able to secure broker access from the javascript client.  Even if I setup authentication on the MQTT broker (which Mosca has) I would have to provide the username password in the javascript.  Even if I did not hard code it in, anyone could figure it out without too much trouble.

So I was wondering if anyone has been down this road and could offer up some advice on how I could make my app more secure.

Thanks,
Sam

Pablo Oldani

unread,
Jul 7, 2014, 4:26:50 PM7/7/14
to mq...@googlegroups.com
Hi, did you found the solution to your problem? im having the same issue.

Thanks, Pablo

Paul Fremantle

unread,
Jul 7, 2014, 9:01:45 PM7/7/14
to mq...@googlegroups.com
Sam

The best way to do this would be to use something like OAuth2. I've blogged about this here: http://pzf.fremantle.org/2013/11/using-oauth-20-with-mqtt.html

There is no standards for this, and also no out-of-the-box support, so you are on your own at the moment in implementing this. I did some hacky work to add an OAuth2 backend to Mosquitto, but its not good enough for any volume. 

In fact you have a slightly different problem (that could be solved by OAuth2 but also could be solved another way). Looking at your website, you don't actually want to identify users, you simply want to ensure that the MQTT channel is tied to the web browser. So I would create a custom authenticator and use the cookie from the web session as a temporary password for the MQTT server. That would ensure that the MQTT channel is not wide open. 

Paul


--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.



--
Paul Fremantle
Part-time PhD student - School of Computing
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729

Peter Hunsberger

unread,
Jul 7, 2014, 9:05:40 PM7/7/14
to mq...@googlegroups.com

Haven't been following this, but it sounds a bit like a standard use case for SAML?

Sam Matthews

unread,
Jul 7, 2014, 10:27:25 PM7/7/14
to mq...@googlegroups.com
Thanks Paul for the ideas.  I will go over your blog and try to implement your suggestions

Sam

You received this message because you are subscribed to a topic in the Google Groups "MQTT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mqtt/1gjqT9QCX_c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mqtt+uns...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages