The document discusses authorization for internet of things devices using OAuth 2.0. It outlines design patterns like backend data portability and device-to-device communication. It then describes the architecture involving clients, authorization servers, resource servers, and devices. Finally, it provides an overview of relevant standards organizations and technologies like OAuth, COSE, OpenID Connect, and FIDO that can help address IoT security challenges.

1. Authorization
for Internet of Things
using OAuth 2.0
Samuel Erdtman
samuel.erdtman@nexusgroup.com
Hannes Tschofenig
hannes.tschofenig@arm.com

2. © TechCon20152
Agenda
 Design Patterns
 Architecture
 Technology Big Picture
 Demo
 Summary

3. © TechCon20153
Design Patterns
 A design pattern is a general reusable solution to a commonly
occurring problem.
 A few design patterns have emerged in the IoT space, as
described in RFC 7452 and recent Internet Society IoT
whitepaper.

4. © TechCon20154
Backend Data Portability
 Devices upload data to the cloud operated by a specific vendor.
 Backend data sharing of protected data via OAuth-alike mechanisms and
RESTful APIs.
https://developer.carvoyant.com/page
http://www.mapmyfitness.com/

5. © TechCon20155
 Device talks directly to other device (often smart phone).
Security based on direct relationship between the device
(pairing).
Vendor A Vendor BE.g. Bluetooth Smart,
Thread
Device-to-Device Communication

6. © TechCon20156
Examples
Wahoo Heart-Rate
Monitor
Beacons
Cadence Sensor
Parrot
Hearing Aid

7. © TechCon20157
What if?
 IoT devices need to be accessed by multiple users
securely?
 Access rights dynamically change?
 Access rights are fine-grained?
 Number of IoT devices is large?
 Access policies need to be managed centrally?
 Access rights can be delegated?
 System has to be integrated in a larger context
(e.g., other, existing identity management
infrastructures)

8. Architecture

9. © TechCon20159
Client
Authorization
Server
Resource
Device
Management
Server
Response
Request
Token
Token
Client Info

10. © TechCon201510
HMAC-SHA256 (AS-RS Key)HMAC-SHA256 (PoP Key)
Request Example
Head
Body
{
“action” : “open”
}
Head
{
“alg” : “HMAC-SHA256”
“exp” : “1300819380”
“iv” : “<iv>”
}
Body
{
“scope” : “open”,
“audience” : “door lock foo-bar”,
“key” : “<encrypted key”>
}
{
“alg” : “HMAC-SHA256”,
“token” : “<access token>”,
“timestamp” : “1300919380”
}
Request Access Token

11. Technology Big Picture

12. © TechCon201512
ACE WG
 Authentication and Authorization for Constrained Environments
(ace) aims to standardize solutions for interoperable security for
IoT.
 Relevant documents:
 IoT Use Cases – draft-ietf-ace-usecases
 OAuth 2.0 Profile for IoT – draft-seitz-ace-oauth-authz
 Charter: http://datatracker.ietf.org/wg/ace/charter/

13. © TechCon201513
OAuth WG
 Authorization protocol widely used on the Web and on smart
phones.
 Core OAuth 2.0 functionality specified in RFC 6749
 Charter: https://tools.ietf.org/wg/oauth/
 Proof of Possession Security Extension
 Architecture – draft-ietf-oauth-pop-architecture
 Key Distribution – draft-ietf-oauth-pop-key-distribution
 JSON Web Token (JWT) – RFC 7519
 JWT Key Claim – draft-ietf-oauth-proof-of-possession
 Browser views allow for a secure browser context inside the native
app now available for Android and IOS
(described in draft-wdenniss-oauth-native-apps).
Example code available for Android and IOS.

14. © TechCon201514
COSE WG
 Concise Binary Object Representation (CBOR), RFC 7049,
defines an efficient binary encoding based on the JSON data
model.
 CBOR Object Signing and Encryption (COSE) offers security
services for CBOR-based structures.
 Functions:
 Signing, Encryption, Key Exchange, and Key Representation
 Charter: https://datatracker.ietf.org/wg/cose/charter/

15. © TechCon201515
OpenID Connect
 Builds on OAuth 2.0 and provides support for federated login
and the ability to convey authentication information.
 Organization offers self-certification program.
 Work done in working groups, such as the Heart working group.
 Main specifications can be found at
http://openid.net/developers/specs/
 Additional information about the organization can be found at
http://openid.net

16. © TechCon201516
UMA
 User Managed Access (UMA)
 OAuth-based protocol designed to give users a unified control
point for authorizing who and what can get access to their data
and devices.
 Separates resource owner from requesting party.
 More information available at:
http://kantarainitiative.org/confluence/display/uma/Home

17. © TechCon201517
OMA LWM2M
 Lightweight Machine-to-Machine Communication (LWM2M)
 http://openmobilealliance.org
 Specification available for download at
http://technical.openmobilealliance.org/Technical/technical-
information/release-program/current-releases/oma-
lightweightm2m-v1-0
 Functionality:
 Device management
 Key Provisioning
 Firmware Updates

18. © TechCon201518
FIDO
 The FIDO (Fast IDentity Online) Alliance was formed in July
2012 to address the lack of interoperability among strong
authentication technologies, and remedy the problems users
face with creating and remembering multiple usernames and
passwords.
 Specifications at https://fidoalliance.org/specifications
 Universal Second Factor (U2F) protocol
 Universal Authentication Framework (UAF) protocol
 More info about the alliance, certification programs and tutorials
at https://fidoalliance.org

19. Demo

20. © TechCon201520
Technologies used in Demo Setup
 OAuth 2.0 & Extensions
 OAuth 2.0 Proof of Possession
 OAuth 2.0 IoT profile
 JSON Web Token (JWT)
 Bluetooth Smart
 ARM mbed
 Android app
Nordic nRF51-DK

21. © TechCon201521

22. © TechCon201522
Summary
 There are ongoing standardization efforts. Help us make the
specifications better.
 Technologies and eco-systems can be re-used to solve IoT
security challenges.
 Code is available. We are planning to add more to make
development easier.