QConNY 2017 – IOT and Edge Compute

On Tuesday (6/27/17) I presented about what my company, Chick-fil-A, is doing in the IOT space to a great audience at QConNY.

My talk was focused on Chick-fil-A’s Security story and Edge computing story in support of a larger Internet of Things strategy.

In the short amount of time I had to share our story, it was challenging to really go deep into some of the details about the technologies I used. I wanted to put together a quick reference for those that want to learn more about IOT.

Here are some helpful reference materials:

MQTT

MQTT is a great protocol for lightweight, simple messaging; particularly if you have devices that are power / resource constrained.

If you are going to use MQTT, be aware it is not a queueing service. I recommend reading the MQTT Essentials articles (part 1-11) from HiveMQ. If you read these (and they are short so its an easy investment of time) you will emerge with a thorough understanding of what MQTT is and what it isn’t. Pay specific attention to Quality of Service and how session management works. There are some cool tricks you can do to hand-off sessions from one application to another, as well.

Security

If you are working with JWT, you need to make sure that you understand some of the weaknesses and vulnerabilities that have been identified in the protocol. If used correctly and with up-to-date libraries, JWT can be awesome. Make sure you know what you’re doing.

If you are working with JWT and want an easy way to see a pretty-printed version of your token, or if you want to be able to validate your token’s signature, JWT.io is pretty handy.

OAuth 2.0

We use standard OAuth in a number of places, but we also decided that a few draft specifications were solid enough (and adopted elsewhere) that it made sense for us to implement.

Here is a quick list of what we use, and why.

Dynamic Client Registration

Rather than try to solve distributing crypto-material to devices at manufacture time, we elected to have devices register themselves in-restaurant. Any device can register, but registration does not entitle a device to do anything. We decided we would rather know that a device that didn’t belong registered and then remediate the issue (change wifi configuration, diagnose issue) than to invest tons of energy in try to prevent it.

We leverage the OAuth Dynamic Client Registration flow, which distributed a

Auth Code Flow & Device Code Flow

Auth Code Flow is already an IETF standard, and is used all over. We use it for devices that have browsers available, such as tablets or phones.

Device Code Flow is still in a draft status, but has been widely used by the likes of Google and ESPN, among others.

We implemented the IETF draft for Token Exchange as well. This enables us to use a more pure approach to OAuth elsewhere. When a client is authorized initially, it will simply get an “auth” token tied to the authorized user. This token can then be exchanged for a token that ties the device to its permanent group memberships, which results in proper entitlements for MQTT and other services in the restaurant and in the cloud.

Conclusion

The talk should be online soon, so I will post a link when its available.

Note – I am just getting started on this blog, and this is the first post. I will be writing more about emerging technology in the future and welcome you to check back if you’re interested.