IoT Wonderland: Understanding the Magic of OAuth2 Device Registration Flow
-
Upload
forgerock -
Category
Technology
-
view
283 -
download
1
Transcript of 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
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
Copyright © 2016 ForgeRock, all rights reserved.
OAUTH2 BASIC IDEA
REGISTERED
APPLICATION
REGISTERED USER
AGFA
APPLICATION
RESOURCE SERVER
AUTHZ SERVER
Copyright © 2016 ForgeRock, all rights reserved.
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
Copyright © 2016 ForgeRock, all rights reserved.
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/
Copyright © 2016 ForgeRock, all rights reserved.
OAUTH2 BRIEF HISTORY (CONT)
https://hueniverse.com/2010/05/15/introducing-oauth-2-0/
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
Copyright © 2016 ForgeRock, all rights reserved.
OAUTH2 DEVICE FLOW
https://hueniverse.com/2010/05/15/introducing-oauth-2-0/
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
Copyright © 2016 ForgeRock, all rights reserved.
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
Copyright © 2016 ForgeRock, all rights reserved.
OAUTH2 DEVICE FLOW +----------+ +----------------+ | |>---(A)-- Client Identifier --->| | | | | | | |<---(B)-- Verification Code, --<| | | | User Code, | | | | & Verification URI | | | Device | | | | Client | Client Identifier & | | | |>---(E)-- Verification Code --->| | | | polling... | | | |>---(E)-- Verification Code --->| | | | | Authorization | | |<---(F)-- Access Token --------<| Server | +----------+ (w/ Optional Refresh Token) | | v | | : | | (C) User Code & Verification URI | | : | | v | | +----------+ | | | End-user | | | | at |<---(D)-- User authenticates -->| | | Browser | | | +----------+ +----------------+
Copyright © 2016 ForgeRock, all rights reserved.
DEMO
NodeMCU
Twillio (Wrapper)
OpenIG
OpenAM
Trust established
API Gateway
Copyright © 2016 ForgeRock, all rights reserved.
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)
Copyright © 2016 ForgeRock, all rights reserved.
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
Copyright © 2016 ForgeRock, all rights reserved.
SECURITY CONCERNS
Token is a Bearer token Device might not be able to process a TLS layer Device has ClientID / ClientSecret
Copyright © 2016 ForgeRock, all rights reserved.
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