Authentication becomes a critical part of any business, that too developing applications using the OAuth2.0 protocol is still challenging to some C++Builder developers using Restful APIs as most modern IoT applications mandates. Don’t worry, this post will simplify your challenge and understand better.

Assume an end-user(Resource Owner) has an account in google(Resource Server) and has resources like contacts. The same user wants to sign up in Facebook (Third-Party App), as a user, he needs to reuse users credentials of google in Facebook and avoid fresh signup(filling all the personal details in Facebook and creating login credentials or
to access some of the protected resources from google e.g) use contacts from google to invite friends that need to be used on Facebook.

This is achieved by traditional Client Server authentication. But this approach has drawbacks as mentioned below.

• End user credentials is used by 3rd party app.
• 3rd party app store credentials for later use.
• Resource servers must provide password authentication.
• End users cannot revoke access to individual 3rd party app as credential are universal, can only block access by changing password.
• Compromise of 3rd party app exposes end user password.

OAuth2.0 addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token — a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

For above scenario, an end-user (resource owner) can grant facebook (client- webapp, browser, desktop app) access to his protected contacts stored at a google contacts (resource server), without sharing his username and password with the facebook client to invite friends. Instead, he authenticates directly with a server trusted by the contact service(authorization server), which issues the contacts service delegation-specific credentials (access token). End user data is exposed over a Restful API. All transaction is over HTTP/HTTPS.

REST – Representational state transfer web services are known as Restful APIs is an architecture style not a protocol. It exposes end user data (XML or typically JSON) by creating URI and transfer over a HTTP protocol. For RestDemo Sample click here.

OAuth2.0 Work Flow.

Authorization Grant Types: It can be Authorization code, Implicit, Resource owner credentials, Client Credentials.

OAuth2.0 and the Internet Of Things:

IoT Gadgets and Devices vast of amount of data which can be Applied with analytics which can creates revenue stream.

Many IoT Vendors expose end user data over Restful services. Be aware of Vendor Restful API restrictions such as Rate limiting, time and changes in vendor API may result in feature breaking in your client Application. To avoid such limitations you can check Embercadero’s Enterprise Mobility Services Middleware.

Okay, this would have helped in understanding the concepts about OAuth2.0 and IoT Use cases. To check the demonstration in action checkout this below one.