Federated Identity for IoT with OAuth2
9 likes5,722 views
This document discusses using OAuth2 for federated identity and access management with IoT devices that use MQTT. It provides an overview of federated identity and access management (FIAM) and OAuth2, and why they are suitable for IoT. It then demonstrates using OAuth2 to authenticate an Arduino device that publishes sensor data to an MQTT broker. The demo shows the device obtaining and refreshing access tokens to connect and publish, while a Python client subscribes to the data. Lessons learned and next steps are discussed.
![Step
1.
Get
a
token
• Simple
python
script
and
web
browser
• Encodes
the
requested
permission
“scopes”
as
b64
encoded
JSON
(ugly
but
works!)
• scope
=
'[{"rw":"w","topic":"/pzf/#"}]’
• IdP
=
WSO2
Iden*ty
Server
–
open
source
Oauth
server
• Redirects
to
a
localhost
server
which
prints
the
code](https://image.slidesharecdn.com/federatedidentityforiot-140202050322-phpapp01/85/Federated-Identity-for-IoT-with-OAuth2-14-320.jpg)
Federated Identity for IoT with OAuth2
- 1. Federated Iden*ty for IoT with OAuth Paul Fremantle CTO, WSO2 (paul@wso2.com) PhD researcher, Portsmouth University (paul.fremantle@port.ac.uk) @pzfreo
- 2. How this will work • Quick intro to Federated Iden*ty and Access Management • Even quicker introduc*on to OAuth2 • MQTT overview • Demo • Issues • Next steps
- 4. What is Federated Iden*ty and Access Management (FIAM)? Federated IAM aims to give You control over your creden*als and access: • You don’t give your userid/pw to anyone • You control the grant of permissions • LinkedIn example • OAuth2 emerging as widely used approach
- 5. Why FIAM for IoT? • Your device = Your data • Tokens are beYer than u/p for devices • Manage tokens and scopes independently of the device
- 6. Tokens
- 7. Why OAuth2? • Widely implemented • PreYy good – Of course there is never 100% agreement – Or certainty with security protocols • Not just HTTP: – hYp://tools.ie^.org/html/dra_-‐ie^-‐kiYen-‐sasl-‐ oauth-‐12 – OAuth2 used with SSL
- 9. MQTT
- 10. MQTT • Very lightweight messaging protocol – Designed for 8-‐bit controllers, SCADA, etc – Low power, low bandwidth – Binary header of 2 bytes – Lots of implementa*ons • MosquiYo from Eclipse • Apache Ac*veMQ and Apollo – Clients: • Arduino, Perl, Python, PHP, C, Java, JS/Node.js, .Net, etc • Plus an even lighter-‐weight version for Zigbee – MQTT-‐SN (Sensor Network)
- 12. CreateToken.py Demo components 1 Refresher.py 2 Arduino 3 5 4 MosquiYo (Open Source MQTT Broker) Ac*ng as “Resource Server” MosquiYo_py_auth mqY-‐oauth2.py IdP WSO2 Iden*ty Server 6 ESB Introspec*on API
- 13. Demo steps 1. Get an access-‐token / refresh-‐token 2. Encode it into the Arduino code, compile, burn 3. Reboot Arduino 4. Arduino tries access token 5. Arduino connects as “refresh user” and requests refresh token • 6. Arduino receives updated access token and reconnects • 7. Arduino starts to publish data (assuming it is allowed!) • 8. Python client receives data using a previously authorized token • • • • •
- 14. Step 1. Get a token • Simple python script and web browser • Encodes the requested permission “scopes” as b64 encoded JSON (ugly but works!) • scope = '[{"rw":"w","topic":"/pzf/#"}]’ • IdP = WSO2 Iden*ty Server – open source Oauth server • Redirects to a localhost server which prints the code
- 15. Step 2. Burn into Arduino • LiYle program burns into EEPROM
- 16. Step 3, 4, 5, 6 Recode Arduino with App • App tries access token to CONNECT • If fails, retries as user “r” (refresh) – Ideally this would be a separate server / IdP-‐based broker • Sends {clien*d, refresh_token} to topic /r • Subscribes to /c/{clien*d} • When new access_token arrives, saves in EEPROM and reconnects
- 17. Step 7. Arduino publishes data • MPU 9150 • Yaw, Pitch, Roll • Every publish is validated against the IdP – Should be cached by the resource server
- 18. Step 8. Python client subscribes • Subscriber.py
- 19. Lessons learnt • MQTT and MPU / I2C code is 97% of Duemilanove – Adding the final logic to do OAuth2 flow pushed it to 99% – No TLS in this demo is a big issue • Different Oauth implementa*ons behave differently (e.g. changing the refresh token every *me you refresh) • Need to be able to update the scope of token if this will work for long term embedded devices • The refresh flow should not really go via the Resource server – Easy fix • MQTT should have a well defined model for sending a message to just one client (securely)
- 20. Next steps • • • • • Do the same for CoAP / other IoT protocols Implement solidly J Gain agreement on the specific MQTT Other FIAM approaches for IoT? Please feel free to contact me: – @pzfreo – paul@wso2.com
- 21. Ques*ons?