OAuth 2 provides the authorization to the flows. Here we will see how the OAuth2.0 secure your Mule flows created using Anypoint Studio.

Moreover, we will focus here the step by step approach to implement OAuth2.0 in our Mule flows to achieve high-level security using the token mechanism provided by OAuth2.0

The very important difference to keep in mind while implementing the security in applications is the difference between users and clients: clients are the ones who expose third-party applications (means external APIs) and will connect with our organizational APIs; users are the users of our internal application.

For an example of this difference, imagine Facebook. You are a registered user of Facebook and want to access another application which is inside a Facebook account called, say, "playzone" (not real, just used as an example ), which allows you to play virtual games on Facebook. In this case, you are the user of Facebook and "playzone" is a client application for Facebook. So the client id and secret password for "playzone" are registered with Facebook.

By using these credentials, the client is secured with the application.

Every client has a different “client id” and a “secret” that is like a password for that client.

There are two types of clients: “Confidential” and “Public.”

“Confidential” means that it needs to validate client credentials, while “Public” does not need the validation of client credentials.

Every client has a redirect-URI, that is used to get the access_token using an access_code.

Types of Access Provided by the OAuth Provider

There are several types of access called “OAuth grant types” available:

1. Authorization code – It has two steps to follow:

   1. Log in to a form automatically created by the provider.

   2. Get an access_code and then you must use the acces_code in a different URL to get the access_token.

2. Implicit – Only one step to follow:

   1. Log in to a form automatically created by the provider.

3. Client credentials – Here the username and password are not required. Rather, you access the access_token by providing only the clientId, clientSecret, and the scope.

Let's follow these steps to implement OAuth2.0:

1. OAuth Provider namespaces need to be defined in order to configure OAuth and Mule-Security for the authentication manager.

Below is the sample code to define namespaces:

<mule

xmlns:ss="http://www.springframework.org/schema/security"

xmlns:mule-ss="http://www.mulesoft.org/schema/mule/spring-security"

xmlns:spring="http://www.springframework.org/schema/beans"

...

version="EE-3.3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

...

xsi:schemaLocation="

http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd

http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd

http://www.mulesoft.org/schema/mule/spring-security http://www.mulesoft.org/schema/mule/spring-security/current/mule-spring-security.xsd

http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">

2. The Security Manager needs to be defined in the authentication manager, which identifies the users that are allowed to access the application.

Below is the sample code to define security manager:

<spring:beans>

<ss:authentication-manager id="sampleSecurityAuthenticationManager">

<ss:authentication-provider>

<ss:user-service id="sampleSecurityUserService">

<ss:user name="username" password="xxxx" authorities="READ_PROFILES"/>

</ss:user-service>

</ss:authentication-provider>

</ss:authentication-manager>

</spring:beans>



<mule-ss:security-manager>

<mule-ss:delegate-security-provider name="sampleSecuritySecurityProvider" delegate-ref="sampleSecurityAuthenticationManager"/>

</mule-ss:security-manager>

3. Configure and create the OAuth 2.0 provider to define the type of login/access for getting an access_token.

Define the client that can access the application using OAuth. For this, we need the client id and the client secret of the client which wants to register with the application.

So we configure the “clients” element in the OAuth-provider using the secured information.

Below is the sample code for configuring an OAuth client in Mule:

<oauth2-provider:config>



<oauth2-provider:clients>

<oauth2-provider:client clientId="sampleClientId" secret="sampleClientSecret"

type="CONFIDENTIAL" clientName="sampleClient"

description="My sample client application">

<oauth2-provider:redirect-uris>

<oauth2-provider:redirect-uri>http://localhost*</oauth2-provider:redirect-uri>

</oauth2-provider:redirect-uris>

<oauth2-provider:authorized-grant-types>

<oauth2-provider:authorized-grant-type>AUTHORIZATION_CODE</oauth2-provider:authorized-grant-type>

</oauth2-provider:authorized-grant-types>

<oauth2-provider:scopes>

<oauth2-provider:scope>READ_RESOURCE</oauth2-provider:scope>

<oauth2-provider:scope>POST_RESOURCE</oauth2-provider:scope>

</oauth2-provider:scopes>

</oauth2-provider:client>

</oauth2-provider:clients>



<oauth2-provider:config/>

Here we have defined the client with its credentials inside the OAuth2 provider.

Next, we will configure the type of access.

Here, for our example, we will use the authorization code grant type which is the most general and more secure among all other grant types.

Below is the sample code to configure the grant type as Authorization_code:

<oauth2-provider:config

name="oauth2Provider"

providerName="SampleAPI"

supportedGrantTypes="AUTHORIZATION_CODE"

port="8081"

authorizationEndpointPath="sampleapi/api/authorize"

accessTokenEndpointPath="sampleapi/api/token"

sampleSecuritySecurityProvider-ref="sampleSecuritySecurityProvider"

scopes="READ_RESOURCE POST_RESOURCE" doc:name="OAuth provider">

<oauth2-provider:clients>

<oauth2-provider:client clientId="sampleClientId" secret="sampleClientSecret"

type="CONFIDENTIAL" clientName="sampleClient" description="My sample client application">

<oauth2-provider:redirect-uris>

<oauth2-provider:redirect-uri>http://localhost*</oauth2-provider:redirect-uri>

</oauth2-provider:redirect-uris>

<oauth2-provider:authorized-grant-types>

<oauth2-provider:authorized-grant-type>AUTHORIZATION_CODE</oauth2-provider:authorized-grant-type>

</oauth2-provider:authorized-grant-types>

<oauth2-provider:scopes>

<oauth2-provider:scope>READ_RESOURCE</oauth2-provider:scope>

<oauth2-provider:scope>POST_RESOURCE</oauth2-provider:scope>

</oauth2-provider:scopes>

</oauth2-provider:client>

</oauth2-provider:clients>

</oauth2-provider:config>

Note: Here, the READ_RESOURCE token is used which is a “permission constant token,” any name can be given.

Example: READ_POSTS. The “permission constant token” is used to access the API flows in Mule, so if the user has this permission constant token, then they have access to that flow.

Below is an example of a flow which tests the READ_RESOURCE permission:

<flow name="sample-read-resource" doc:name="SampleFlow">

<http:inbound-endpoint address="http://localhost:8082/resources" doc:name="HTTP" />

<oauth2-provider:validate config-ref="oauth2ProviderPassword" throwExceptionOnUnaccepted="true" doc:name="Validate Token" scopes="READ_RESOURCE" />

<set-payload value="Welcome to OAuth2" />

</flow>

To test this above flow, use the following URI:

• http://localhost:8082/resources?access_token_here

Just in case the access token does not match due to the user not having the correct permissions, an exception is thrown. One such exception which can get thrown is: InvalidAccessTokenException.