In the world of API development and integration, securing API calls is paramount to ensure that data exchange between systems is protected from unauthorized access.
If your enterprise is using Mulesoft platform, APIs access can be protected by a combination of one or more of the schemes below:
- IP allow or deny lists;
- private VPCs that are not exposed to not secured networks; and,
- secrets added to HTTP headers (or query parameters), which are inspected for validity at several points during the API lifecycle using API Policies.
This article delves into the APIs security strategies implemented by Mulesoft for protecting APIs using secrets and Policies. I will leave IP Blocking and VPCs for a later time.
Out of the Box, Mulesoft supports 2 types(1) of secret validation policies:
- Client ID Enforcement: client ids and client secrets + Basic Authentication; and,
- OpenId Connect Access Token Enforcement: oAuth tokens validation.
Historically, API designers have opted heavily on adding client id and secrets to API headers as means of identifying and authenticate client requests. We will discuss Client ID Enforcement policy first.
####### (1) there are other security validation policies but they are either variations of those 2 above or just injection detection policies(not really authentication/authorization).
Due to its simplicity, this method is used the most in securing Mulesoft APIs.
Features:
- This method involves a client application receiving a Client ID and a Client Secret upon registration with the Mulesoft API Manager.
- The Client ID identifies the application making the request, while the Client Secret is a secret key known only to the application and the authorization server.
Mulesoft API Manager can manage not only client applications but also assign contracts and policies to each API in order to determine which clients have access to what APIs.
Pros:
- Simplicity: It's relatively straightforward to implement compared to OAuth 2.0.
- Moderate Security: If kept confidential and used correctly, Client IDs and Secrets provide a secure method for authenticating API calls.
Cons:
- Limited to Server-to-Server: Best suited for server-to-server interactions where the Client Secret can be securely stored.
- Risk of Exposure: Client Secrets are somewhat static and rarely rotate. If the Client Secret is exposed, it can be reused maliciously for a long time, making this method less secure then, lets say an oAuth token that expires more often.
To protect an API using client ID policy, you have to add the policy in the Anypoint API Manager by clicking in Policies when you have an API selected:
Add Client ID Enforcement:
Then you can choose between Client ID or Basic Auth credentials types:
Here you can also set where the client_id and client_secret values are coming from. Any Dataweave expression is valid.
After the policy is applied (it may take a few seconds until the agent updates the policy for your application), only callers that contain the headers client_id and client_secret with valid values will be able to call this API.
Any request to a protected API with * Client Id Enforcement * Policy applied need to provide a valid client id and secret.
If the policy was applied with default configurations, you need to pass the client_id and client_secret in the header.
Configuration your Http Requester to pass client_id and client_secret in each request is easy: Just add them to the HTTP Request Config:
oAuth tokens came to fulfill modern authentication and authorization requirements such as:
- User Impersonation
- Use of claims & scopes for in depth authorization
- short lived secrets (tokens)
Features:
- OAuth 2.0 is a protocol that allows third-party services to exchange web resources on behalf of a user.
- It separates the role of the client from that of the resource owner, enabling the user to grant limited access to their resources without sharing their credentials.
- Supports various "grant types" for different scenarios, such as authorization code, implicit grant, client credentials, and refresh token.
Pros:
- Flexibility and Security: OAuth 2.0's diverse grant types accommodate various application scenarios, enhancing security without compromising flexibility.
- User Authorization: It enables users to grant apps access to their information on other websites without exposing their credentials.
- Widely Supported: OAuth 2.0 is supported by major internet companies, facilitating integration with services like Google, Facebook, and Microsoft.
Cons:
- Complexity: Implementing OAuth 2.0 can be complex due to its various components and grant types, even when using a platform like Mulesoft.
- Potential for Misconfiguration: Due to its complexity, there's a higher risk of misconfiguration, potentially leading to security vulnerabilities.
oAuth Validation policies are only available if you Anypoint Platform is configured with a oAuth capable Client ID Provider such as Okta on PingFederate.
To protect an API using an oAuth policy, you have to add the policy OpenId Connect Access Token Enforcement in the Anypoint API Manager by clicking in Policies when you have an API selected:
Then you have to add the Policy below:
Add any special configuration needed such as Scopes:
Good part of the oAuth complexity comes from what "oAuth dance" - or, how we exchange a secret by a oAuth token.
Hopefully, Mulesoft provides a super easy way to acquire and renew oauth tokens when they expire. Here it is how:
First you need to add a dependency to the oauth module to your app pom.xml:
<dependency>
<groupId>org.mule.modules</groupId>
<artifactId>mule-oauth-module</artifactId>
<version>1.1.20</version>
<classifier>mule-plugin</classifier>
</dependency>
Then configure the client credentials grant in the Http Requester:
- OAuth stands out for its robust security features and flexibility, making it suitable for applications requiring user delegation and permissions. However, its complexity and potential for misconfiguration necessitate careful implementation.
- Client ID and Client Secret or Basic Auth offer a balance between simplicity and security, ideal for server-to-server communication where the Client Secret can be securely stored. Nevertheless, they are less suited for scenarios where the Client Secret cannot be securely managed.
In conclusion, the choice of authentication mechanism depends on the specific requirements and context of your application. OAuth 2.0 is preferable for applications involving user data and third-party services, whereas Client ID and Secret might be more appropriate for simpler server-to-server interactions. Simple API Keys could be reserved for internal or low-risk applications where ease of use is the priority.
I am a Sr. Integration Architect working exclusively with Mulesoft for more than 10 years. I have connected and integrated anything to almost everything 😊. You can find me on linkedin.