Jonas is Director of Commercial Engineering at Curity. His expertise lies in identity and access management, and access control solutions for privileged users, databases and applications.
The fact that the API economy is growing rapidly is no longer news – it’s common knowledge. Many reports now describe a sharp increase in the use of APIs for different purposes. And with the growing use of public and internal APIs, reports also show a sharp rise in API attacks. There is a pressing need to secure APIs, but as most software professionals know, enterprises don’t always prioritize security.
Many non-financial APIs have leaked user information in recent years, including breaches at Tesla, Peloton, LinkedIn, and Marriott. Although this data may seem insignificant, the leaked information could be exploited to launch new attacks, especially phishing attacks in which much more critical user data could end up in the hands of the attacker. With this in mind, securing APIs is not just necessary for banks. Any API, public or internal, needs robust security to thwart the increased level of attacks to protect the information they expose.
At the heart of API protection is a token-based architecture. A legacy approach, on the other hand, which deploys static API keys, is discouraged: if an API key is lost, stolen, or shared, it would need to be rotated and updated in clients using that API. It’s not a very flexible or scalable model. There’s also the problem of getting the API key in the first place. This recovery process must be authenticated in some way, whether a user or a system requests access to the API.
An API can take responsibility for validating an access token used to protect the API. The access token can come in a variety of formats, but a JSON Web Token (JWT) is the most common approach. The JWT is passed in the authorization header when an application or service calls the API. One advantage of a JWT is that it directly contains a set of claims that the API itself can consume to determine or authorize what information to return to the caller. APIs can be developed in many languages, but implementing token validation is similar across the board. Curity provides several code examples for different API implementations that provide a good starting point to help implement this approach.
The downside of using JWTs, at least for public applications, is that they could potentially contain personally identifiable information. It’s usually something you don’t want to share publicly. Instead, it’s much better for a public application to manage opaque (by reference) tokens. This type of token is simply a single string. The API receiving the opaque token can introspect the token by calling the identity provider (IdP). This could, however, become costly for the API to run frequently. A much better approach is to leverage an API Gateway that can handle introspection processing so that the API can use its resources to serve its content instead.
The API Gateway
Placing an API gateway in front of public and internal APIs is a great way to add new security measures. The gateway can limit the rate of API calls based on policies and who is calling the API. Inspecting request payloads for vulnerabilities, such as injection attacks, is usually something most modern gateways can handle as well.
The API Gateway is also a great place to manage API call authentication and authorization. Some gateways have rudimentary capabilities to handle this out of the box, but in many cases using the shadow token approach or the split token approach results in a more secure and robust implementation. The gateway can handle initial verification of access tokens and coarse authorization using scopes. This will prevent the API from performing initial token validation and frequent introspection calls. Additionally, it also reduces unauthorized calls to the API itself. With the Phantom or Split token approach, a public application never needs to contain a JWT. The API Gateway gets the JWT and validates it before sending the JWT to the API itself. At this point, the API can obviously consume the JWT as needed to determine what data to return.
Integrating these patterns with a modern API gateway is fairly trivial. At Curity, we have worked with several gateway vendors over the years and have developed plugins to help with the onboarding process. If an API gateway is part of the architecture, integrating a token-based approach to securing APIs should be a no-brainer.
The developer portal
With the growing number of APIs developed by organizations, there should be a standard way for developers to understand how to use them. This is where a good developer portal is the critical link between the API provider and the developer who needs to use it. We won’t explore the inner workings of a DevPortal here, but a key one is API access management. This usually involves generating a client_id or secret, or managing certificates that can be used to obtain access tokens that will grant access to the API.
The DevPortal is also used to track API usage and can correlate who or what is accessing an API and how often. A token-based architecture can help protect APIs by mapping a specific client_id to a developer (or application). This way, the API Gateway, for example, can determine who is accessing an API based on the token presented. To automate this process, an integration between the DevPortal and the Identity Provider (IdP) using Dynamic Customer Registration (DCR) is usually configured. With DCR, a new client that controls token issuance is automatically generated in the IdP by the DevPortal. This creates a one-to-one mapping between the token distribution and the developer or application. It also allows complete control and monitoring of how the API is accessed.
Another consideration is how a single-page application (SPA) handles access tokens. Managing and storing tokens in the SPA interface has important security implications. SPAs are vulnerable to Cross-site Scripting (XSS) attacks and cannot securely store any type of token. On top of that, browsers are dropping support for third-party cookies, making it increasingly difficult to store, for example, refresh tokens in a cookie if the token service is running on a different domain from that of the SPA.
The Token Handler pattern can mitigate these issues. The Token Manager provides components that can be integrated with the API Gateway. The SPA will only communicate directly with the token manager instead of directly communicating with the token service to obtain tokens. The token manager is responsible for token management and will issue secure SameSite cookies to the SPA used for authentication and authorization.
The token manager would be a plugin on the API Gateway or API Proxy. There are more details about the token manager in this overview and a working example in this article “SPA using the token manager model”.
Not just for banks
The API economy has exploded and continues to grow. With this, securing APIs no longer has to be an afterthought. API security isn’t just for banking apps. A robust token-based architecture must be implemented from scratch in any new API project to achieve the highest level of API security. This, along with an API gateway and a good DevPortal, will protect the API and make it easier for developers to use the API. For SPAs, consider using a token manager built into the API Gateway or API Proxy to avoid managing tokens directly in the SPA vulnerable to XSS attacks.
Featured image via Pixabay.