Author: Venkateswara Bhuvan Tej Sanku
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 which is secured by 2.0 policy.
Client: Any application which wants to access the above Mule application.
OAuth provider: It is a software which provides the secure token to the client and validates the token. There are many third party OAuth providers like Okta, Github, Salesforce, OpenAM etc..MuleSoft also has its own OAuth provider. We are going to use 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 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 4 operations
1. CREATE CLIENT
2. DELETE CLIENT
3. VALIDATE TOKEN
4. REVOKE TOKEN
NOTE: There is no separate operation for GET TOKEN in Mule oauth provider.It is 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 which returns the sum of two given numbers which are passed as query parameters is deployed.
- Here, postman is the client which access the mule application.
- Lets develop a Mule OAuth 2.0 provider which can provide the operations like ‘create client’ , ‘get access token’ , ‘validate token’ etc…
1). Mule OAuth 2.0 provider:
- Create a project “oauth2.0”.
- Create two object stores in which ‘client credentials’ and ‘tokens’ are stored.
- Now, lets 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 do not 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’ are 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 depends 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 to create 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 inbuilts process
- The path to get the token is given in 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.
- Now 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/
2). 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 the application withlatest raml and deploy again.
3). 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. (As the proxy application already deployed, it is showing redeploy).
- Make sure that 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/
4). 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 actas 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 Authorization field.
Authorization : Bearer ‘AccessToken’
- Send request to actual Application.
Note:
- Client credentials in object _clientStore are last onlyfor 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 the client_id’s client_Ids from object _clientStore.
- Send each client id to create client flow using For Each.
- Un-check the ‘Fail if present’ check box in Create Client operation in CreateClientFlow.
This will automatically refresh the clients before they expire.
