16 May Single-Sign On into multiple Wearables and Devices
It enables you to connect the user to the external data source. In other words it provides the developer friendly api call to connect across multiple applications and devices using a single api call. It removes all the core development tasks to connect across multiple Authentication protocols across different api’s and provides an abstract REST Endpoint to integrate into your Application.
We have provided the api call (Single-Sign On Endpoint) which enables your application to embed the connection urls into your application, not like it redirects to connecting page, whose UI is alien to your application, instead you can add those urls to your application for seems less integration.
Issues we solved for you while providing you single sign on
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. The API’s which use this authentication mechanism for user authorization are MisFit , Fitbit, Runkeeper, MapMyFitness, MapMyWalk, Strava, Jawbone, 23&me, Sonly lifelog, movesapp, lifefitness and Microsoft.
The first figure shows the authentication flow for Fitbit and later one shows the authentication flow for Misfit.
OAuth 1.0 provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections. The API’s which use this authentication mechanism for user authorization are Withings, Fatsecret and VitaDock
The figure shows the how authentication should be handled in vitadock.
This specification was derived from the OAuth Core 1.0 specification. OAuth Core 1.0 Revision A was created to address a session fixation attack identified in the OAuth Core 1.0 specification as detailed in http://oauth.net/advisories/2009-1. A full inventory of changes is available in the specification repository.
This sort of authentication is somewhat like Oauth 1.0 but is not as per specification given. The API’s which use this sort of are PredictBGL (manageBGL)
In this blog we tried to show cast how we have resolved the dependency of the connecting the users across multiple sources using different authentication protocols and provided a single sign on tool which enables the developers to just add the connection urls in there applications and forget about integrating different protocols, the connect urls calls provide the pure abstraction of complexity underneath. Stay tuned for more action and data. Follow us on twitter and instagram.