Single-Sign On into multiple Wearables and Devices

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.

Screen Shot 2016-05-16 at 8.11.54 PM

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 

Oauth 2.0

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.

fitbitScreen Shot 2016-05-16 at 8.35.51 PM

The first figure shows the authentication flow for Fitbit and later one shows the authentication flow for Misfit.

Oauth 1.0

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

Screen Shot 2016-05-16 at 8.29.39 PM

Screen Shot 2016-05-16 at 8.30.01 PM

The figure shows the how authentication should be handled in vitadock.

Oauth 1.0a

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.

Legacy Oauth

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)

Conclusion.

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.

 

No Comments

Sorry, the comment form is closed at this time.