OAuth binding for MQTT

Paul Freemantle blogs about some experimenting he has done around using OAuth within MQTT - specifically using an OAuth access token in the place of a username password.

I've been thinking about security and privacy for IoT. I would argue that as the IoT grows we are going to need to think about federated and user-directed authorization. In other words, if my device is publishing data, I ought to be able to decide who can use that data. And my identity ought to be something based on my own identity provider.

Choir member here appreciating the sermon.

Paul appeared to focus on how the MQTT client, once having obtained an OAuth access token reflecting the relevant user's consent to some set of operations (captured in a scope), used that token on its CONNECT messages to a MQTT broker. In the end, he used the existing MQTT username parameter to carry the token.

Coincidentally, I was thinking about the same integration yesterday, though focussed less on how to bind the tokens to the MQTT messages and more on how we might leverage MQTT's existing pub/sub model to get the token to the Client.

Something like

1. Client send the username/password on MQTT CONNECT message
2. Client sends SUBSCRIBE message for a topic of 'access_token/#'
3. MQTT broker responds with a PUBLISH message carrying the access token.
4. Client discards password, stores access token

On subsequent interactions (as long as the token hadnt expired) with the broker, the client would use the token instead of the username/password combination.

The above pattern, namely the client directly exchanging a username/password for an access token, mirrors the OAuth Resource Owner Credentials grant type - allowed for in OAuth but not recommended.

There are definite advantages to instead leveraging a web browser (as Paul indicated he had used) for the token issuance, including

1. password need not be presented to broker
2. allows for federated user authentication (ie at some other IdP)
3. allows for a detailed & granular consent UI

But perhaps the above issuance model would be easier to layer onto simple MQTT clients - leveraging as it does the existing flow.