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:
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:
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.
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 firstname.lastname@example.org.