Some APIs require tighter governance than others. For example, API providers working in healthcare, banking, or government must often comply with regulations prohibiting the sharing of sensitive data. Yet, the sudden ubiquity of APIs isn’t always managed safely, causing security concerns around data access.

The explosive growth of APIs and microservices has resulted in a number of potential vulnerabilities, according to Michal Trojanowski, Product Marketing Engineer, Curity. This is especially alarming to sensitive domains but is quickly affecting other areas too. Rectifying this issue will require truly military-grade protection, requiring a total mindset shift.

Attend Platform Summit 2023 to catch Michal Trojanowski’s talk on identity-related API security.

Ahead of this year’s Platform Summit 2023, we’re interviewing some key speakers to dig into their upcoming sessions and collect their opinions on the API industry.

Michal Trojanowski, one such Platform Summit speaker, has spent over ten years working as a developer in various technologies and has a wealth of knowledge about identity and security-related topics. At Curity, he helps people better understand authentication, OAuth, OpenID Connect, and JWTs.

Below, we’ll reprint some thoughts from Trojanowski on the state of API security and the identity-related standards and OAuth extensions that you’ll want to deploy, a theme of his upcoming session.

What is the state of threats against APIs, as you see it?

I don’t want to sound too fatalistic, but I don’t think we’re in a good spot right now. On the one hand, we’ve seen an explosion of APIs in the last couple of years. Everyone is creating APIs, creating microservices that talk via APIs, and exposing APIs. And these not only expose business data but also access to an organization’s infrastructure as needed by administrative tools.

All these recent APIs were (and still are) created hastily, which in many cases negatively impacts the security of these solutions. Developers often don’t have enough time to learn and understand the technologies they are using, and decisions are made that hamper security.

On the other hand, we’ve only recently found ourselves in a completely new environment with generative AI writing code for us. Sadly, this powerful generative AI is also used to facilitate and accelerate the coding of scripts used to attack APIs.

So, we have much more data exposed via APIs that are coded hastily, without proper care, and we have tools that facilitate creating sophisticated scripts to attack these APIs. Unfortunately, this doesn’t look very good.

What makes specific industries more sensitive to API attacks? What sort of data or privileges are under threat?

I wouldn’t say that some industries are more sensitive to API attacks but to attacks in general. Financial institutions or some government agencies will always be a more juicy target for hackers than, for example, libraries or online crafts shops. Many organizations that represent the more sensitive areas only recently started to expose their products and services via APIs (banks in some regions have only recently been required to expose APIs to adhere to regulations), and in this sense, it makes them more vulnerable to API attacks.

With the growing information warfare, I see a rising threat to other industries that were previously not that susceptible. These attacks are often not to make some illegal gains (as is usually the case when attacking financial institutions) but to sow disinformation.

This demonstrates that more industries should now pay more attention to tighter security of their APIs. Apart from the usual sectors like finance, health, and government, I also believe that news outlets and non-governmental organizations (NGOs) should be on alert. Organizations should also understand that API attacks might not always be about stealing data or resources but also about gaining unauthorized access that allows modifications, such as planting fake information.

What are OAuth flows, and why must we extend them for these sensitive areas?

OAuth flows are procedures in which applications (OAuth clients) get access tokens from the authorization server. OAuth introduced a few different flows (authorization code flow, implicit flow, resource owner password flow), but nowadays, we should use the authorization code flow for the most part.

OAuth has the benefit of being a well-established protocol that has been around for a while now. But this also has allowed us to identify the vulnerable parts of its flows. Therefore, we need extensions to patch these vulnerable parts.

Still, these patches are sometimes useful only in certain scenarios or industries. That’s why many of them are still treated as optional extensions and don’t have to be used in every case.

What is the end benefit of this focus on hardening API security?

Very often, the extensions of the OAuth protocol help us mitigate concrete attacks or vulnerabilities. For example, when we introduced the Proof Key for Code Exchange (PKCE) extension, it had a very concrete goal — to protect from attacks where one mobile application would steal the authorization code from another to get the victim’s access tokens.

It is now recommended to use PKCE with every code exchange as it has proven to strengthen the security of the code flow. So the end benefit here is to help achieve overall better security through patching concrete vulnerabilities of OAuth.

Why are you excited about the Platform Summit 2023?

I’ve been to the Platform Summit twice before, and it has always been a very good experience with interesting sessions and inspiring informal conversations. Going to the next Platform Summit would have been exciting even without the three-year break. Now the hype is even larger.

Without giving away too much, what will you be speaking about at Platform Summit 2023?

I will be speaking about some of the OAuth extensions that can help make the flows even more secure. Many people are familiar with mutual TLS (mTLS), but I would like to show how it can be leveraged to create more secure access tokens. I will also explain specifications like Pushed Authorization Requests (PAR) and JWT Secured Authorization Response Mode (JARM) so that they are not just cryptic acronyms anymore.