APIs have changed drastically since 2010, when many of the best practices and accepted wisdom we currently employ were first put into place. Jacob Ideskog, CTO of Curity, compares this architecture to “the onion,” due to the concentric rings of firewalls, networks, and servers. The trouble is that the onion is incredibly difficult to implement in a decentralized world of mobile devices, cloud servers, and microservices. This evolution calls for a drastically different approach to API security.

This was the topic of a talk Ideskog delivered at Platform Summit 2024 titled How to Build a Fortress with the Security of a Tent. Here are some essential takeaways from Ideskog’s talk to implement into your API designs.

Adopt Token-Based Architecture

Ideskog launched into his talk in earnest by discussing the evolution of APIs following the boom of mobile devices circa 2012. The beginning of decentralization saw the rise of token-based authentication like OAuth 2.0. Token-based architecture is the key to many security issues discussed throughout this presentation.

Ideskog identifies two types of tokens. The first is called a Bearer Token, and it can be used like money found on the ground. The second is called Holder of Key (HoK) or Proof of Possession (PoP), which requires the API server to verify that a user is who they say they are. Ideskog advocates strongly for HoK and PoP and spends much of the remainder of the presentation explaining how to put this architecture into effect.

Token-based architecture is also an essential component of zero-trust architecture, which is increasingly prevalent in a world so widely dependent on cloud-based architecture and microservices. Otherwise, an unauthorized user who gets access to a Bearer Token could gain access to an entire network.

Know Your Audience

APIs are much more widespread than they used to be. They’re no longer limited to HTTP requests and JSON objects. Instead, APIs are a vital component of single-page applications and mobile applications as well as traditional websites. This is good news for API developers, who want as wide an audience as possible, but it raises concerns about API security.

This raises the concerns of “tents,” which is the nickname Ideskog gives to other APIs and third-party applications interacting with an API. API developers need to ensure these tents and their APIs are secure, as an API ecosystem is only as secure as its weakest link.

Integrate FAPI

Ideskog mentions several different use cases that require APIs where identity is especially important. He starts by mentioning Financial-Grade APIs or FAPI, a protocol that requires the use of JSON Web Tokens (JWTs). FAPI also allows API designers to enable different access levels, from baseline to advanced profiles and permission granting. It also offers the benefit of acting as an additional abstraction layer between a user and the end resource, making it uniquely suited for financial transactions.

Embrace Decentralized Identity

Simply securing an API with anonymous tokens is often not enough. Without adopting what Ideskog calls Proof of Possession or PoP, someone could get unauthorized access to an authorization token, which could give them “the keys to the kingdom.” He advises several methods for integrating identity management into your API authorization. The first he recommends is called sender-constrained tokens, which tethers a user to the mutual TLS connection between the client and the authorization server.

The second, which Ideskog talks about in much greater detail, is the token-handler pattern, which he also calls backend for frontend, which solves the bulk of the security issues caused by single-page applications and mobile applications by attaching a simple backend. This solves the identity problems by restoring the ability to use cookie-based authorization.

Avoid Authorizing In the Browser

Browser-based authorization became popular with the rise of single-page applications and mobile apps. The browser is susceptible to all manner of security vulnerabilities. Ideskog even goes as far as to say, “the browser is a hostile environment.” Cross-site scripting (XSS) allows attackers to gain unauthorized access by injecting a few lines of JavaScript into the browser. In one example mentioned during Ideskog’s talk, an attacker was able to copy an organization’s entire backend using two simple image tags.

That’s just the beginning of the troubles XSS can cause. Once someone gains unauthorized access, they can issue new tokens and refresh existing ones. To make matters worse, XSS can be nearly impossible to trace as the system is being accessed using official tokens.

Ideskog goes on to warn about blind submission, an attack where malicious code is entered into a form that is later executed. Eliminating the browser from the equation removes virtually all of these vulnerabilities.

Harden Your Mobile Applications

Ideskog concludes his presentation with some words of advice on how to make mobile applications more secure. As he notes, mobile operating systems have tools for securing apps. Developers simply don’t use them. He recommends using a feature called attestation, which is available for both iOS and Android, which uses a mobile device’s hardware chip to validate transactions. Once your mobile apps are secure, you can take full advantage of APIs with a clear conscience.

Final Thoughts on Building a Fortress with the Security of a Tent

An API is only as secure as its weakest link. Once an API is in use, any user not practicing proper security protocols can put your entire organization at risk. You could even be held responsible if your API is involved in any way with a data breach. By implementing the strategies recommended by Ideskog, you can take full advantage of the exploding API market while ensuring business users and customers are secure.