It’s Not Only Banking APIs That Must Be Secured
The fact that the API economy is growing rapidly is no longer news — it’s common knowledge. Many reports now depict a steep rise in API usage for different purposes. And with the escalating use of both public and internal APIs, reports also show a sharp surge in API attacks. There is a pressing need to secure APIs, but, as most software professionals know, companies don’t always give security top priority.
Many nonfinancial APIs have leaked user information in recent years, including breaches at Tesla, Peloton, LinkedIn and Marriott. Though this data might seem unimportant, the leaked information could be leveraged to launch further attacks, especially phishing attacks during which much more critical user data could end up in the hands of the attacker. With this in mind, securing APIs is necessary not only for banks. Any API, public or internal, needs robust security to thwart the increased level of attacks to protect the information they expose.
At the core of protecting APIs is a token-based architecture. A legacy approach, on the other hand, which deploys static API keys, is inadvisable: If an API key is lost, stolen or shared, it would have to be rotated and updated in the clients consuming that API. That’s not a very flexible or scalable model. There’s also the problem of obtaining the API key in the first place. That retrieval process must be authenticated somehow, whether a user or a system requests access to the API.
Token Validation
An API can take on the responsibility of validating an access token used to protect the API. The access token can come in a variety of formats, but a JSON Web Token (JWT) is the most common approach. The JWT is passed in the authorization header when an application or service calls the API. An advantage of a JWT is that it directly holds a set of claims that the API itself can consume to determine or authorize what information to return to the caller. APIs can be developed in many languages, but the implementation of token validation is similar across the board. Curity has several code examples for different API implementations that offer a good starting point to make implementing this approach easy.
The downside of using JWTs, at least for public applications, is that they could potentially hold personal identifiable information. That’s typically something you don’t want to be shared publicly. Instead, it’s much better for a public application to handle opaque (by-reference) tokens. This kind of token is simply a unique string. The API receiving the opaque token can introspect the token by calling the identity provider (IdP). This could, however, become costly for the API to perform frequently. A much better approach is to leverage an API gateway that can handle the introspection processing so that the API can use its resources for serving its content instead.
The API Gateway
Placing an API gateway in front of both public and internal APIs is a great way to add new security measures. The gateway can rate-limit API calls based on policies and who is calling the API. Inspecting request payloads for vulnerabilities, such as injection attacks, is typically something most modern gateways can also handle.
The API gateway is also an excellent place to handle authentication and authorization of API calls. Some gateways have rudimentary capabilities to handle this out of the box, but in many cases leveraging either the Phantom token approach or the split token approach results in a more secure and robust implementation. The gateway can handle an initial verification of access tokens and coarse-grained authorization using scopes. This will shield the API from running the initial token validation and frequent introspection calls. Furthermore, it also reduces unauthorized calls to the API itself. With either the Phantom or Split token approach, a public application never needs to hold a JWT. The API gateway obtains the JWT and validates it before it sends the JWT on to the API itself. At that point, the API can obviously consume the JWT as needed to determine what data to return.
Integrating these patterns with a modern API gateway is fairly trivial. At Curity, we have worked with several gateway providers over the years and have developed plug-ins to ease the integration process. If an API gateway is part of the architecture, integrating a token-based approach to secure the APIs should be a given.
The Developer Portal
With the growing number of APIs developed by organizations, there should be a standard method for developers to understand how to use them. This is where a good developer portal is the critical link between the API provider and the developer that needs to consume it. We won’t explore the inner workings of a DevPortal here, but one key component is managing API access. This typically involves generating a client_id or secret, or managing certificates that can be used to obtain access tokens that will grant access to the API.
The DevPortal is also used to track API usage and can correlate who or what is accessing an API and how often. A token-based architecture can help protect the APIs by mapping a specific client_id to a developer (or app). This way, the API gateway, for example, can determine who is accessing an API based on the token presented. To automate this process, an integration between the DevPortal and the identity provider (IdP) using dynamic client registration (DCR) is typically set up. With DCR, a new client that controls the token issuance is automatically generated in the IdP by the DevPortal. This creates a one-to-one mapping between the token distribution and the developer or app. It also allows for full control and monitoring of how the API is accessed.
Token Handler
Another consideration is how a single-page application (SPA) handles access tokens. There are significant security implications with handling and storing tokens in the SPA frontend. SPAs are vulnerable to Cross-site Scripting attacks (XSS) and cannot securely store any type of token. In addition to that, browsers are removing support for third-party cookies, making it more and more challenging to store, for example, refresh tokens in a cookie if the token service is running on a domain different from the SPA’s.
The Token Handler pattern can mitigate these issues. The Token Handler provides components that can be integrated with the API gateway. The SPA will only communicate directly with the Token Handler instead of communicating directly with the Token service to obtain tokens. The Token Handler is responsible for handling the tokens and will issue secure SameSite cookies to the SPA used for authentication and authorization.
The Token Handler would be a plug-in on the API gateway or API proxy. There are more details of the Token Handler in this overview and a working example in this “SPA Using the Token Handler Pattern” article.
Not Just for Banks
The API economy has exploded and is continuing to grow. With that, securing APIs must no longer be an afterthought. API security is not only for banking apps. A robust token-based architecture should be implemented from scratch in any new API project to achieve the highest level of API security. This, coupled with an API gateway and a good DevPortal, will safeguard the API and smooth the way for developers to consume the API. For SPAs, consider using a Token Handler integrated with the API gateway or API proxy to avoid handling tokens directly in the SPA vulnerable to XSS attacks.
