You’ve probably heard some conversation about passwordless authentication in recent years – tech industry leaders have lobbied to make it standard practice in consumer web applications for over a decade. 

Even if the idea of passwordless auth is new to you, it’s hard to work in the tech industry in 2023 and not be aware of the cyberattack at LastPass. For many people, tech industry professionals and average consumers alike, it was a wake-up call. Not only was it an enormous data breach — over 30 million users’ passwords were compromised — it was initially caused by password theft.

If even password managers can’t safely manage login credentials, what does that mean for the rest of us? Perhaps NOW is the right time for passwordless auth to take its place in the spotlight.

From a consumer perspective, it’s definitely time to take steps to safer password management practices. 

Application developers have a clear imperative to change their auth models. Browser-based passwordless auth is easier than ever, and consumers are ready for better security practices for their most sensitive online activities.

But what about API teams? Browser-based auth practices aren’t going to revolutionize practices for teams that work and live in the data layer, but there are still some important takeaways for API developers and product managers. 

Leave Room For Human Imperfection

It might sound like advice from a therapist, but anyone interested in cybersecurity needs to heed this warning: People are going to mess up, and you can’t stop them – but you can change your environment to make mistakes less damaging. 

We’re not here to blame users, though! The impetus is on product teams to:

• Assume your users are fallible human beings –  because they are!
• Design systems that remove opportunities for error.
• Protect resources so that mistakes have the least possible impact.

Secure design, whether for consumer-facing apps, developer-focused APIs, or anything in between, must shift the burden for security away from individual users. The OWASP Top Ten gets a lot of attention, but planning for the human element of cybersecurity is more important than checking any item on that list. At least 80% of cyberattacks involve human error. And yes, following the OWASP principles will help insulate you from those errors – the principles exist to serve the people creating and using technical products. 

Use Passwords & API Keys Intentionally

Passwords are especially vulnerable to human error because, in terms of security factors, they are “something you know.” API keys are similar – does that mean we should be getting rid of them, too? Fortunately, the answer to that is no.

It’s not likely we’ll ever fully replace passwords. Using cryptographic keys or MFA to secure your wifi would be a pointless hassle – it’s a low-value target that needs to be accessed by multiple people and devices and is mostly vulnerable when it’s stretched across too many users simultaneously. A password is perfectly fine.

API keys also have appropriate uses. Consider a free weather data API. An API key is mostly important for rate limiting and usage metrics, and a heavier auth method wouldn’t pay off. It’s a similar set of constraints as a Wi-Fi network – the downsides of unauthorized access are very low, providing ease of access is important, and the most important risks come from spiky traffic volumes or DDOS attacks. If that describes your API, feel free to use rate-limited keys!

But once any proprietary data or financial information gets involved, it’s crucial to start asking questions about secure design. How do API consumers access their key in the first place? Is it secured behind a password-based auth method? Is the API key connected to any financial data or personally identifying information? Is any sensitive data held on the same server that hosts the public endpoints? Relying on your API consumers to manage these risks appropriately is not ideal.

Aim To Be Secure By Design

The momentum to “shift left” on security is going strong. In many cases, that means shifting to a “DevSecOps” model, integrating security into automated processes from the very start of the development lifecycle. It’s a practical shift and a cultural one – security isn’t an afterthought or an impediment, but an integral consideration at every stage. When done right, DevSecOps is more secure and more efficient.

DevSecOps approaches can fall short when they lead dev teams to think of security as primarily an operational concern. The operational issues are important, and we’ll touch on those a bit more below – but the mandate should be to be Secure By Design. That means designing every aspect of your product and process with security in mind.

Designing for security goes hand-in-hand with human-centered design. Whether you’re looking at the architecture of your data layer, how you implement security practices in your code linter, or what auth protocols you use for different resources, the goal is to limit the possibility of human error and minimize the damage when someone inevitably makes a mistake. 

Beware of the Man in the Middle!

One of the most common exploits for stealing passwords and other sensitive data is a “Man in the Middle” attack. This is one area where application developers are waking up to what most API developers already know: encryption is essential! 

Where APIs (Mostly) Get It Right: TLS

At the very least, no one should be transmitting any data over an unsecured HTTP connection in 2023. By now, HTTPS For Everything is a settled matter. Most API communications should probably be secured with some kind of additional encryption. In most cases, TLS is a good choice. 

WebAuthn, the industry-best browser standard for passwordless authentication, uses the same encryption method as TLS:

• Initial authentication via a public/private key pair, known as asymmetric encryption. 
• Symmetric encryption for all data transmitted during the session.

WebAuthn is not the same as multi-factor authentication, and it’s important to note that part of the reason MFA/2FA approaches have lost favor is the lack of encryption. SMS messages, a popular option in many MFA flows, cannot be encrypted, and are easily intercepted because the cellular network was not designed for security. 

You can still use a smartphone as part of a WebAuthn flow. On any device with a Certified Authenticator, you can generate a public/private key pair and register it with the application or service. The private key never leaves the device, and data encrypted with the public key can only be decrypted by the private key and vice-versa. The relevant data is transmitted in JSON objects.

Where APIs (Sometimes) Get It Wrong: JWTs

If this sounds familiar to you as an API developer, it may be because you’ve worked with JWTs before. Much of the data flow with WebAuthn is similar to JWT auth. JWTs aren’t perfect, and the differences between WebAuthn and JWTs show why. 

One source of risk with JWTs is that the tokens are difficult to revoke before their pre-set expiration. While a token is valid, the client application controls the session. Even if the client starts to perform questionable or malicious actions, the server cannot terminate an individual token. That makes JWTs a poor fit for session-based auth, even though it’s a common practice. In contrast, WebAuthn allows client and server applications to terminate the authentication at any time. The client application never handles a key directly but must have an encrypted valid attestation to complete any requests. By revoking the public key, the server can force a new registration at any time. 

The second difference worth highlighting is encryption. In a WebAuthn application, all traffic is encrypted with the sole exception of the public key during the registration ceremony. It’s possible to encrypt all communications in a JWT auth flow, but this behavior isn’t the default. Unless you opt to use JSON Web Encryption (JWE), JSON tokens are signed but unencrypted. The signature protects messages from tampering, but not from interception via a Man-In-The-Middle attack. 

While none of these options are inherently poor, except perhaps SMS 2FA, the takeaway for API teams is to be attentive to what gets encrypted and when it happens. There are costs to using full asymmetric encryption for all requests, but there are situations where it’s worth the investment. In finance and healthcare, regulatory guidelines will tell you when you need encryption in transit or at rest. But even in less regulated industries, you need to be careful to choose authentication and encryption protocols that will properly protect your data.

Treat Front-End Applications as Top-Tier Security Concerns

One of the most valuable attributes of a great API product is that it is client-agnostic. If you are building an API, you no doubt have some specific use cases in mind – but API consumers are going to do things you never expected, often with impressive results. While this creativity can cause some problems, it’s important for API product teams to prioritize safety while allowing room for graceful mistakes and fostering flexibility. 

Some API teams may be inclined to view the client apps that consume their APIs as an afterthought or an unknown quantity. But being client agnostic doesn’t mean you can afford to be agnostic or lax about front-end security. Those client applications are a gateway into your API, and you need to build in guardrails to keep traffic on a safe path. 

Support Backend For Frontend With Tailored APIs

The last fifteen years have seen a mad rush toward single-page applications and, more recently, some steps back from the brink. One reason for the retreat is that SPAs have a very large attack surface and a lot of potential locations for back-end logic and data to sneak into the front end. 

One design pattern that strikes a better balance of client-side complexity and data security is Backend For Frontend. API product teams can be a powerful partner in enabling BFF, which is a variation of the API Gateway pattern. While an API Gateway centralizes the connections between client and server in a single access point, BFF creates a coordinating layer specific to each client, reducing bloat and limiting front-end exposure. 

APIs that are successful components of BFF architectures need to follow some best practices:

• Work backward from UI/UX needs to tailor data and auth methods to different platforms
• Segregate generic methods from client-specific data
• Design endpoints around features and Jobs To Be Done to limit unnecessary data exposure
• Follow the Rule of Three to reduce duplicate code, especially at public endpoints
• Use industry-standard open-source technology for encryption and auth

Most of these practices will pay off regardless of the architecture your clients are using, but the more you can center your designs around real-world use cases, the better you will be able to create API products that are both secure and flexible.

Rigorously Enforce Data Segregation

The most important thing API designers can do to support more secure client applications is to store as little sensitive data as possible, in as few locations as possible. One reason passwordless auth is something of a Holy Grail is that it involves as little data exchange as possible – you can actually have authentication without even transmitting a username, and client applications never handle any auth credentials at all. What would that level of rigor look like if you extended it to your data layer?

As with encryption, some industries have clear standards for data segregation. Additionally, any companies looking to do business in the European Union need to follow the General Data Protection Regulation, or GDPR, which requires proper data segregation. Even if these factors don’t apply to you, logical and consistent data segregation practices will help you create the buffer we keep talking about! 

Human error is inevitable – but if you limit the amount of sensitive data in any one place, you’ll limit the fallout from those mistakes. 

Secure Your Development Processes

You’ve done your best to make your API secure by design. You’ve worked with your customers to understand their needs and support them in building secure front-end applications. You’ve read and re-read the OWASP Top 10. You’ve moved to secure MFA or passwordless auth for your personal accounts where you can. But there’s one more area we still need to talk about.

The LastPass incident that unfolded in the fall of 2022 and winter of 2023 began when a malicious actor intercepted a master password. Only four people had knowledge of that password, but it was likely not difficult for a motivated hacker to figure out which employees might be worth targeting. A bit of social engineering can quickly lead an attacker to high-value phishing targets. If those people are using insecure authentication methods, an enormous amount of damage can be done very quickly.

How are you approaching security practices for your internal teams? How are you screening vendors? What are you doing to ensure against social engineering and phishing attacks on your key employees? 

If your production systems are not secure, your product is not secure. Secure by design includes securing your design assets, design tools, and designers’ access credentials. Human error will happen. Passwords stink. 

The challenge for the technology industry is to keep supporting collaboration and innovation – hallmarks of the API economy and the goals of great API products – while simultaneously making security a top-level feature and design priority. The good news is that the knowledge and tools you need are out there, and partners like Stoplight and Smartbear are here to help you put them to use.