Protecting against API Token and Credential Theft in 2024
This article is part of APIFutures, a distributed, creator-led effort to identify the most significant opportunity and/or the greatest challenge facing the API community in 2024. You can check out other articles and viewpoints on the APIFutures landing page.
These days, most organizations building digital solutions use an API-based architecture since APIs can serve secured data to various clients. Organizations provide APIs for business partners and also for their own web and mobile apps. To call an API, these clients must get an API message credential. Users commonly must authenticate to obtain such a credential before using the application.
In 2024, cyberattacks against APIs are a major concern, and organizations need a solid design to protect against these threats. By default, if a malicious party obtains an API message credential, it can be used to access secured data. To prevent data breaches, organizations need up-to-date API protection. For this, they should follow best practices and use strong security when possible.
Use the OAuth 2.0 Authorization Framework
The OAuth 2.0 authorization framework is centered on protecting APIs and ensuring least-privilege access to data. Clients receive access tokens as unforgeable and locked-down API message credentials. These access tokens can be protected using proof-of-possession techniques so malicious parties cannot replay stolen tokens.
Using OAuth 2.0 involves integrating an authorization server that issues the access tokens. Security specialists provide this component, which enables advanced security capabilities. Yet choosing the best OAuth 2.0 features for the various API, client, and user scenarios requires insight. This results in multiple best practices. At Curity, we recommend the following options.
Require Proof of Possession for B2B API Clients
When providing APIs to business partners, using proof of possession access tokens based on the RFC 8705 standard is relatively straightforward. This approach utilizes the underlying secured communication channel to bind an access token to a TLS client certificate. The client, or business partner application, must then present the access token with the corresponding TLS client certificate in all subsequent API requests.
This working example shows how to get integrated. The business partner can create their own client certificate or request one from the organization that provides the APIs. The certificate is then configured in the organization's authorization server. If required, forward and reverse proxies can terminate the mutual TLS connection to avoid any code impact on clients or APIs.
Use the Strongest Cookies in Browser API Clients
For browser-based applications, the browser is the ultimate client. It is not usually practical to issue each end-user with a client certificate to install in the browser. Consequently, using certificate-bound access tokens may not be considered suitable. Yet organizations still need to protect against token and data theft.
The primary threat for browser-based applications is cross-site scripting (XSS), where malicious code can potentially exfiltrate tokens and data from the browser. Therefore, organizations should avoid storing tokens in the browser. They are best advised to use a backend for frontend (BFF) that issues the latest and strongest secure cookies to the browser. As a result, the browser-based application sends HTTP-only, SameSite=strict cookies to APIs instead of tokens. Although this does not eliminate XSS threats, it reduces their impact and prevents tokens from being exfiltrated from the browser.
The token handler pattern provides a design that manages web threats while maintaining all of the best features of a single-page application architecture. The BFF can optionally use a client certificate to receive certificate-bound access tokens. Although requests from the browser itself do not provide proof of possession, a BFF enables the best all-around security.
Use Attestation in Mobile API Clients
Traditionally, OAuth-secured mobile apps use the RFC 8252 standard (OAuth 2.0 for Native Apps). In this case, the mobile app opens the system browser to authenticate the user, which forwards the authorization code to the app that exchanges it for tokens. As for browser-based apps, it is not usually practical to issue each end-user a client certificate to install on their device to enable certificate-bound access tokens.
OAuth-secured mobile apps are public clients. A malicious app could potentially impersonate the actual app and get tokens. The best mitigations are to use HTTPS redirect URIs and proof key for code exchange (PKCE). Yet the refresh token is unprotected. If a malicious party manages to steal the mobile app's refresh token, it can use it to get new access tokens.
Mobile capabilities have progressed since RFC 8252 was published in 2017. These days, all mobile devices are issued with a hardware-backed key that can be used to digitally sign material to prove a client's authenticity before authentication begins. The device key can enable a hardened mobile flow that prevents impersonation and protects the refresh token.
Implement Zero-Trust Backends
APIs need to apply business authorization and should do so by using secure values received in access tokens. In a zero-trust approach, APIs do this for all requests, regardless of whether the caller is internal or external. The Implementing Zero Trust APIs article overviews the main techniques required to validate access tokens, apply claims-based authorization, and securely share identity values between multiple APIs.
Cloud-native platforms provide additional infrastructure security that can further harden the security of an application. Solutions like Secure Production Identity Framework for Everyone (SPIFFE) enable each backend component to receive a workload identity, along with a key pair for proving that identity. This enables backend APIs and databases to require mutual TLS, where the connection provides proof of possession of a workload identity. This ensures the confidentiality of internal requests and restricts the allowed callers.
Add Cryptography-Backed User Authentication
Even if APIs and clients are implemented with strong security, a major threat is account hijacking. If users log in via passwords, there are several problems. Server breaches have the potential to reveal passwords for many users. Passwords are also vulnerable to phishing attacks. Finally, passwords provide an awkward user experience, especially on mobile.
Therefore, in 2024, it's a recommended practice to add passkey authentication to your login options. This hardens logins by requiring strong authentication based on cryptographic key pairs. It also provides a simple user experience. When required, roaming users can register multiple passkeys against their user account. Passkeys can be used in conjunction with email-backed account recovery. Even if a device is lost, the user can recover by proving ownership of their email address.
Strong authentication must be accompanied by solid API access afterward. As such, OAuth clients should never implement authentication directly. Instead, they run a code flow where the authorization server coordinates the authentication workflow. After the user signs in, the authorization server issues the client a least-privilege access token to minimize the client's access to APIs.
Conclusion
The best designs for protecting against security threats require an understanding of APIs, clients, and the environments in which they execute. For some types of connections, proof of possession can be used, whereas for others, the best practices may differ.
Investing in components that enable a modern token-based architecture is the best way to manage security. Once the building blocks are understood, the same security patterns can be used in many other use cases. This includes securing supporting components, such as those used to manage the software supply chain.
When applied correctly, this approach enables a future-proof platform. Complex security code is externalized so that only simple code is needed in business-focused components. Support for new security capabilities will frequently be enabled by upgrading the authorization server. Designs, therefore, scale well to many APIs and their clients to enable your digital solutions to grow securely.
