IoT Wonderland: Understanding the Magic of OAuth2 Device Registration Flow
0 likes1,000 views
The document discusses OAuth 2.0 device flow, which allows restricted devices like IoT devices to obtain access tokens to access APIs on a user's behalf. It describes how device flow works, the issues it addresses for devices without browsers, and its history. It then demonstrates device flow in an example where an alarm system uses an access token obtained via device flow to call a web service and notify the user if an incident occurs. Security concerns with device flow like use of bearer tokens on non-TLS devices are also noted.
![Copyright © 2016 ForgeRock, all rights reserved.
OAUTH2 DEVICE FLOW
What’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](https://image.slidesharecdn.com/iotwonderland-170609104313/85/IoT-Wonderland-Understanding-the-Magic-of-OAuth2-Device-Registration-Flow-10-320.jpg)
IoT Wonderland: Understanding the Magic of OAuth2 Device Registration Flow
- 1. FORGEROCK @forgerock IDENTITYCAFE COME AND TASTE THE AND ITS APPLICATION
- 2. 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
- 3. 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
- 4. NODE MCU
- 5. Copyright © 2016 ForgeRock, all rights reserved. OAUTH2 BASIC IDEA REGISTERED APPLICATION REGISTERED USER AGFA INSTAGRAM APPLICATION RESOURCE SERVER AUTHZ SERVER
- 6. 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
- 7. 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/
- 8. 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
- 9. 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
- 10. Copyright © 2016 ForgeRock, all rights reserved. OAUTH2 DEVICE FLOW What’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
- 11. 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 | | | +----------+ +----------------+
- 12. Copyright © 2016 ForgeRock, all rights reserved. DEMO NodeMCU Twillio (Wrapper) OpenIG OpenAM Trust established API Gateway
- 13. Copyright © 2016 ForgeRock, all rights reserved. DEMO Alarm 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..’rn', callback)
- 14. Copyright © 2016 ForgeRock, all rights reserved. DEMO Alarm 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..’rn', callback) This is NodeMCUs serial output
- 15. Copyright © 2016 ForgeRock, all rights reserved. SECURITYCONCERNS Token is a Bearer token Device might not be able to process a TLS layer Device has ClientID / ClientSecret
- 16. 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