Prototyping Mule OAuth2 Client Application

Introduction

This article explains how to prototype Mule OAuth 2.0 client application with grant type of "Client Credentials", which is most popular grant type for Mule integration. Most modern APIs enforce OAuth2.0 security policies. OAuth2.0 has the following Grant Types (The detailed explanation can be found here):

• Authorization Code
• PKCE
• Client Credentials
• Device Code
• Refresh Token
• Legacy: Implicit Flow
• Legacy: Password Grant

This post will cover the following topics:

• Using postman to retrieve access token
• Prototyping retrieve access token using cURL
• Mule flow to retrieve access token
• Sample flow using the access token with caching scope

OAuth 2.0 With Client Credential Grant Type

In order to access the OAuth2.0 enabled APIs, we first have to retrieve the access token from the Identity Providers. Then we can access the API by passing the access token. The parameters for Client Credential can be the following:

• grant_type (required)
• scope (optional)
• client_id (required)
• client_secret (required)

In most cases, cilent_id and client_secret are encrypted as Basic Authentication. The encryption can be done using base64 or openssl as the following:

?

1	echo -n "${CLIENT_ID}:${CLIENT_SECRET}" | base64

?

1	echo -n "${CLIENT_ID}:${CLIENT_SECRET}" | openssl enc -base64

Note: the "-n" option of echo is for not printing the trailing newline character. This is very important.

Using Postman to Retrieve Access Token

The postman is the best tool to do prototyping for the OAuth 2 client. The following snapshot shows the setup of the Postman:
for body:

for Headers:

for Authorization:

cURL Solution

Once we have the postman, the solution of cUrl is very straight forward.

?

1 2 3 4 5 6 7 8 9 10 11 12 13

$ cat oauth2-client.sh   #!/bin/bash # CLIENT_ID=MY-CLIENT-ID-GOES-HERE-WITHOUT-QUOTE CLIENT_SECRET=YOUR-CLIENT-SECRET-GOES-HERE-WITHOUT-QUOTE   OAUTH_HEADER=$(echo -n "${CLIENT_ID}:${CLIENT_SECRET}" | base64)   curl -d "grant_type=client_credentials&scope=https://graph.microsoft.com/.default" \      -H "Content-Type: application/x-www-form-urlencoded" \      -H "Authorization: Basic ${OAUTH_HEADER}" \      -XPOST https://login.microsoftonline.com/keurig.onmicrosoft.com/oauth2/v2.0/token

Mule Application Solution - Retrieve access_token

The mule application flow for retrieving access token is the following:

The Data-Weave transformation code is the following:

?

1 2 3 4 5 6 7

%dw 2.0 output application/x-www-form-urlencoded --- {  grant_type: "client_credentials",  scope: "https://graph.microsoft.com/.default" }

The request configuration is as the following:

?

1 2 3 4 5 6 7

<http:request method="POST" doc:name="Request" doc:id="65997138-84c0-48b3-8347-68abf386b3a1" config-ref="HTTP_Request_configuration" path="/keurig.onmicrosoft.com/oauth2/v2.0/token">    <http:headers><!--[CDATA[#[output application/java --- {  "Content-Type" : "application/x-www-form-urlencoded" }]]]--></http:headers> </http:request>

The HTTPS connector configuration referred in the request is the following:

The xml configuration is the following:

?

1 2 3 4 5 6 7 8 9 10

<http:request-config name="HTTP_Request_configuration" doc:name="HTTP Request configuration" doc:id="fb6e2c7d-010f-4141-bafe-a4a50c4fc540">   <http:request-connection protocol="${oauth2.protocol}" host="${oauth2.host}" port="${oauth2.port}">    <reconnection>     <reconnect frequency="5000">    </reconnect></reconnection>    <http:authentication>     <http:basic-authentication username="${secure::oauth2.client.id}" password="${secure::oauth2.client.secret}">    </http:basic-authentication></http:authentication>   </http:request-connection> </http:request-config>

As you can see, we pass the client_id and client_secret as the username and password of the basic authentication. This is just base64 encoded string. Here is an example of the response from the retrieval of access token.

?

1 2 3 4 5 6

{     "token_type": "Bearer",     "expires_in": 3599,     "ext_expires_in": 3599,     "access_token": "eyJ0eXAi......" }

Mule Application Solution - Use access_token

The following diagram shows the usage of the access_token. The access_token is passed to the server as header.

As you can see, we need to use cache scope. This allow us to avoid calling the server if the token is not expired. In this case, the token will expire in one hour. Thus our object store TTL should be less then 60 minutes.