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 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).