OAuth 2.0 implementation in Mule 4 using Mule OAuth2 provider

OAuth 2.0:

OAuth 2.0 is the industry-standard protocol for authorization. Ref: https://oauth.net/2/

OAuth dance:

OAuth dance is an authentication process performed by client, Mule application (server) and OAuth 2.0 provider.

Mule application: The Mule application that is secured by 2.0 policy

Client: Any application that wants to access the above Mule application

OAuth provider: It’s a software that provides the secure token to the client and validates the token. There are many third-party OAuth providers like Okta, Github, Salesforce and OpenAM. MuleSoft also has its own OAuth provider. We’re going to use the Mule OAuth provider.

Reference: https://docs.mulesoft.com/api-manager/2.x/mule-oauth-provider-landing-page

Oauth dance

Ref: https://docs.mulesoft.com/api-manager/2.x/oauth-dance-about

Here, grant type used is ‘CLIENT_CREDENTIALS’

Ref: https://docs.mulesoft.com/api-manager/2.x/oauth-grant-types-about

Mule OAuth 2.0 provider

Mule OAuth 2.0 Provider is an OAuth 2.0 provider alternative developed by MuleSoft that can be used in any organization.

Mule OAuth 2.0 provider module

• Mule has provided an Oauth 2.0 provider module in Anypoint exchange.
• The OAuth2 Provider Module allows a Mule application to be configured as an Authentication Manager (OAuth provider) in an OAuth2 Dance.
• With this role, the application will be able to authenticate registered clients, grant tokens, validate tokens or register and delete clients, all during the execution of a flow.
• This module has four operations:
  • Create client
  • Delete client
  • Validate token
  • Revoke token

Note: There’s no separate operation for GET TOKEN in Mule OAuth provider. It’s an inbuilt operation provided in Mule OAuth provider configuration.

Step-by-step procedure

Prerequisites

• A mule application should be successfully running in runtime manager.
• Client_Id and Client_secret should be generated.
• Here, a simple mule application that returns the sum of two given numbers that are passed as query parameters is deployed.
• Here, postman is the client that accesses the mule application.
• Let’s develop a Mule OAuth 2.0 provider that can provide the operations like ‘create client’ , ‘get access token’ , ‘validate token’.

• Mule OAuth 2.0 provider

• Create a project “oauth2.0”.
• Create two object stores in which ‘client credentials’ and ‘tokens’ are stored.





• Now, let’s create OAuth2 provider configuration in global elements.

<oauth2-provider:config name=”Oauth2_Provider_Config” doc:name=”Oauth2 Provider  Config” doc:id=”adcc2165-73cd-4c0e-8d79-4fedd5704714″ providerName=”Oauth2_Provider” listenerConfig=”HTTP_Listener_config” clientStore=”client_objectStore” supportedGrantTypes=”CLIENT_CREDENTIALS”>

            <oauth2-provider:token-config tokenStore=”token_objetStore” />

</oauth2-provider:config>

                                    Oauth2 provider configuration.xml

• listener config: HTTP listener configuration through which Mule OAuth 2.0 provider is listening. (Shown below.)
• Client validation rate limiter: To control access to validate client operations. It will control that failures calls within a certain period don’t exceed a maximum count. After that number of failures is reached, further requests are rejected.
• Client store: Select object store created to store client details.
• Token generation strategy is default.
• Grant_types: ‘CLIENT_CREDENTIALS’ is used as grant type.
• Scopes : No Scopes is provided.

Ref: https://docs.mulesoft.com/api-manager/2.x/mule-oauth-provider-landing-page

• Token config:
  • Path: This is the path used to get the “token.”
  • Token store: Select object store created to store tokens.
  • Token ttl: This is the expiration time of a token.

• Add ‘OAuth2 provider’ module from Exchange into the project.

Create client

• Create a flow and add HTTP listener with path “/createClient”.
  • Create an HTTP listener config. (This configuration has to be provided in listener config field of OAuth 2.0 provider config).
  • Add create client operation and fill the required fields as below.

• Select the Oauth2 provider config created in module configuration tab.
• Client id, client secret, client name are passed from client as headers.
• Description, Principal and redirect uris are hard coded. You can pass these values from client or hard code depending on requirement.
• “CLIENT_CREDENTIALS” are used as Grant type.
• No scopes are declared.
• Type is selected as “Confidential” to maintain confidentiality of the credentials.
• If “Fail if present” is ticked, it doesn’t allow duplicate clients.
• Add a set payload component and set the value to “Client created successfully.”

Url: http://{host}:{port}/createClient

Get token

• Mule Oauth2 provider module doesn’t provide separate operation for token generation. It is an inbuilt process.
• The path to get the token is given in the OAuth2 provider config.

Url: http://{host}:{port}/token

Validate token

• Create a flow and add HTTP listener with path “/validate”.
  • Add an HTTP listener config.
  • Add Validate token operation and fill the required fields as below.

• Access token is passed as a Bearer token in “authorization” header from client.

• No scope is declared.
  • Set the response in Transform message as required.
• The OAuth 2.0 provider application is ready to deploy into runtime manager.
• Deploy it into cloudhub and make sure it is running successfully in runtime manager.

Oauth implementation URL: http://oauth2-api.us-e2.cloudhub.io/

• Add OAuth 2.0 in raml:
• Modify the raml of the mule application as below.
• Add below code in RAML.

securitySchemes:

 oauth_2_0:

       description: |

           Mule OAuth 2.0.

       type: OAuth 2.0

       describedBy:

           headers:

              Authorization:

                  description: |

                    Used to send a valid OAuth 2 access token. Do 

                   not use with the “access_token” query string 

                   parameter.

                  type: string

                   required: true

           responses:

               401:

                  description: |

                      Bad or expired token.

               403:

                  description: |

                      Bad OAuth request.

       settings:

        authorizationUri: http://0.0.0.0:8081/authorize

        accessTokenUri: http://0.0.0.0:8081/access-token

        authorizationGrants: [ client_credentials]

• Add“securedBy:[ oauth_2_0]” under each method in the RAML.
• Publish the modified RAML to exchange.

• Update your application with the latest raml and deploy again.

• Create an API in API manager:

• Manage the API from Exchange and select ‘endpoint with proxy’ to create proxy application.

• Give the URL of the mule application in implementation URL.
  
  Implementation URL: http://addition-api.us-e2.cloudhub.io/api

• Click save.

• Give the runtime version and proxy application name.
• Deploy the proxy application. (Since the proxy application was already deployed, it is showing redeploy).
• Make sure the proxy application is successfully deployed and running.

• Make sure that API is Active in API manager.

Proxy URL: http://api-proxy.us-e2.cloudhub.io/

• Apply OAuth 2.0 policy on API proxy:

• Select required OAuth version and click on configure policy.

• Provide the validation URL.
• Validation URL: http://oauth2-api.us-e2.cloudhub.io/validate

• Click on Apply.
• Lets test from POSTMAN , which acts as a client here.

Step 1: Register Client (performed by Mule developers)

• Provide the client_id and client_secret generated.

Step 2: Get Access Token (performed by client)

• Provide Grant Type as ‘CLIENT_CREDENTIALS’

Step 3: Request to actual application

• Provide the access token as Bearer token in the Authorization field.

Authorization: Bearer ‘AccessToken’

• Send request to actual Application.

Note:

• Client credentials in object _clientStore last for 30 days.
• Instead of adding client credentials every time after 30 days, we can achieve auto refreshing of client credentials by creating a flow with Scheduler as below.

• Set the scheduler frequency to 20 days (or any number less than 30).
• Retrieve all the client_id’s client_Ids from object _clientStore.

• Send each client id to create client flow using For Each.

• Uncheck the ‘Fail if present’ check box in Create Client operation in CreateClientFlow.

This will automatically refresh the clients before they expire.

— By Venkateswara Bhuvan Tej Sanku