RESTful services and OAUTH protocol in IoT

RESTful services and OAUTH protocol in IoT by Yakov Fain, Farata Systems

Farata Systems and SuranceBay surancebay.com faratasystems.com

The three parts of this presentation • One approach to integrating consumer devices in the business workﬂow • Live demo: integrating a blood pressure monitor into a business workﬂow • A brief review of REST, OAUTH, Websockets and their roles tin our application.

Yesterday’s Sensors (Things) • 18 years ago. Telephony. • I’ve been programming IoT!

Today’s Sensors  SCIO: a molecular sensor that scans physical objects and receives instant information to your smartphone. http://www.consumerphysics.com/

Tomorrow: Streachable Wearables  epidermal electronics Source: http://bit.ly/1uu0srr

A thing is an app + an API + a Web site.

Smartphone  app Device  Manufacturer’s  Server Device A Typical Consumer Device Setup Bluetooth or NFC MQTT, CoAp, … MQTT, CoAp, …

Low-Level IoT Approach Learn and implement IoT protocols: MQTT, XMPP, AMQP, CoAp,… Write Java programs for Raspberry Pi or Arduino  Learn HomeKit and HealthKit from Apple

High-Level IoT Approach Create applications using standard technologies to integrate things into an existing business workﬂow.

A Proof of Concept App • Integrate consumer devices into one of the insurance business workﬂows • Leverage existing software technologies • Create a standard-based application layer that connects things

Your Server in the Middle • Create a software layer as a proxy for all communications with IoT devices. • Find the use-cases for data-gathering devices in your business applications. • Collect the valuable data from devices for analisys. Java dominates on the middleware market.

The Use Case: Integrating Scale and Blood Pressure Monitor  into insurance workﬂow IHealthLabs Blood  Pressure Monitor Fitbit Scale  Aria

Medical Examiner’s Report Removing Manual Entry

DeviceVendor.com XYZ protocol XYZ protocol A Typical IoT Workﬂow

A Typical IoT Workﬂow XYZ protocol XYZ protocol We’re not dealing with XYZ    Our server communicates with the vendor’s server   using HTTPS  DeviceVendor.com

Integrating With Fitbit Scale: Take 1. ﬁtbit.com My Front-End App HTTP/Rest API Weight:

Integrating With Fitbit Scale: Take 2. ﬁtbit.com HTTP/Rest API Weight: My Front-End App My Server Polling/Pub-SubData push via WebSocket

Integrating With Fitbit and iHealthLabs. ﬁtbit.com Weight: iHealthLabs.com HTTP/  Rest API Blood Pressure: HTTP/Rest API Data push via WebSocket My Front-End App My Server

Adding OAuth Authentication ﬁtbit.com Weight: iHealthLabs.com HTTP/  Rest API Blood Pressure: HTTP/Rest API My Front-End App My Server Data push via WebSocket Secret, key, tokens from each vendor are here

The Final Architecture ﬁtbit.com Weight: iHealthLabs.com HTTP/  Rest API Blood Pressure: HTTP/Rest API My Front-End App My Server Data push via WebSocket - Vendor’s consumer app Secret, key, tokens from each vendor are here

What’s used in our app • RESTful Web services • OAuth authentication and authorization • WebSocket protocol • Front end: written in Dart, deployed as JavaScript • Data exchange format: JSON • Back-end: Java with Spring Boot and embedded Tomcat • Build automation: Gradle

© 2015 Farata Systems HTTP Request and Java EE Rest Endpoint A sample client’s HTTP request: “https://iHealthLabs.com:8443/iotdemo/ihealth/bp" // Configuring The App @ApplicationPath(“iotdemo") public class MyIoTApplication extends Application {  }

© 2015 Farata Systems HTTP Request and Java EE Rest Endpoint // Receiving and handling blood pressure on our server @Path("/ihealth")  public class BloodPressureService { // … // The method to handle HTTP Get requests @GET @Path("/bp")  @Produces(“application/json")  public String getBloodPressureData() { // The code to get bp and prepare JSON goes here   return bloodPressure;  } } A sample client’s HTTP request: “https://iHealthLabs.com:8443/iotdemo/ihealth/bp" // Configuring The App @ApplicationPath(“iotdemo") public class MyIoTApplication extends Application {  }

© 2015 Farata Systems A Rest Endpoint in Spring Framework // The endpoint handling blood pressure @RestController  @RequestMapping("/ihealth")  public class HealthLabsController { // … // The method to handle HTTP Get requests @RequestMapping(value="/bp", method = RequestMethod.GET,  produces = "application/json")  public Measurement getBloodPressureData() { // The code to get blood pressure goes here   return bloodPressure;  } }

OAuth 2 Authorizing an app to act on behalf of the user

Authorization and Authentication • Authentication: Is the user who he says he is? • Authorization: Which resources the user can access? The owner of the Blood Pressure Monitor can see only the measurments taken from his device.

The OAuth Players • The User • The client app that accesses the user’s resources • The server with the user’s resources (data) • The authorization server

Delegating Authorization to 3rd Party Servers

Bad Delegating Authorization Good

OAuth 2 Access Token A client app needs to aquire an access token that can be used on behalf of the user.

Typical OAuth 2 Workﬂows • A client app is located on the user’s device • A client app is located on the server (our use case)

iHealthLabs Authorization (our   server) GUI Redirect URI

A Sample OAuth 2 Workﬂow • My company registers the app with the thing’s vendor providing a redirect URI for successful and failed logins and gets a client id and a secret.

A Sample OAuth 2 Workﬂow • My company registers the app with the thing’s vendor providing a redirect URI for successful and failed logins and gets a client id and a secret. • My company builds an app that uses the thing’s API (e.g. with REST ).

A Sample OAuth 2 Workﬂow • My company registers the app with the thing’s vendor: providing a redirect URI for successful and failed logins and gets a client id and a secret. • My company builds an app that uses the thing’s API (e.g. with REST ). • The user opens my app and logs into thing’s vendor site via its authentication server (not the OAuth provider).

A Sample OAuth 2 Workﬂow • My company registers the app with the thing’s vendor providing a redirect URI for successful and failed logins and gets a client id and a secret. • My company builds an app that uses the thing’s API (e.g. with REST ) • The user opens my app and logs into thing’s vendor site via its authentication server (not the OAuth provider). • My app (not the browser) generates the unguessable state value and sends the request to the thing vendor’s OAuth provider:    https://<auth_server>/path?clientid=123&redirect_uri=https// myCallbackURL&response_type=code&scope=“email user_likes”&state=7F32G5

A Sample OAuth 2 Workﬂow • My company registers the app with the thing’s vendor providing a redirect URI for successful and failed logins and gets a client id and a secret. • My company builds an app that uses the thing’s API (e.g. with REST ) • The user opens my app and logs into thing’s vendor site via its authentication server (not the OAuth provider). • My app (not the browser) generates the unguessable state value and sends the request to the thing vendor’s OAuth provider:    https://<auth_server>/path?clientid=123&redirect_uri=https// myCallbackURL&response_type=code&scope=“email user_likes”&state=7F32G5 • My app receives a temporary auth code from the thing’s OAuth server and compares the state with the one received from the server:    https://myCallbackURL?code=54321&state=7F32G5

A Sample OAuth 2 Workﬂow • My company registers the app with the thing’s vendor providing a redirect URI for successful and failed logins and gets a client id and a secret. • My company builds an app that uses the thing’s API (e.g. with REST ) • The user opens my app and logs into thing’s vendor site via its authentication server (not the OAuth provider). • My app (not the browser) generates the unguessable state value and sends the request to the thing vendor’s OAuth provider:    https://<auth_server>/path?clientid=123&redirect_uri=https// myCallbackURL&response_type=code&scope=“email user_likes”&state=7F32G5 • My app receives temporary auth code from the thing’s OAuth server and compares the state with the one received from the server:    https://myCallbackURL?code=54321&state=7F32G5 • ,My app makes another request adding the secret and exchanging the code for the authorization token:    https://<auth_server>/path?clientid=123&client_secret=…&code=54321&redirect_uri=  https//myCallbackURL&grant_type=authorization_code

A Sample OAuth 2 Workﬂow • My company registers the app with the thing’s vendor: providing a redirect URI for successful and failed logins and gets a client id and a secret. • My company builds an app that uses the thing’s API (e.g. with REST ) • The user opens my app and logs into thing’s vendor site via its authentication server (not the OAuth provider). • My app (not the browser) generates the unguessable state value and sends the request to the thing vendor’s OAuth provider:    https://<auth_server>/path?clientid=123&redirect_uri=https// myCallbackURL&response_type=code&scope=“email user_likes”&state=7F32G5 • My app receives temporary auth code from the thing’s OAuth server and compares the state with the one received from the server:    https://myCallbackURL?code=54321&state=7F32G5 • ,My app makes another request adding the secret and exchanging the code for the authorization token:    https://<auth_server>/path?clientid=123&client_secret=…&code=54321&redirect_uri=  https//myCallbackURL&grant_type=authorization_code • The thing’s vendor redirects the user to my app and returns the authorization token.

A Sample OAuth 2 Workﬂow • My company registers the app with the thing’s vendor providing a redirect URI for successful and failed logins and gets a client id and a secret. • My company builds an app that uses the thing’s API (e.g. with REST ) • The user opens my app and logs into thing’s vendor site via its authentication server (not the OAuth provider). • My app (not the browser) generates the unguessable state value and sends the request to the thing vendor’s OAuth provider:    https://<auth_server>/path?clientid=123&redirect_uri=https//myCallbackURL&response_type=code&scope=“email user_likes”&state=7F32G5 • My app receives temporary auth code from the thing’s OAuth server and compares the state with the one received from the server:  https://myCallbackURL?code=54321&state=7F32G5 • ,My app makes another request adding the secret and exchanging the code for the authorization token:    https://<auth_server>/path?clientid=123&client_secret=…&code=54321&redirect_uri=  https//myCallbackURL&grant_type=authorization_code • The thing’s vendor redirects the user to my app and provides the authorization token. • My app starts invoking the vendor’s API using the token.

Access and Refresh Tokens • The OAuth 2 server returns the authorization token. It expires after certain time interval. iHealtLabs sends the token in JSON format that expires in 10 min. • The OAuth 2 server also can provide a refresh token that the client app uses to request a new token instead of the expired one.

© 2015 Farata Systems WebSocket Workﬂow • Establish connection with the service endpoint upgrading the protocol from HTTP to WebSocket • Send messages in both directions at the same time (Full Duplex) • Close the connection

© 2015 Farata Systems Apps for Websockets • Live trading/auctions/sports notiﬁcations • Controlling medical equipment over the web • Chat applications • Multiplayer online games • Any app that requires a data push from a server

© 2015 Farata Systems WebSocket Client/Server handshake • Client sends an UPGRADE HTTP-request • Server conﬁrms UPGRADE • Client receives UPGRADE response • Client setsreadyState=1 on the WebSocket object

© 2015 Farata Systems The JavaScript Client if (window.WebSocket) { ws = new WebSocket("ws://www.websocket.org/echo"); ws.onopen = function() { console.log("onopen"); }; ws.onmessage = function(e) { console.log("echo from server : " + e.data); }; ws.onclose = function() { console.log("onclose"); }; ws.onerror = function() { console.log("onerror"); }; } else { console.log("WebSocket object is not supported"); } ws.send(“Hello Server”);Sending a request:

© 2015 Farata Systems Java EE WebSocket Server’s APIs 1. Annotated WebSocket endpoint Annotate a POJO with @ServerEndpoint, and its methods with @OnOpen,@OnMessage, @OnError,and @OnClose 2. Programmatic endpoint Extend your class from javax.websocket.Endpoint and override onOpen(), onMessage(), onError(), and onClose().

© 2015 Farata Systems HelloWebSocket Server @ServerEndpoint("/hello") public class HelloWebSocket { @OnOpen public void greetTheClient(Session session){ try { session.getBasicRemote().sendText("Hello stranger"); } catch (IOException ioe) { System.out.println(ioe.getMessage()); } } } The server-side push without client’s requests A detailed description at http://bit.ly/1DHuKwg

© 2015 Farata Systems Websockets with Spring Framework public class WebSocketEndPoint extends TextWebSocketHandler {  private final static Logger LOG = LoggerFactory.getLogger(WebSocketEndPoint.class);    private Gson gson;  private WebSocketSession currentSession;    @Override  public void afterConnectionEstablished(WebSocketSession session) throws Exception {  super.afterConnectionEstablished(session);    setCurrentSession(session);  }    public boolean sendMeasurement(Measurement m) {  if (getCurrentSession() != null) {  TextMessage message = new TextMessage(getGson().toJson(m));    try {  getCurrentSession().sendMessage(message);  } catch (IOException e) {  e.printStackTrace();  return false;  }    return true;  } else {  LOG.info("Can not send message, session is not established.");  return false;  }  }

Deploying with Spring Boot • Java EE REST services are deployed in a WAR under the external Java Server. • Spring Boot allows creating a standalone app (a JAR) with an embedded servlet container. • Starting our RESTful server: java -jar MyJar. • We used Tomcat. To use another server, exclude Tomcat in build conﬁguration and specify another dependency. • A sample section from Gradle build replacing Tomcat with Jetty: dependencies { compile("org.springframework.boot:spring-boot-starter-web") { exclude module: "spring-boot-starter-tomcat" } compile("org.springframework.boot:spring-boot-starter-jetty") }

Security • Device vendors should take security very seriously. • We don’t deal with security between the thing and its vendor. • The OAuth state attribute helps ensuring that the received redirect_uri is the same as provided during the app registration. • IoT integration apps are as as secure as any other Web app (see owasp.org).

Thank you! • Farata Systems: faratasystems.com • email: yfain@faratasystems.com • Twitter: @yfain • My blog: yakovfain.com • My podcast: americhka.us

RESTful services and OAUTH protocol in IoT

More Related Content

What's hot

Viewers also liked

Similar to RESTful services and OAUTH protocol in IoT

More from Yakov Fain

Recently uploaded

RESTful services and OAUTH protocol in IoT