OAuth

Introduction to OAuth

Overview

The popularity of social media apps, mobile apps and cloud services has introduced another authentication and authorization model.  In this model, at a minimum, three actors are involved.  The three actors are the user, client application and the service provider. This is often referred to as the three-legged OAuth model. The user is the owner of the resource and it grants client application access to its resources that are controlled by the service provider. OAuth standard enables the user to grant client application to its resources without ever sharing its username/password with the client application.

A simple example of OAuth

Traditionally, it is the social media applications that have been the main drivers behind OAuth deployment.  In the past, web applications such as news media sites would maintain their own user profile data by providing the option to each of its users to create custom profile on the site for better user experience.  This approach had many shortcomings for both users and media sites:

• Users had to provide email or username and password for each site during the initial creation of a profile.
• Users would often forget their passwords during the login process since they had created multiple profiles at different sites.
• Media sites were now responsible for securing their users’ emails and passwords from hackers.
• Users would often create fake profiles that would provide inaccurate tracking data to media sites.

Over time, social media sites such as Facebook, Twitter, LinkedIn, and Google have become the defacto repositories of a user’s social identity or profile. The availability of existing social identities with rich profile data provided an opportunity for sites to access user data outside their domain of control. OAuth is an identity standard that enables sites to access user profile data outside their domain of control without requiring users to pass their username, password to the site.

The Figure below illustrates a simple example that leverages OAuth.  A news media site (client application) that provides an option for a better social experience by allowing a user (resource owner) to post a comment on an article with the user’s facebook profile attributes (name, photo, location) displayed next to the comment. The user in this example, grants control to the news media site to fetch its facebook profile attributes from the facebook site (service provider) without ever revealing an email or password to the news media site.

The figure above is a common use case where a user (resource owner) is accessing a new media site (client application) to post a comment on an article using a Facebook account. Before the comment can be posted, the news media site fetches the user’s facebook profile attributes (user owned resources) from facebook (service provider). The granting of access to resources owned by the user to the client application on behalf of the user is enabled by the the OAuth standard.

OAuth with API Gateways

The flexibility and power of OAuth introduces complex transactional interaction between the parties in the three-legged OAuth model. Although the previous example demonstrates a common use case, there are multiple design time and run time interactions that take place behind the scenes between different parties.  The previous example is expanded to illustrate the run time interactions that take place to enable a seamless user experience.

OAuth Transactional Flow in 3-Legged Model

As shown above, OAuth is complex since it involves multiple actors, various token types, transport redirects and security protocols. To harness OAuth’s power and flexibility, client applications and service providers have to integrate with OAuth toolkit or library. The tight-coupling of OAuth with existing applications either on the service provider side or the client application presents several challenges:

• Client application, service provider security application (authorization server, resource server) have to be modified to integrate with OAuth toolkit or library.  This means developers have to be involved in the integration process.
• Tracking multiple versions of OAuth standards now becomes the responsibility of the integration development team.
• There is no centralized management of OAuth tokens and their expiry, as OAuth is integrated across multiple applications .
• Applications have to be trusted to generate, consume and validate correct and secure tokens.
• Complex transport mechanisms such as HTTP redirects have be added to existing applications.
• Tracking and isolating an issue within OAuth becomes more difficult since it is tightly coupled with applications.

All of the above challenges can be overcome by introducing the API gateways in the 3-Legged model.

OAuth with API Gateways in 3-Legged Model

The above figure illustrates two locations where an API Gateway can be deployed in the 3-Legged model to make the infrastructure OAuth enabled, without any modification to the applications. The gateway at the top is an OAuth client. The gateway at the bottom is an OAuth server. The loose-coupling of OAuth with your applications by leveraging API gateways offers the following advantages:

• Plug-n-play with no modification to client applications and service provider applications.
• Centralized management and enforcement of OAuth tokens and their expiry.
• API gateways with hardware assist provide a more secure mechanism in generation and validation of secure tokens.
• API gateways can scale to handle large number of OAuth requests.
• Complex transport mechanisms such as HTTP redirects are simple policy configurations in API gateways.
• Tracking and isolating an issue within OAuth is easier since OAuth is loosely-coupled with applications.

Learn how to simplify, secure and expedite the deployment of OAuth and Single-Sign On with API Gateways in your infrastructure by requesting a demo.