Crank-Up Your API Security with Sender-Constrained API Tokens

The average API provider has not prioritized the implementation of good API security because API security is misunderstood, and good security in general is not easy. Sometimes, the perceived cost is greater than the perceived risk. As a result, many organizations are at an increased level of vulnerability to cyber attacks. When API security is too ‘basic’, attackers find their way through, in particular by phishing users and finding leaked credentials.

Bearer tokens are practical but dangerous

Basic bearer-style OAuth tokens are common use because they are practical. But when they leak, are stolen or just used outside the client-side application boundary, they are a serious security risk. Sender-constraining tokens is the practice of reserving the use of an OAuth token for the original API client (the sender) to which it was issued. This validation requires the client to prove possession (PoP) of a cryptographic secret via either mutual TLS (OAuth mTLS) or application-layer signing (DPoP). This proof is required in addition to the token but is also correlated with the token itself.

There have been many attempts over the years to normalize this pattern to improve API security but the required coordination can be difficult. To facilitate this, the OpenID Foundation standardizes the required specifics under Financial-grade API Security Profile Advanced (FAPI Advanced). A common misunderstanding is that FAPI is for the financial sector. If you are looking for guidelines to improve your API security in general, FAPI is applicable to any industry – from the spec:

“The Financial-grade API is a highly secured OAuth profile that aims to provide specific implementation guidelines for security and interoperability. The Financial-grade API security profile can be applied to APIs in any market area that requires a higher level of security than provided by standard OAuth or OpenID Connect†– OpenID spec.

Even with the best possible standard in place, sender-constraining tokens will require work. Implementing sender-constrained tokens and proof-of-possession whether leveraging mTLS or DPoP, requires changes not only at your OAuth authorization server (e.g. identity stack) but more importantly in your API resource server (e.g. API gateway). In fact, the number one security consideration of the spec is about the uncertainty of resource server handling of access tokens. In other words, it counts for nothing to support FAPI advanced in the OAuth layer if the API does not enforce it. The spec is clear: to be conform requires the resource server to enforce the constraint.

Turn on FAPI Advanced using OTK

To make this easier to implement in Layer7 deployments, we provide FAPI support in our OAuth toolkit (OTK). By setting otk.fapi_advanced.enabled to true, you can raise the security of your API and apply sender-constrained OAuth tokens to all APIs protected by Layer7. Another advanced feature of the OAuth toolkit which helps increase security and improve the user experience is the support for the Client Initiated Backchannel Authentication (CIBA) scheme in which the authentication is fully decoupled without any redirection. If you are using other API management solutions, check your documentation and/or communities to learn about how your solution supports FAPI.

News flash: API security is not new. To some, it seems like a new thing because of recent awakenings about the serious lack of security applied to existing APIs out there. But despite the trend, the practice of API security itself is not a recent invention. Still, after over 20 years into it, we keep working at it because:

• The APIs we protect are evolving
• The API threat is becoming more sophisticated
• The APIs are deployed at larger scale

Next month, I will be presenting at API World on the topic of API security where I will demonstrate sender-constraint and other API security patterns. See you October 26 for Facets of API Security in an Era of Weaponized AI.