Secure your Apps and APIs with strong authentication and Adaptive Access

I am John Gren. I’m a product owner for API security at Gravitee, a full solutions company offering full API lifecycle management and access management.

This article will share insights into managing API security for open banking. The article will also look into how to offer and customize different authentication methods for customers using an access management solution.

As per State of API Security, Q1, 2022, “API security incidents affected 95% of organizations in 2021, but 34% of these organizations also lack an API security strategy”. This shows that in 2021, 95% of companies were affected by API security incidents.

This is a high number, but it is expected as APIs are important and used by many organizations.

What’s worrying, though, is that 34% of these organizations also lack an overall API service security strategy. This means that businesses’ and people’s data integrity might be at risk without proper API security governance.

History – Open Banking and API Security

Open banking has many sides to it. It’s a set of technologists in some parts of the world a bank regulation, but more importantly, it’s a global movement to open up financial data, find new streams of business and allow customers to take control of their financial situation. Around 2008, this concept was very immature in its security nature. So innovative FinTech companies found business areas and needed to access the customer’s financial data the same way the customer would. But of course, due to limited technologies, the results were credential sharing and screen scraping, meaning customers needed to share their passwords to banking services to use FinTech solutions. This caused problems within the banks and the FinTechs since the banks could be unaware of the FinTech solution. This, along with technological limitations, caused unreliable services to break easily.

Then, the movement around open banking grew to find a way to offer access to customers’ financial data in an agreed secure and reliable service interface. The parties involved in open banking are the bank or the account servicing payment service provider with its core item system, the consumer as the data subject, or the payment service user and third-party providers. Good open banking is fuelled by the APIs, exposed by the banks allowing FinTechs to develop solutions. This ecosystem needs to rely on open standards for APIs and the authentication and authorization of both consumers and third-party providers calling the read and payment APIs to be authorized to interact with consumers’ financial data with their consent. To achieve this, we need to authenticate consumers securely, collect consent when making transactions, securely authenticate third-party providers, and manage threat protection and rate limit policies.

Security with Identity and Access Management

To securely manage identities and access across your ecosystem, you need to centralize this with an access management solution, relying on open standards when identifying users and fetching data through APIs. The technology protocol used to authorize and authenticate users securely is OAuth 2.0 and OpenID + FAPI for Open banking. This allows you to challenge users with well-known authentication access services and then pass on the user delegation so that apps call APIs on behalf of the users passing along signed-off tokens containing delegation rights and user attributes. The Open ID Foundation has also developed an industry-led common security protocol for financial services called the Financial grade API or FAPI. Using these solutions gives you a lot of benefits, such as confidence. There’s no passing of passwords since the authentication is done in the Access Management System. You’re getting customer retention and inclusiveness, as having multiple accounts and password is a problem for users.

By centralizing access management, you have full control over which authentication method you present to the user. This also gives you inclusiveness to offer well-known methods that customers are familiar with. One area where this is well implemented is within the European Union and the electronic identification, authentication, and trust services for the EIDAS regulation. With this, public sector authorities or financial institutions under the PSD can comply with the identity federation. So this means that organizations will be able to present national identity methods for login and signature from European countries, making it easier and safer to onboard new users and use services across the EU, regardless of nationality. You also get reduced IT costs because communication between the user application and the API relies on a standard protocol. You don’t have to go through the process of redesigning your IT environment if you want to introduce a new authentication method. It’s also less prone to errors in transactions.

OF2 also has a built in support for consent making sure the consumer is well aware of the decisions and that the action can be traced back irrevocably. So by establishing your identity and access management solution, you get full control over who can access your apps and APIs and what they can do. You can prompt users with strong authentication methods when needed, such as for payments.

Modern strong customer authentication

Modern strong customer authentication methods are more commonly known in the access management world as MFA. MFA stands for multi-factor authentication. The purpose of MFA is to be confident in the user’s identity and remove the risk of lost passwords. It is said that MFA can block over 99.9% of account-compromised attacks. MFA works in a way that adds an additional factor to the authentication process. It should be based on the following elements: knowledge, possession, and inheritance. So knowledge refers to something the user knows, like a password or a pin. Possession is something they own, like a subpoena a USB security key, or a mobile device. Inheritance indicates something that they use – fingerprint or facial recognition for biometric authentication.

One technology becoming an industry standard for strong authentication on the web is FIDO2 or a web button browser. It is a browser API that lets the user choose the device that fits them best, such as a UBKey, or facial recognition on your mobile device. However, MFA requires extra steps to authenticate with, which may affect the customer convenience, and all data might not be sensitive and need MFA for protection.

Adaptive Access

Adaptive access lets you tailor your authentication flow in the access management solution, prompting additional factors only when needed. The common flow is adaptive MFA, step-up authentication, and remember device,

• Adaptive MFA – considers users’ contextual information and prompts MFA if the confidence about the user’s identity is low, such as the number of login attempts and successfully providing the correct password.
• Step Up authenticationcan allow the user to access that with a less secure authentication method but prompt MFA if a static rule applies, such as the user initiating a payment.
• Remember devicelets the user remember the device in the access management solution as a trusted device. It’s for user convenience and not to have to provide multi-factor authentication every time they log into the service.

All of these policies can be used together. So it’s very important to understand the order in which the policies are executed when designing your MFA flows in your access management solution.

Step Up authentication

We can imagine that we have an app that gets access to two different APIs, the Balanced API, and the Payment API. To give you a simple overview, the user secured at first login with a username and password for convenience. This could mean that the user can only access the balance API. If the user wants to make a payment, the app would need to trigger a step-up authentication request to the Access Management Server. And once the user has been challenged with the multi-factor authentication, the app will get a callback with a new valid token with elevated privileges that can be used to access the payment API. The building blocks for Step Up authentication are available in OAuth 2 and Open ID Connect.

Intelligent API Security

Traditional app and API security have their shortcomings. It relies heavily on authentication, authorization, and applying rate limits or throttling in an API gateway. But the malicious attackers are far more elaborate than just generic policies. This, together with an API gateway typically not equipped with enough computing to do real-time analysis of API consumers, requires something more. So the future of API security is intelligent API security. It focuses on real-time analysis of both users and API consumer behavior. So it’s using machine learning to ingest logs from your API ecosystem, map out common behavior patterns and find deviations and anomalies because the normal pattern for one API consumer might be considered malicious for another. So you need to have granular intelligent API security to find the threats before a cyber attack.

The Gravitee.io platform

At Gravitee, we continuously look into how to evolve within API security seamlessly integrated across your API ecosystem. Gravitee offers a rich, open-source platform with both API management and access management, free to start using and fully financial grade API certified, open source, and full of potential, just like open banking. If you want to enhance your API governance, Gravitee extends and offers capabilities within alerting security overviews and API designs so that you can design your open banking APIs in an effective collaborative tool, making sure you design sustainable APIs that can be reused across your third party providers and across your internal FPS apps. In our modular architecture, we also offer a marketplace with plugins to ensure you can browse and find plugins fitting your industry and needs. For full API governance, Gravitee comes top with Cockpits. It is an overview tool that lets you fully view your gravity installations across regions and business areas.

For open banking, UK FinTech Tide uses the Gravitee API platform for full API lifecycle management and security by using access management with Phaedo to end biometric authentication.

Recommendations

• If you’re a bank in a non-regulated market, don’t wait for open banking to be regulated. See it as a new product and a new revenue channel.
• Build your open banking success on open standards for APIs and ensure you manage them through an API full lifecycle management solution.
• Put App and API Security first by establishing a reliable Identity and Access Management Solution, API threat protection, and Alerting.
• Lastly, not everyone has simple and secure control over their financial data – contribute and keep Open Banking Secure.