Using OAuth for Access Control on the Internet of Things

Phillip J. Windley, Ph. D.
Office of the CIO
Brigham Young University

This article is a draft of an article that appears in IEEE Consumer Electronics Magazine, Vol 4. Iss 3

Summary

The use of RESTful APIs is growing quickly as more and more organizations determine that they can extend their core business by attracting developers and becoming a platform for online apps. This trend has been accelerated by the increasing use of mobile applications that rely on access to server-based data and processes to accomplish their work. The increasing availability of connected consumer devices beyond mobile will further speed up API popularity.

While some APIs can be used without authentication or authorization, the majority require some form of access control. For APIs that don’t involve user accounts, the use of developer keys and secrets (a form of username/password access control) is sufficient. However the most interesting use cases involve users authorizing an API to share their data with an application on their phone, a connected device, or another Web site using a protocol called OAuth.

This article will examine API access control, focusing on OAuth. We’ll examine the most common OAuth flows in detail and discuss how they work, why they’re secure, and when and when not to use them. We’ll 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.

Introduction

If you’re anything like me, you’ve 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 they are part of the “Internet of Things”—is that they are all quite anti-social. That is, they don’t easily talk to each other.

Nearly 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: Bluetooth, Wi-Fi, Zigbee, and so on. But regardless, in the end, I have a device 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 aren’t the only connected lights I have. And opening two apps to turn on the lights is beyond my endurance.

Most current Internet of Things business models focus on cloud-based strategies that place the vendor at the heart of the data architecture.

Clearly, if the Internet of Things is going to come to fruition, we’re going to need better ways of connecting devices. Merely connecting them to a network and then to an account controlled by the manufacturer isn’t enough. Devices need to be connected to each other and to services that the owner uses. Owners want to coordinate their interactions and this requires more than just having devices connect to their maker.

Here are some of the reasons devices need rich connections:

• 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 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 eight hours.

Richer connections will allow us to move from the current manufacturer-centric connected device ecosystem to one that is a true Internet of Things. Making these interactions secure and protecting owner privacy will require more sophisticated access control methods than are currently employed.

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 of a person’s life. The best way to ensure systems protect people’s personal data and respect their wishes is to make people part of the process.

As illustrated in Figure 1, the Internet of Things creates lots of relationships between sensors and other connected devices, cloud-based 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.

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 owners and 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’ll return to Fuse and discuss how authentication worked on the paths between 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 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 has become the protocol of choice for letting users choose what applications access their data. OAuth makes users part of the process that determines what data is shared and with what application.

The remainder of this article will examine how OAuth works, catalog its fitness for purpose as an access control mechanism for the Internet of Things, and explore proposed extensions and enhancements that are likely to play a role in securely connecting devices.

Why OAuth

OAuth [2] was invented for a very specific purpose: to allow users to control access to their accounts without requiring that they share their username and password. Before OAuth, if Alice wanted Site B to have access to her data on Site A, she’d give Site B her username and password on Site A. Site B would store the username and password and impersonate Alice each time they need to access Site A on her behalf. By using Alice’s username and password Site B would demonstrate that they had Alice’s implicit permission to access her account on Site A. This sometimes called the “password anti-pattern.”

The password anti-pattern has serious drawbacks

• the resource server (i.e. the server hosting the API) can’t differentiate between the user and other servers accessing the API
• passwords stored at other servers increase the risk of a security breach.
• granular permissions are hard to support since the resource server doesn’t know who is logging in.
• shared passwords are difficult to revoke and must be updated in multiple places when changed.

OAuth fixes these by making the resource server part of the flow that delegates access. Consequently, the resource server can ask the user what permissions to grant and record them for the specific client requesting access. Moreover, the client can be given its own credential apart from those that the user has or those used by other clients the user might have authorized.

OAuth Basics

OAuth[1] is a protocol for access control. As such it defines the interactions among several actors who play specific roles (see Figure 2).

The central figure in these interactions is the resource owner. The owner is the actor, almost always human, that controls client access to resources. One of the reasons OAuth is an important building block for the Internet of Things is because it supports access control by an owner.

The owner has resources on a resource server (RS). The resource server protects the owner’s resources by controlling access. The server might be a cloud-based API or a connected device.

The owner also specifies the authorization server (AS). The authorization server issues credentials that can be used to access resources on the RS.

The interactions between these actors results in the client being granted an access token by the AS that it can later present to the RS and gain access to the protected resources.

There is often confusion about whether OAuth is an authentication or an authorization protocol. In fact it’s a little of both. The OAuth specification doesn’t specify the structure of the tokens. There is not necessarily any identifying information in the token. Further, the resource being accessed might or might not have identity information and OAuth doesn’t presume that the AS, RS, and client share any common identifier for the user other than the OAuth token. OpenID Connect is an authentication protocol that is based on OAuth and adds an identity layer for applications that need it [3].

There are two primary activities in OAuth:

1. Getting a token
2. Using a token

We’ll discuss each of these in turn.

Getting a Token

To get an access token, the client interacts with an authorization server. There are four ways to do this. They’re formally called authorization grant types but most people call them “OAuth flows”. The different flows exist to accommodate different types of clients and access scenarios.

Authorization Code Grant

The authorization code grant is the most commonly used OAuth flow and the one most people are talking about when they say “OAuth.” If you’ve ever signed into a Web site with Google, Facebook, or Twitter, you’ve used this flow. The green arrows in Figure 2 illustrate the Authorization Code Grant.

In this flow, the authorization code is returned to the client after the owner has given explicit permission to the AS. Usually this is done by the user clicking on an “Accept” or similarly labeled button on a Web page served up by the AS. The page will generally list the permissions that are being granted for the owner. The owner can decide whether to agree or not.

The specifics of the interaction call for the AS to redirect the owner back to the client via a URL supplied by client when it registered with the AS. The redirect contains a one-time, opaque code in the query string portion of the URL that the client can exchange for the actual access token in the background.

Obviously this type of grant is only usable when the owner is present to interact with the AS and the client can allow the user to interact with the AS via a Web browser. Web sites fit this description as do desktop and mobile applications that can make use of an embedded browser.

Implicit Grant

Like the Authorization Code Grant described above, the Implicit Grant flow redirects the owner to the AS where she signs in and explicitly grants permissions to the client to access resources. The difference lies in what gets returned. Unlike the Authorization Code Grant, the Implicit Grant returns the access token directly when the owner is redirected back to the client.

The Implicit Grant is intended for clients that might not be able to keep the access token secret for some reason. Therefore, the access token returned usually has only limited permissions. In addition, the access token is typically short-lived and does not come with a refresh token for extending the grant’s life.

Resource Owner Credentials Grant

In the Resource Owner Credentials Grant, the client collects the owner’s username and password (or other credentials as appropriate) and exchanges those for an access token. While this might feel like the password anti-pattern we discussed above, in the Resource Owner Credentials Grant, the client doesn’t store the username and password, but merely exchanges them. Examples of where this might be desirable are in a mobile app or other use case where redirection is difficult.

While many see this grant type as sub-optimal, the fact that it doesn’t rely on Web redirection makes it quite suitable for connected devices that don’t have Web interfaces or where the processing power is insufficient for managing complex HTTP flows.

Client Credentials Grant

The Client Credentials Grant uses the credentials that the client has to gain access to resources in its own right. This is often useful for clients to “boot up” with an RS API, supply client information, or create accounts for the owner. Most API providers supply developer keys and tokens to people building applications on their platform. These developer keys and tokens can be used in a client credential grant for client-specific features of the API. This grant is also applicable when an organization is using OAuth for access control but controls both the client and RS. For example, administrative applications that an organization uses to manage systems might use client credential grants for access to resources when they are not the owner of the data, but need legitimate administrative access for other reasons. Another use of this flow is situations where some resources on the RS are considered public, but the RS needs to limit access and ensure only clients known to the RS are accessing the resource.

Refresh Tokens

Access token may have a time-to-live. When the do, the AS can also give the client a refresh token that can be used to renew the access token. Refresh tokens are never sent to the RS, only the AS. As a result, the RS can’t save them and replay them later, strengthening the owner’s control over access to the resource.

Using a Token

Using a token is straightforward. The AS has returned an access token to the client. The client presents the access token to the RS whenever it needs access to the resource. The blue arrows of Figure 2 show the standard interaction for using an OAuth token.

The standard interaction is for the client to present the access token in the HTTP Authorization header prefixed with the string Bearer. This reminds us that the access token is indeed a bearer token. The RS will provide access to the resource in keeping with the permissions granted by the owner regardless of who presents the token. Keeping the token secure is therefore paramount.

Token Types

The OAuth 2.0 specification does not require a specific token structure. Usually, access and refresh tokens are long opaque strings that are useful only as keys into a data structure where the real information is stored.

Work is underway in the IETF Web Authorization Protocol Working Group to develop JSON Web Tokens (JWT)[2], a JSON-based method of exchanging claims or assertions between the client and RS. JWT is designed to be URL-safe, so it also works nicely in an HTTP Authorization header. JWT allows the RS to receive trustworthy (i.e. digitally signed) claims directly from the client without having to check them with the AS. So long as the signature is from the AS and valid, the claims in the JWT can be trusted. For example, the JWT might include the owner’s role, allowing the RS to use that claim in determining how to respond to the resource request. The RS could be assured that the role came from the AS, rather than merely being an assertion the owner or client were making unilaterally.

Using OAuth with Devices

Earlier I introduced Fuse, a connected-car project I lead. Fuse uses off-the-shelf OBD-II devices that have a cellular (1xRTT) connection. The devices are supplied by Carvoyant who also provides a cloud-based API that serves as the proxy for the device. The cellular connection provides its own means for connecting the physical device to Carvoyant. The devices are pre-provisioned with service on a virtual mobile network and that process provides the connectivity[3] back to Carvoyant.

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 vehicle data ends up on 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 is 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 provider’s and client developer’s 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 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 proxy. This is often necessary or at least desirable for reasons beyond access control such as inter-device coordination. Devices often have small microcontrollers, instead of full blown microprocessors and don’t have the memory or processing power to even parse a JSON object, let alone handle HTTP with TLS.

Furthermore, devices often don’t have displays making configuration and other interactions difficult. This 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’ve 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’ve already discussed the problems of low-powered devices not supporting Web browser based flows, but there’s 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 isn’t a problem for a connected device since the user doesn’t 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 re-grant access.

In the Web and mobile interactions envisioned by OAuth’s original framers, this wasn’t 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. Devices are often reacting to their environment. Consequently the user isn’t 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 this is happening in the background without human involvement. Consequently, if the refresh token fails, Fuse has no recourse except to notify the user using email or some other means that an access control problem occurred and they need to log in and fix it. In the meantime, Fuse is disconnected from the API and is unable to carry out the tasks the user expects it to. Note that this problem isn’t mitigated by the device having a proxy.

Connected-car scenarios also point to other problems with connected devices and OAuth’s dependence on a user being present. For example, what happens with Alice lets Bob borrow her car? How does she grant access to Bob? Can she limit what Bob can do? What happens when the device can’t communicate with the AS? These problems can be solved in a variety of ways, but if every device manufacturer solves them differently, we won’t create an interoperable Internet of Things.

In the case where both the device and the client are under the control of a single authority and trust each other, Hannes Tschofenig has proposed an extension to the OAuth Client Credential grant that uses CoAP and DTLS for connected devices. [7] In this scenario, the client uses client credentials (which are relatively stable compared to access tokens) to retrieve and access token from the AS. When the device API is queried, the device receives the access token from the request and validates it with the AS. If the access token is still valid, the device returns the desired data.

This solution leaves the user out of the access token grant process and so can’t be used when the client needs access to data on a user-by-user basis. In Fuse, for example, we wanted to preserve the ability of the car owner to invalidate Fuse’s access to the data from the car. Consequently, a client credential grant wasn’t appropriate.

Magically Working Together

Even with the preceding problems, OAuth still presents a viable solution to a lot of present-day Internet of Things challenges. Still, supporting a world where dozens or even hundreds of connected devices easily connect together to get things done for their owner will need more than what present-day OAuth is prepared to provide.

Mike Schwartz of Gluu calls this the “magically working together” problem. [8]. Schwartz uses the example of a connected light-bulb and light switch as shown in Figure 3. He says “If you buy a light switch and a light bulb, they need to magically work together.” In this scenario the light bulb is the RP and the switch is the client.

Getting connected devices to directly work together is difficult. Commercial connected lightbulb products like Philips Hue use a hub and a proprietary connection system. But it seems unlikely that any of us will be willing to buy all our light bulbs and switches from a single vendor, let alone every connected device we might ever own.

A more general solution would use a suite of standard protocols for managing the interactions that can be supported by devices operating alone or with a hub. OAuth could play a role if we overcome some of the obstacles that currently exist.

Tiered Access Control

One key idea in a flexible connected-product scenario is support for tiered access control with fallbacks[4]. Without tiered control and fallbacks, a deeply connected set of devices would be prone to failure through the tyranny of over-active access control whenever network connections fail or hubs go offline.

When all the devices are members of a trusted network, we may not need any access control. These situations are usually rare, especially where wireless networks and dynamic device situations are in play.

If the devices and clients are relatively static, then client credential access control may be appropriate. Client credentials are easy to set up and may be pre-provisioned. Transferring the credentials from one device to another during set up can be accomplished in a variety of ways. Once the device has the credentials, presuming they are not subject to disclosure, they can be used in a static environment indefinately to grant access to a device. This is essentially the same as giving each device a username and password.

OAuth tokens support devices and clients that come and go. As an owner uses new devices and applications, OAuth supports granting and denying access based on the owner’s whims. There is inconvenience, however, in the fact that each RS might have a different AS that the owner is responsible for tracking and interacting with.

Devices could be smart about falling back to less restrictive access control policies in order to ensure they work even if they’re not connected or the user’s phone isn’t charged. The fallback policy could be configurable to avoid situations where a security problem might result from falling back too far.

User Managed Access

When you have just a few things connected in only a few ways, keeping track of what device is sharing what data with who might not be easy, but creates only a small risk. As the number of devices and connections increases, however, this becomes a significant worry.

User Managed Access (UMA) is an emerging standard that can be thought of as OAuth++ because it adds two very important elements to OAuth [9]:

1. UMA specifies a formal protection API presented by the AS, so that RS’s running in different domains can be “authorization relying parties” to it. This feature allows an AS to be under the device owner’s control instead of the manufacturer’s. This AS serves as a central place for the owner to configure and control access policies for every device (and API) they control. Further this AS can make access decisions based on policies so that the owner doesn’t have to be present when access control decisions are made.

2. A formal recognition that the client may be under the control of someone, the requesting party, other than the resource owner. OAuth is sometimes called “Alice-to-Alice sharing” because the owner is sharing resources she owns with a clien she herself also controls. As an example of where sharing with other requesting parties is desirable, consider a guest room where the guest may be delegated control of devices in that room (and elsewhere in the house). Because OAuth doesn’t directly support clients under the control of requesting parties other than the resource owner herself, new protocols are needed to support this kind of scenario.

These elements may seem small, but they’re important for Internet of Things scenarios because they create significant flexibility and convenience. Managing hundreds of devices will be sheer drudgery if agents, like UMA’s AS, can’t work autonomously to allow access when appropriate and protect resources from misuse otherwise. The UMA AS serves as a virtual hub and could be built into physical devices like Apple’s HomeKit or Insteon controllers. These same controllers could also be built to serve as outsourced access control agents from another AS if the owner configures them that way.

The use of an AS that is separate from the RS greatly simplifies its implementation. The RS no longer has to know about users and access control policies (other than the fallback policies we discussed earlier). It simply asks the AS to validate the access token it receives from the client.

Similarly the work of the client (which might be another device as in the light-bulb-switch scenario) is simplified because it no longer needs to interact with access servers for each device individually and can outsource the user experience of requesting and granting access to the AS.

Specifically, UMA’s AS formalizes these interactions between the client, the RS, and the AS in places that OAuth leaves them unspecified, removing a significant amount of uncertainty about interaction. This makes building complying devices simpler and improves the life of the owner since she doesn’t need to learn and use new, ad hoc access control systems for each new device.

Conclusion

OAuth provides a good tool for managing access in connected devices even though it was originally designed for Web interactions. The OAuth credenential grants that are part of the original specification make assumptions about the client, the RS, and the AS that are often not true of connected devices such as support for Web browsers and HTTP redirects.

Even so, developers and engineers have found ways to adapt OAuth flows to connected-device situations through the use of proxies and by stretching some of the original concepts. But these adaptations are just stop-gap measures that won’t support more generalized scenarios with multiple devices, much less the hundreds of connected devices from dozens of different manufacturers envisioned in a true Internet of Things.

Emerging standards like UMA and OpenID Connect will play a key role in allowing devices to more easily work together. Other standards such as CoAP, DTLS, and MQTT will provide lighter-weight connectivity for devices with limited processing power. Together these protocols create an environment where rich inter-device connections and relationships are routine. These standards will continue to evolve and new standards will emerge as the boundaries are pushed further and further by our need to connect more things to each other.

UMA’s support for an owner-controlled AS and ability to outsource authorization decisions to other AS services is an important development for building an Internet of Things that puts the owner in charge of her data and how it is shared. Such support is a vital element for supporting owner control and privacy.

References

[1] Victor Ake, Identity Relationship Management in the Internet of Things, December 9, 2014 https://forgerock.org/2014/12/irm-iot/

[2] Dick Hardt (Ed.), IETF RFC 6749: The OAuth 2.0 Authorization Framework, October 2012, http://tools.ietf.org/html/rfc6749

[3] N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore, OpenID Connect Core 1.0 Incorporating Errata Set 1, November 8, 2014, http://openid.net/specs/openid-connect-core–1_0.html

[4] Andrew,Banks and Rahul Gupta (Eds.), MQTT Version 3.1.1, October 29, 2014, http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

[5] Z. Shelby, K. Hartke, and C. Bormann (Eds.), The Constrained Application Protocol, June 2014, https://tools.ietf.org/html/rfc7252

[6] E. Rescorla and N. Modadugu (Eds.), Datagram Transport Layer Security, Version 1.2, January 2012, https://tools.ietf.org/html/rfc6347

[7] H. Tschofenig (Ed.), The OAuth 2.0 Internet of Things (IoT) Client Credentials Grant, March 2015, https://tools.ietf.org/html/draft-tschofenig-ace-oauth-iot–01

[8] Michael Schwartz, OAuth2 for IoT?, November 20, 2014, http://www.gluu.org/blog/oauth2-for-iot/

[9] H. Tschofenig, E. Maler, E. Wahlstroem, and S. Erdtman, Authentication and Authorization for Constrained Environments Using OAuth and UMA, March 9, 2015, https://tools.ietf.org/id/draft-maler-ace-oauth-uma–00.txt

About the Author

Phillip J. Windley, Ph.D. is an Enterprise Architect in the Office or the CIO at Brigham Young University (BYU). He is also an Adjunct Professor of Computer Science at BYU where he teaches courses on digital identity and large-scale distributed systems. Phil is the co-founder and organizer of the semi-annual Internet Identity Workshop. He is also the author of the books The Live Web published by Course Technology in 2011 and Digital Identity published by O’Reilly Media in 2005.

Portions of this article are excerpted from an upcoming second edition of Digital Identity.

---

Last Modified: Tuesday, 11-Aug-2015 20:08:35 UTC