IEEE Consumer Electronics Magazine - July 2015 - 56

The big advantage of using OAuth
for connecting devices is that the
process is well understood and
numerous libraries and API platforms
provide support for API providers
and client developers alike.
own means for connecting the physical device to Carvoyant.
The devices are preprovisioned with service on a virtual
mobile network, and that process provides the connectivity
back to Carvoyant. [The security of devices on virtual mobile
networks should not be taken for granted. The car's internal
network (the so-called CAN bus), OBD-II devices, and the
cellular network are not hardened against attack. While reasonable precautions can prevent some problems, securely
connecting cars to the Internet is an ongoing area of work.]
Carvoyant authorizes access to what amounts to a read-only
API for the car using OAuth. Using the terminology of the preceding sections, Fuse is the client, the Carvoyant account system
is the AS, and the Carvoyant API is RS. Fuse asks car owners to
authorize access to the data about their car in the API using
OAuth. The interaction is a standard authorization code grant.
Fuse helped me understand the pros and cons of using
OAuth for connecting devices to the Internet and ensuring
that the vehicle data ends up in the right hands. For the most
part, OAuth was a great choice for connecting the Fuse system to the Carvoyant API while allowing owners to maintain
control of how their data are used.
The big advantage of using OAuth for connecting devices
is that the process is well understood, and numerous libraries
and API platforms provide support for API providers and client developers alike. But OAuth is far from a complete solution. Let's see why.

OAuth's SHORTCOMINGS FOR THE IoT
We can place the shortcomings of OAuth for device authorization into several categories.

DEVICE LIMITATIONS
From the preceding discussion, we see that one almost universal element of the current connected devices is that they are not
interacting directly with the client. Rather, something else, a
cloud-based service, a gateway, or a phone, is acting as a
proxy. This is often necessary or at least desirable for reasons
beyond access control such as interdevice coordination. Devices often have small microcontrollers instead of full-blown
microprocessors and do not have the memory or processing
power to even parse a JSON object, let alone handle HTTP
with TLS.
Furthermore, the devices often do not have displays,
making configuration and other interactions difficult. This
56 IEEE Consumer Electronics Magazine

july 2015

restricts the utility of OAuth flows since the device is
unlikely to have a Web browser available to process the
redirects. These limitations apply whether the device is acting as the API (the left-hand side of Figure 1) or the client
(right-hand side). There are several ways we can mitigate
these issues.
The most obvious way, as we have seen, is to proxy the
device with something more powerful that can overcome
these issues. That still leaves us with the problem of connecting the device to the proxy in a secure manner. For the most
part, this latter process is ad hoc with few standards. As a
result, the user experience of connecting a device and using it
varies widely. What's more, the security of these ad hoc
mechanisms is highly dependent on the ability of the programmers creating it.
Another approach is to make connecting to lower-powered
devices easier. Alternate transport protocols such as MQTT
[4], interaction protocols like the Constrained Application
Protocol [5], and security protocols such as Datagram Transport Layer Security [6] are potential fixes, either by themselves or in combination with each other.
When the lack of a display is the primary problem, the
user can grant access through OAuth on a more capable
device such as a mobile phone and then configuration and
tokens can be transferred to the device, removing the proxy
from the device interactions with other devices and APIs.

WHERE'S THE USER?
OAuth's flows were designed for systems where the user is
available to approve the initial connection. We have already
discussed the problems of low-powered devices not supporting Web browser-based flows, but there is another problem.
As we saw, OAuth supports refresh tokens. Refresh tokens
are meant to be used by the client with the AS to get a new
access token when the old one has expired. Normally, this is
not a problem for a connected device since the user does not
need to reauthorize access to use a refresh token. The problem occurs when the refresh token fails for some reason and
the user needs to regrant access. In the Web and mobile interactions envisioned by OAuth's original framers, this was not
a big concern since the need to access the API would be driven by the user interacting with the application. Hence, the
user is available to approve access again, if necessary.
Devices are another matter as they are often reacting to
their environment. Consequently, the user is not available to
handle problems with access control. I had this specific
problem with Fuse. The device reacts to vehicle events such
as the ignition being turned off or on. When that happens,
the Fuse system wants to process the event and may need
other information from the device and its API. All of these
are happening in the background without human involvement. Consequently, if the refresh token fails, Fuse has no
recourse except to notify the user using e-mail or some
other means that an access control problem has occurred
and that they need to log in and fix it. In the meantime, Fuse
is disconnected from the API and is unable to carry out the

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