On this 10th ‘Day of Christmas’ Mule blog post, we tackle an increasingly important question in the world of APIs: Presume that you would like to create a remote API (which perhaps exposes some legacy business logic) for access by internal and/or external clients. How can you make sure that access to your API is protected in such a way that:
A) Only clients that you trust can access them;
B) Those clients can access your API through the explicit authorization of their end-users; and
C) The end-users can be authenticated with a central entity, *withouth* having to share their credentials with your API’s clients.
It turns out that over the last couple of years, as the prominence of remote APIs, specially REST based ones, has increased, the need for a good answer to this question has become critical. At the onset, to address the question, many proprietary web authentication protocols were created (AuthSub, AOL’s OpenAuth, Yahoo’s BBAuth, and others…). OAuth is a security model which brings together the results of such existing bodies of work to address this question in a common manner.
One of the most impressive elements of the Mule Enterprise Security (MES) features that we introduced at the beginning of December is the support for OAuth. Specifically, with MES, you can make Mule act as a full-fledged OAuth 2.0 provider (the latest version of the spec which has recently officially become a standard!) and use it to protect your backend APIs.
To show how easily this can be done, we have put together a sample Mule app that shows how, with only a couple of lines of XML, an HTTP API exposed by a Mule flow, can be protected with Mule’s OAuth 2.0 provider. The example also contains a simple JavaScript based Web client that walks through the OAuth dance and shows how clients (say a Mobile app) can interact with the OAuth provider in order to obtain a secure token and access the API. The following diagram illustrates the different elements of the example:
To better understand how the pieces come together, have a look at the following short viewlet which goes over the example and demonstrates its use.
This example is only the tip of the iceberg as far as the capabilities of the Mule Enterprise Security OAuth 2.0 provider are concerned. There is much more, including support for Role Based Access Control (RBAC), scopes, other OAuth 2.0 grant types, as well as the ability to protect APIs that are not necessarily exposed by Mule flows. I am planning to go over these other capabilities in upcoming Mule blogs – stay tuned! – but for now, hope you enjoy this simple example illustrating a very powerful capability recently introduced in Mule.
Note: To try out the example described in this blog , you need to install Mule Enterprise Security first. Only then you can import the example into Mule Studio (versions 3.3.1, 3.3.2, and 3.4 M2 are supported).
