How to Use OAuth to Integrate with Public Cloud Services

Traditionally, consumer internet companies have been the dominant users of public cloud services. Now enterprise customers, who initially had strong reservations about public cloud services are integrating their applications with those services. Enterprise applications such as databases, CRMs (Customer Resource Management) and ERPs (Enterprise Resource Planning) have started to leverage cloud services to increase business efficiency and reduce cost.

Popular cloud service providers such as Google, Salesforce.com and Workplay support REST and OAuth standards to enable enteprise application to consume their services. REST for application integration and OAuth for authentication and authorization. Rather than being mired in supporting multiple enterprise identities for granting and tracking access to their cloud resources, cloud providers use OAuth to provide a single vector of access control to their services. This integration scheme often works great for brand new consumer internet applications that don’t have go down the path of retrofitting REST and OAuth standards into their framework. Enterprise applications, unlike their counterparts in the consumer internet space have to retrofit. Enterprise applications that are cloud enabled still have to access local services using enterprise-based identity standards and cloud services using OAuth. Adding additional access control standards within an application becomes a welding job and adds friction to a successful deployment. This issue is further revealed in illustration below.

OAuth without an API Gateway

The figure above illustrates the architecture of a company that integrates its enterprise applications with three public cloud services.

Although, a cloud-based integration provides tremendous benefits strategically, there are several challenges that a company faces with this architecture as it embraces cloud services as the new backbone for its applications:

• Modifying applications to be OAuth enabled.
• Configuration and management of PKI keys for OAuth within an application.
• Making existing enterprise identities compatible with OAuth requires an expertise of a seasoned security developer. It also becomes harder for IT support staff to isolate access control problems when enterprise applications are managing credentials and policies for local and remote (cloud) services.
• Modifying applications to add a cloud provider’s REST API toolkit.
• Over time, scalability becomes an issue. As new applications are deployed and need to be cloud enabled, they must be integrated and tested for OAuth, which requires time and resources.
• Performance becomes an issue when SSL is used to communicate with cloud providers.

OAuth with an API Gateway

The figure above illustrates an architecture deployment with an API Gateway.

When an API gateway is added to the architecture deployment, it addresses many of the challenges we discussed in the previous scenario:

• No modifications are required to applications since an API Gateway has built in support for OAuth and REST.
• An API Gateway is a single point of enforcement that provides enterprise applications access control to their local services and access control to their cloud services.
• Enterprise applications can leverage their existing enterprise identities to gain access to cloud services by having an API Gateway map their identities to OAuth credentials.
• Scalability is no longer an issue as new applications are deployed. Integration and testing of OAuth is no longer required with applications.
• Centralized monitoring and enforcement is easier with an API Gateway. API Gateway provides full visibility to which application is accessing what service.
• Performance is no longer an issue since an API gateway accelerates SSL traffic that communicates with cloud providers.

Using an API Gateway as part of your cloud strategy becomes a minimally invasive IT operation. An API Gateway should be a key fabric of a company’s cloud strategy. If correctly leveraged, it will enable cloud services to be one of the primary backbones of an enterprise’s application architecture.

As you can see in the two illustrations, completing the OAuth process is a lot less work for an organization with an API gateway. The gateway does most of the heavy lifting for you. In these figures, we show three applications interacting with three cloud providers. Typically, this is just a starting point for enterprise customers who eventually expand to many internal applications integrated with many cloud providers.

What other services does your organization use OAuth to integrate with?

[promobox]

[/promobox]