Identity for IoT: An Authentication Framework for the IoT

AN AUTHENTICATION
FRAMEWORK FOR THE IOT
John Bradley
Copyright © 2014 Ping Identity Corp.All rights reserved. 1

Premise
•  The full promise of the Internet of Things (IoT) can only be
realized if the many and varied interactions between users,
things, cloud services and applications can be authenticated.
•  User delegated consent will be necessary for any scenario
where potentially privacy sensitive data is collected and
transferred (wearables, home automation, health, etc).
•  OAuth 2.0 and OpenID Connect 1.0 are two authentication
and authorization standards that promise to serve as important
tools for the IoT’s authentication and authorization
requirements

Who are the actors
• Things/devices
• Users
• Applications
• Clouds
• Gateways

Who are the actors
• Things/devices
• Users
• Applications
• Clouds
• Gateways
All of which
need to be
authenticated

Authentication & Authorization Model
•  IoT Actors authenticate by presenting security tokens on their calls/messages
to each other
•  Tokens represent relationship between the relevant user and the calling actor
(and any consents/permissions associated with that relationship
•  Upon receiving a message, an actor validates the token to verify the request
is consistent with the relationship/permissions
•  If consent is removed, token is revoked, and access disabled
•  OAuth 2.0 & OpenID Connect 1.0 are two authentication & authorization
frameworks that enable this model

OAuth 2.0
•  OAuth 2.0 is an IETF standard authentication & authorization framework for
securing application access to RESTful APIs
•  OAuth allows a Client (an application that desires information) to send an API
query to a Resource Server (RS), the application hosting the desired
information, such that the RS can authenticate that the message was indeed
sent by the Client.
•  The Client authenticates to the RS through the inclusion of an access token on
its API call—a token previously provided to the Client by an Authorization
Server (AS).
•  In those scenarios that the API in question protects access to a User’s identity
attributes, it may be the case that the access token will only be issued by the AS
after the User has explicitly given consent to the Client accessing those
attributes.

OpenID Connect 1.0
•  OpenID Connect 1.0 is an OIDF standard that profiles and extends OAuth 2.0 to add
an identity layer—creating a single framework that promises to secure APIs, mobile
native applications and browser applications in a single, cohesive architecture.
•  OpenID Connect adds two notable identity constructs to OAuth’s token issuance
model.
–  An identity token—the delivery of which, from one party to another, can enable a
federated SSO user experience for a user.
–  A standardized identity attribute API—at which a client can retrieve the desired identity
attributes for a given user.
•  If your use case requires something more than authentication and authorization of
API calls, Connect’s features that go beyond OAuth become relevant.

Representative IoT architecture
• Fitbit makes Aria smart scale
• Scale syncs through home Wifi to
Fitbit cloud for display & analysis
through web & native applications
• 3rd party services can access
weight data to provide additional
insight

Architecture requirements
• User weight data is personal and must be protected
against compromise
• Additionally, weight data must only be shared by
Fitbit when consistent with user policy

Architecture
FitBit
Proprietary
3rd party
services
REST API
REST API

Architecture
FitBit
Proprietary
3rd party
services
REST API
REST API
Lets examine how OAuth &
Connect can apply here

Cloud to cloud
•  TrendWeight offers additional
insight & analysis of weight data
•  Pulls scale data from Fitbit cloud
REST endpoints
•  TrendWeight should use OAuth to
authenticate their API calls as
being on behalf of particular user
•  Because user is involved in token
issuance, privacy enabling model

Cloud to Cloud
Login & consent
Weight data

Revocation of authorization
User can remove permissions
assigned 3rd parties

Native Application
•  Users can view their weight data
& trends from ioS & Android
native applications
•  Native applications pull data from
Fitbit cloud REST endpoints
•  Native applications should use
OAuth to authenticate their API
calls as being on behalf of
particular user

Device to gateway
•  Devices communicate with each other and the gateway via the
local network— sharing data, sending control messages, etc.
•  These local interactions may not use HTTP, but instead a
application protocol more optimized to the constraints (CPU
size, battery, etc.) of devices.
•  Such application protocols include XMPP, MQTT and CoAP.
•  Work has begun in exploring how to bind OAuth & Connect to
such IoT optimized protocols, e.g.ACE effort in IETF

Conclusion
• Authentication & authorization of actors is
fundamental to IoT security
• Mechanisms must be secure, scalable and privacy
respecting
• OAuth & Connect promise to provide important
pieces of authn & authz framework for IoT

Identity for IoT: An Authentication Framework for the IoT

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Identity for IoT: An Authentication Framework for the IoT

Similar to Identity for IoT: An Authentication Framework for the IoT (20)

More from AllSeen Alliance

More from AllSeen Alliance (20)

Recently uploaded

Recently uploaded (20)

Identity for IoT: An Authentication Framework for the IoT