iot wonderland: understanding the magic of oauth2 device registration flow

FORGEROCK @forgerock

IDENTITY CAFE COME AND TASTE THE

AND ITS APPLICATION

ABOUT

Me (@steffoweber) ▪ 10yrs at Sun Microsystems, some at Oracle (Security, OS, WebServices, Identity) ▪ Lead for Customer Engineering at ForgeRock

ForgeRock (www.forgerock.com www.forgerock.org) ▪ Identity & Access Management (full platform) ▪ San Francisco based (coming from Oslo – Engineering in Bristol, Grenoble and

Vancouver VA) ▪ Open Source ▪ 400 Employees (world wide) ▪ BBC, Tom Tom, Thomson Reuters, Vodafone, Toyota, BinckBank and more

http://www.forgerock.com

http://www.forgerock.org

Copyright © 2016 ForgeRock, all rights reserved.

OAUTH2 MOTIVATION

Motivation ▪ sharing data between applications ▪ it’s about authorization (can I access the data on your behalf?)

XACML ▪ Policy language AND query language ▪ Fine grained (Who,What,How,When) vs OAuth scopes ▪ Can be combined at RS and AZ

NODE MCU


OAUTH2 BASIC IDEA

REGISTERED

APPLICATION

REGISTERED USER

AGFA

INSTAGRAM

APPLICATION

RESOURCE SERVER

AUTHZ SERVER


OAUTH2 BRIEF HISTORY

2006 ▪ Ma.gnolia needed solution for authorization (AuthZ) ▪ Twitter began implementation of OpenID ▪ Foundation of OAuth discussion group

2007 ▪ OAuth Core 1.0 final draft released

2008 ▪ IETF workgroup on OAuth

2009 ▪ Security flaw discovered in 3-legged OAuth

6


OAUTH2 BRIEF HISTORY (CONT)

7

2010 ▪ All Twitter apps require OAuth ▪ OAuth standard published as RFC 5849 ▪ Start work on OAuth2 (effect 2009)

‣ Not backward compatible ‣ OAuth 1.x implementations often failed due to complexity of the

cryptographic requirements ‣ Only one flow (started w 3 but then merged into 1) - ok for web apps, but

failed elsewhere ‣ Difficult to scale because requests are signed and RS endpoint needs

token_secret to verify access token.

https://hueniverse.com/2010/05/15/introducing-oauth-2-0/


OAUTH2 BRIEF HISTORY (CONT)


2012 ▪ OAuth2 published ▪ Google & Facebook starting rollout ▪ OAuth2 now a complete Bearer framework; TLS as sole protection layer

2014 ▪ OpenID Connect published as OAuth2 profile

2015 ▪ UMA (User Managed Access) published as OAuth2 profile ▪ OAuth2 for devices flow

2016 ▪ PoP (Proof of Posession) tokens


OAUTH2 DEVICE FLOW


Around 2010 ▪ OAuth Drafts had reference to Device Flow (https://tools.ietf.org/html/draft-ietf-oauth-

v2-06#section-2.7) ▪ Google and Facebook had an early implementation

2015 ▪ Companies like the BBC and European Broadcasting (EBU) began showing interest ▪ EBU drafted their own standard (outside the IETF body of standards) as part of ETSI

(http://www.etsi.org/deliver/etsi_ts/103400_103499/103407/01.01.01_60/ts_103407v010101p.pdf)

▪ OpenAM contained an IdP independent implementation 2016 and later ▪ IoT made the device flow important again

https://tools.ietf.org/html/draft-ietf-oauth-v2-06#section-2.7

https://tools.ietf.org/html/draft-ietf-oauth-v2-06#section-2.7

http://www.etsi.org/deliver/etsi_ts/103400_103499/103407/01.01.01_60/ts_103407v010101p.pdf




OAUTH2 DEVICE FLOWWhat’s the issue w restricted devices (which sometime cannot even have a simple HTTP srv)? ▪ OAuth2 flow:

‣ User accesses OAuth2 Client Service ‣ Client redirects user to OAuth2 AuthZ Server (this would at least require a medium sized display on the

Client) ‣ User has to authorize client req. AuthZ server typically asks user to sign-in (this would at least require an

input device at the client) ▪ Clients [remember client consumes a service on the user’s behalf]: TVs, Radios, Vacuum Cleans, Alarm Systems

2015 ▪ Companies like BBC and European Broadcasting (EBU) began showing interest ▪ EBU drafted their own standard (outside the IETF body of standards) ▪ OpenAM contained an IdP independent implementation

2016 and later ▪ IoT made the device flow important again


DEMO

NodeMCU

Twillio (Wrapper)

OpenIG

OpenAM

Trust established

API Gateway


DEMOAlarm System

(NodeMCU)

1.User leaves home and activates alarm.

2.To activate alarm, user types or scans code displayed by alarm system. This requires consent to access phone number

3.Alarm system now has an access token

4.If alarm system detects an incident, the system calls a webservice which requires an OAuth2 access token.

5.Webservice can access phone number (scope) and call the user.

http.get(https://twilliowrapper.io/call, 'Authorization: Bearer ‘..accessToken..’\r\n', callback)


DEMOAlarm System

(NodeMCU)

1.User leaves home and activates alarm.

2.To activate alarm, user types or scans code displayed by alarm system. This requires consent to access phone number

3.Alarm system now has an access token

4.If alarm system detects an incident, the system calls a webservice which requires an OAuth2 access token.

5.Webservice can access phone number (scope) and call the user.

http.get(https://twilliowrapper.io/call, 'Authorization: Bearer ‘..accessToken..’\r\n', callback)

This is NodeMCUs serial output


SECURITY CONCERNS

Token is a Bearer token Device might not be able to process a TLS layer Device has ClientID / ClientSecret


SUMMARY

OAuth2 Device Flow can be used to ▪ pair a device w a user ▪ grant a restricted device access on user’s behalf ▪ protect service APIs in an OAuth2 manner

Try it out? ▪ www.forgerock.org/downloads ▪ Device simulator: github.com/smof/deviceEmulator

http://www.forgerock.org/downloads

iot wonderland: understanding the magic of oauth2 device registration flow

Technology