IEEE Consumer Electronics Magazine - July 2015 - 55

Google, Facebook, or Twitter, you have 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, and the owner can decide whether to agree.
The specifics of the interaction call for the AS to redirect the
owner back to the client via a URL supplied by the 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 previously, the
implicit grant flow redirects the owner to the AS where he or she
signs in and explicitly grants permission 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 who 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 antipattern we discussed previously, in the resource owner credentials grant, the client does not
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 suboptimal, the fact that it
does not rely on Web redirection makes it quite suitable for connected devices that do not 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 the 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 in situations where some resources on the RS are considered public but the RS needs to limit access and ensure that only
clients known to the RS are accessing the resource.

REFRESH TOKENS
Access tokens may have a time to live. When they 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 to the AS. As a result, the RS cannot 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, and 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.
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 under way in the Internet Engineering Task Force
Web Authorization Protocol Working Group to develop JSON
Web tokens (JWTs) (see the JWT draft at http://self-issued.
info/docs/draft-ietf-oauth-json-web-token.html for more information), a JSON-based method of exchanging claims or assertions between the client and the 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 is 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 that the
owner or client was 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,
which also provides a cloud-based API that serves as the
proxy for the device. The cellular connection provides its
july 2015

IEEE Consumer Electronics Magazine

http://self-issued

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