IEEE Consumer Electronics Magazine - July 2015 - 53

This article will examine API access control, focusing
on OAuth. We will examine the most common OAuth
flows in detail and discuss how they work, why they are
secure, and when and when not to use them. We will also
evaluate the applicability of OAuth to connected devices,
look at OAuth techniques for consumer electronics, and
explore emerging standards for access control on the Internet of Things (IoT).
If you are anything like me, you have got a collection of
connected devices-everything from Hue lightbulbs to Nest
thermostats. The problem with all these devices-and the thing
that keeps me from saying that they are part of the IoT-is that
they are all quite antisocial. That is, they do not easily talk to
each other.
Almost every connected device currently for sale uses the
same model.
▼ Download the mobile app.
▼ Create an account on the manufacturer's server.
▼ Connect your new device to your account.
The last step is accomplished in different ways, depending on
how the device actually connects (i.e., via Bluetooth, Wi-Fi,
ZigBee, and so on). Regardless, in the end, I have a device
that I can control with my phone. That's great the first few
times, but eventually the novelty wears off, and I just want a
light switch to turn on the lights. What's more, the Hue lights
are not the only connected lights I have, and opening two
apps to turn on the lights is beyond my endurance.
Most current IoT business models focus on cloud-based
strategies that place the vendor at the heart of the data architecture. Clearly, if the IoT is going to come to fruition, we are
going to need better ways of connecting devices. Merely connecting them to a network and then to an account controlled by
the manufacturer is not enough. Devices need to be connected
to each other and to the services used by the owner. Owners
want to coordinate their interactions, and this requires more
than just having devices connect to their maker.
Devices need rich connections because of
▼ discovery of contextual and other data such as weather or
price data through Internet-based APIs
▼ coordination with other devices and systems to achieve
a goal such as reducing the peak electric power usage in
a home
▼ integration with systems that can automatically represent
the owner's intent such as reducing the thermostat only if
the house will be unoccupied for more than 8 h.
Richer connections will allow us to move from the current
manufacturer-centric connected device ecosystem to one that
is a true IoT. Making these interactions secure and protecting
owner privacy will require more sophisticated access control
methods than are currently employed.

of a person's life. The best way to ensure that systems protect
people's personal data and respect their wishes is to make
people a part of the process.
As illustrated in Figure 1, the IoT creates many relationships between sensors and other connected devices, cloudbased accounts, gateways, hubs, mobile devices, and other
resources. Each of these interactions might carry personal
data that the owner wishes to keep private, implying a need
for a secure, authenticated channel. More importantly,
doing this conveniently and dependably requires that service operators are trustworthy and working with the owners' interests in mind.
Sometimes, the device will be connected to a cloud-based
service that proxies the data and potentially provides other services. At other times, the device will be proxied by a mobile
phone. Often, simple devices will have a smart hub that serves
as their proxy. At present, at least, most devices are too low
powered to support direct connections from arbitrary clients. In
addition, the proxies need connections to the owners and the
other resources they control and, often, to each other.
Last October, I launched a connected car project called
Fuse. Fuse uses a cellular device that plugs into the OBD-II
port on any car. The device is from a company called Carvoyant. Carvoyant also provides a service that proxies the device
and gives it a cloud-based API. This model fits the top-most
path in Figure 1, where the device uses a cloud-based proxy to
provide an API for the client. Later, we will return to Fuse and
discuss how authentication worked on the paths between the
device and cloud-based API and the API and client, in turn.
Supporting the connections with devices and ensuring that
their owner is in control of the data associated with them
assumes we can do at least the following [1]:
1) ensure that the device has a unique identifier
2) register the device over a secure channel
3) authenticate the device
4) create an association or relationship between the user and
the device.
There are various ways we could implement a system
that fulfills these requirements. OAuth is a viable mechanism for the last two. Over the past several years, as APIs
for personal data have become more widely used, OAuth

ACCESS CONTROL FOR DEVICES
Securely connecting devices to each other, to APIs, and to
owner systems is not an easy task. Connected devices carry
personal information, and, as they become more ubiquitous,
the aggregation of that data can represent significant elements

FIGURE 1. The IoT creates numerous authenticated relationships.

july 2015

IEEE ConsumEr ElECtronICs magazInE

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - July 2015