Not only should organisations protect their own APIs, but they should also protect traffic going to external third-party APIs. This prevents accidentally leaking OAuth tokens obtained for third-party APIs, such as those used to integrate with Salesforce, Google’s GSuite, Twitter, and others. To overcome this problem, the addition of a reverse gateway may be used to apply API management techniques to outbound API calls to third-parties. Let’s review what reverse gateways are, how they work, and why they are important for an API management strategy.
A reverse gateway acts as both a proxy to external third-party APIs and also as a token manager. Each managed third-party API is given a specific URL within the API manager, e.g. /twitter, and is routed through the API gateway rather than directly to the API.
Internally, developers are onboarded and assigned a token on their own API gateway, often called a sub-token, to work with the third-party API. The sub-token represents their application that will be making calls to the third-party API.
Whenever API requests are sent to this internal URL using the sub-token, the internal API management layer asserts the sub-token and then forwards the request, injecting the actual OAuth token for the service in the process.
Using a reverse gateway offers several advantages, including:
- Managing quotas centrally through API sub-tokens
- Restricting access to sensitive third-party APIs
- Centralising procurement processes when multiple teams need to utilise a third-party API
- Determine API monthly usage for charge-back to a specific team
API token leaks are becoming more common. Many vendors, including GitHub, have implemented detection systems to avoid API tokens from being included in source code or configuration files stored in a code repository. Vault-based solutions are being used to managed API tokens, ensuring they are injected into an application at deploy time, or perhaps requiring applications to request the values at runtime via an internal secrets API.
Reverse gateways centralise third-party API tokens, substituting sub-tokens in their place. While proper token management is still required, the monitoring and management capabilities of an API gateway limit the impact to an application’s sub-token, introducing the possibility of reduced risk of exposure.
While there are a variety of solutions to handle secrets management now, they fail to manage the relationship between third-party APIs and the application using them. Each time a new application needs to use a third-party API, the developers establish a relationship with the external organisation. In a large organisation, this might mean 10s to 100s of individual relationships that include contracts and subscription costs.
Reverse gateways enable this to be centrally managed to optimise both cost and time-to-production with these third-party APIs. Working with procurement departments, a team can consolidate multiple team subscriptions, negotiate rates, and adjust future contracts based on internal developer demand.
It is important to consider third-party APIs like your own. They should be monitored, managed, and reported on just like the APIs you produce for your organisation. Using an API gateway as a reverse gateway provides a consistent method of managing third-party APIs while optimizing their usage. Consider dedicating a team to managing some or all of your third-party APIs, using your API management reports to provide insights and negotiating tactics when possible.
For more insight into managing third-party APIs, take a look at the Cloud Native API Management whitepaper.