How OAuth 2.0 Supports third-party applications to authorize HTTP service?

OAuth and OAuth 2.0 are widely used authentication protocols which alert resource providers (e.g. Facebook, Twitter, Google, Microsoft etc.) every time resource owners give permission to third parties to run HTTP applications without exposing user passwords. In this blog, we will discuss how OAuth 2.0 can be used to support the authentication of business-critical HTTP applications with Google and cloud services. I will specifically focus on my team’s direct experience in implementing OAuth 2.0 for one of eInfochips clients, a leading smart home automation player.  The client has an ecosystem of partners who need to be authorized to access HTTP services in order to manage smart home appliances such as water sprinklers, refrigerators, thermostats, indoor lighting etc.

Why OAuth is so popular today? In classic authorization and authentication mechanisms, to provide restricted resources access to third-party applications, a resource owner is required to share user credentials with a third party. However, this may have a few concerns as below:

• Third party applications would require to store the resource owner’s login credentials for future use
• Passwords are exposed to third party apps
• Difficulties in restricting access to a limited set of user resources

OAuth is an open standard authorization protocol which addresses the above mentioned issues by introducing an authorization layer while separating the role of the client and resource owner. Instead of using login credentials to access resources, the client gets an access token – string that identifies a user. Authorization server issues access tokens to third-party clients with the permission of the resource owner. The client then uses this access token to avail the permitted resources of the resource server.  A refresh token is issued to the third parties by OAuth server to obtain a new access token when expired. OAuth defines four types of grants:

• Authorization Code Grant
• Implicit Grant
• Resource Owner Password Credentials Grant
• Client Credentials Grant

Let’s go back to our client use case for a leading home automation player dealing in smart home products. Since, it has a network of device partners who need to be authorized to access HTTP services for cloud-based management of various smart home appliances such as water sprinklers, refrigerators, thermostats, indoor lighting etc, it was felt that it would be best if the resource access provisioning is sanctioned using OAuth 2.0 mechanism. The scenario thus, plays out in the following way:

Jake (resource owner) wants to give access to the current temperature of his cloud-enabled thermostat (referred to as  “Provider”) to his cloud enabled/controlled air-conditioning and heating unit (referred to as “Consumer”). To achieve this, Jack will go to his Consumer app and start associating with the respective Provider. The Consumer will redirect Jack to Provider site where Jack will enter his credentials and approve the temperature access to Consumer. At backend, Provider will provide Access-Token and Refresh-Token to Consumer. Whenever Consumer requires temperature from Jack’s home, it will send Access-Token to get permitted temperature resource from Provider.

The OAuth specification makes a distinction between the activities of the resource server and the authorization serve.  At a high level, the main dependency is that the resource server needs to validate tokens provided to it, against the authorization server.

Terms and references

• OAuth – OAuth is a way to publish and interact with protected data.  In the context of this feature, we are talking specifically about OAuth 2.0.
• OAuth Authorization Server – The server which issues the access tokens to the client after obtaining authorization and successfully authenticating the resource owner.
• OAuth Resource Server – The server which host the protected resources and is capable of receiving and responding to protected resource using access tokens.
• OAuth Resource Owner – An entity which is capable of granting access (authorization) to a protected resource. If a resource owner is a person, it is referred to as an end-user.
• OAuth Client – An application which makes protected resource requests on behalf of resource owner.
• OAuth Scope – Fine grained access to resources.  e.g. It is used to grant access to specific APIs that control the scope.
• OAuth Grant Type – Specifies the type of flow used to authorize access.  Often times this is based on use case for what type of client is interacting with the system.
• OAuth Access Token – The token used by a client to access resources on the resource server.
• OAuth Refresh Token – The token used to obtain a new access token when an existing access token has expired.

In this blog, we have discussed the implementation of OAuth 2.0 protocol in the home automation segment. If you have ideas on how a similar OAuth 2.0 works out in your industry, we welcome your suggestions and feedback at marketing@einfochips.com.