Securing the API Economy

The digitalisation of business operations is continually changing, but some clear trends have emerged. It is now common for big businesses to employ multi-cloud strategies, bringing in third party technology to support business goals that revolve around advancing customer experience and delivery of digital services. Application Programming Interfaces or APIs have become a well established tool for web application developers. APIs are crucial to the web’s infrastructure, serving as a hidden third party that supports businesses in delivering products and services. Their importance as connectivity gateways for different programmes to interact demonstrates how vital they are in shaping the future of our digital transformation. SaaS was a game changer in the sense that it demonstrated how IT systems didn’t need to be proprietary. APIs have now had a similar effect in showing how open data and services with third parties can be revolutionary to business practices.

Software developers can use APIs to innovate at speed in a user-centric way whilst also safely allowing access to valuable user data - continuing to support business development goals. While APIs present ample opportunity for growth, managing API access is a challenge. User data creates an increased responsibility to ensure the safety of API-enabled transactions, and that data breaches aren't made easier by the presence of APIs in an app's software architecture. We can only do that with banking-grade security infrastructure that challenges the capabilities of cybercriminals with the most tech savvy minds.

Implementing banking-grade standards

Regulations that have been put in place, such as PSD2 in Europe, are there to improve and secure electronic payment services, creating an innovative and secure market. Thanks to PSD2, banks and financial institutions are now forced to open up for third parties resulting in the Open Banking landscape we’ve been seeing for the past several years, supported by APIs. Open Banking also allows organisations to modernise their offerings for users, while creating a competitive advantage. The essential financial-grade security, which is central to the acceptance of Open Banking, must be in place to ensure high security standards are met, requiring the implementation of specific technology.

User authentication and consent is key to the level of security necessary for Open Banking. Applications are required to provide strong confidence in customer’s identity and intentions. Strong Customer Authentication and proper Customer Consent are key elements of implementing this. The exact meaning of what falls under Strong Customer Authentication is domain specific and commonly translates to an accredited multi-factor authentication method. Even Customer Consents are context specific. In some use-cases it is sufficient to have the customer simply confirm a certain action, like a double-check, providing a “generic consent”, whereas in other cases stronger confidence in the customer's intention is required. In such cases the customer is required to provide a signature - in technical terms - when confirming an action. These levels of authentication and confirmation are crucial to complying with banking-grade standards that are necessary to protecting APIs.

The good news is that existing standards such as OAuth, and the Financial-grade API (FAPI) centered around OpenID Connect, now provide security and privacy protocols to support Open Banking use cases. Their "scopes" and "claims" token system allows IT systems to precisely control the degree and nature of access to personal information, solving the challenges mentioned earlier on top of another common API weakness: excessive data exposure. (In organisations with complex hierarchies, the improper assignment of permissions among different user groups can be avoided with scopes and claims baked into the system.) OAuth and OpenID Connect's usefulness in addressing data security issues can be boiled down to three techniques: the acquisition of explicit consent, Pairwise Pseudonymous Identifier (an unguessable user ID with no overt association with the details of the actual user) and Phantom Tokens, where an API gateway mediates the issuance of an opaque token — that is, an access token related but untraceable to a source which holds the user's personal data

Take the necessary precautions

Where the API economy is concerned, following the right strategies will help companies get the most out of its rewards while minimising the risks. Installing an API gateway will centralise traffic features, enabling better control of requests that affect both security and business concerns. A dedicated OAuth server to issue tokens is more secure than tokens issued at multiple points across the system. Combining opaque tokens with JSON Web Tokens will optimise safety and convenience if your system is communicating with both internal and third-party clients. Scopes and claims can allow for coarse-grained and fine-grained access control, respectively; the former defines application level access , while the latter enables fine-grained  user authorization. Using HTTPS for all API traffic — even internally — is an absolute must have today. JWT validation, standardised across the system instead of differentiated across various endpoints, is also recommended, as is JSON Web Key Sets (JWKS) for key distribution.

Every business is different, and so having the right security architecture that is catered toward specific business needs is essential. It is important to understand how architecture can support the different ways of implementing, protecting and securing the business. It is easy for simple solutions to be missed, and common sense to be bypassed. For instance, inconsistencies across authentication methods for the same resource is not conducive to good business practices. This is where a centrally managed solution that developers can plug into is extremely valuable. The ease provided by this service will help to avoid inconsistencies and potential gaps in the system.  As those wanting to abuse APIs can employ sophisticated tactics, conducting internal API audits is crucial to finding structural weaknesses that can become privy to suspicious activity. Processes are continuously changing, and an API that had been built with the intention of being used internally may have been made public without the necessary checks instated. Whilst this may not appear like the most pressing of concerns to fix, the value that APIs provide in terms of speed and scaling to businesses make it a worthwhile process.