IEEE Consumer Electronics Magazine - July 2015 - 54

Granular permissions are hard to support since the RS
does not 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 RS part of the flow that delegates access. Consequently, the RS 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.
▼

One of the reasons OAuth is an
important building block for the
IoT is because it supports access
control by an owner.
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 are shared and with
what application.
The remainder of this article will examine how OAuth
works, catalog its fitness for its purpose as an access control
mechanism for the IoT, and explore the 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 it needs to access Site A on her behalf. By using
Alice's username and password, Site B would demonstrate that it
had Alice's implicit permission to access her account on Site A.
This is sometimes called the password antipattern.
The password antipattern has serious drawbacks:
▼ The resource server (RS) (i.e., the server hosting the API)
cannot differentiate between the user and other servers
accessing the API.
▼ Passwords stored at other servers increase the risk of a
security breach.

Owner

1) Use
Client

3) Authorize

2) Redirect

Authorization
Server

4) Code
5) Code
6) Token

10) Data
7) Request
Token

OAuth BASICS
OAuth is a protocol for access control. As such, it defines the
interactions among several actors who play specific roles (see
Figure 2). (Throughout this document, when we talk about
"OAuth," we'll be referring to the newer OAuth 2.0 protocol,
not OAuth 1.0a. You will still run into OAuth 1.0a-protected
APIs from time to time. OAuth 1.0a should not be considered
for new developments.)
The central figure in these interactions is the resource
owner. The owner is the actor, almost always a human, who
controls client access to resources. One of the reasons OAuth
is an important building block for the IoT is that it supports
access control by an owner.
The owner has resources on an RS, and the RS 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 AS 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 is a little of
both. The OAuth specification does not specify the structure of
the tokens, and there is not necessarily any identifying information in the token. Furthermore, the resource being accessed
might or might not have identity information, and OAuth does
not 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
and 2) using a token. We will discuss each of these in turn.

GETTING A TOKEN

9) Okay Token
8) Validate
Get
Resource
Server

Use

FIGURE 2. OAuth interactions for getting (green) and using
(blue) an access token.
54 IEEE Consumer Electronics Magazine

july 2015

To get an access token, the client interacts with an AS. There
are four ways to do this. They are 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 have ever signed into a Web site with

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