/images/resources/neo_security/curity-token-patterns.png

Elevating API Security and Resilience with Token Patterns

On this page

Few companies these days don't use APIs. They're often used as an external interface to connect frontend applications and partners to their services, other times solely internally, to connect the growing number of services in a network that comprises the company's ecosystem. Even though most organizations use APIs, there are different approaches to securing access. The API security maturity model describes how companies can utilize different techniques to ensure access to their APIs is secure, and it mentions tokens as a sign of mature API security.

More and more organizations use token-based security with frameworks such as OAuth or SAML, which provide tokens that act as strong message credentials that a recipient can verify. Yet, a message credential alone is insufficient to secure complex systems. Instead, you need an API credential whose attributes you can customize, to grant permissions to resources.

In this article, I will describe token patterns companies should use to get the most from securing APIs with tokens.

What are Token Patterns?

While frameworks like OAuth or SAML provide solid basics for protecting resources with secure credentials (tokens), they do not solve everything. Token patterns provide organizations with tools that allow them to utilize tokens in a way that creates more secure APIs and more robust integrations.

Token patterns enable you to change the confidentiality, privileges or strength of access tokens depending on the particular API and API client. You can even potentially exchange tokens from one token issuer for another, to enable interoperability in federated scenarios, or when migrating from an old to a new token issuer.

Issues of Token-based Approaches

Systems protected with access tokens are still vulnerable to attacks, even when they correctly implement standards like OAuth. These attacks can come from both external and internal actors. Companies should consider both threat groups when designing security measures.

External attackers will try to steal or misuse access tokens to abuse the company's APIs. For example, an attacker may be able to sign up to an application with a temporary email address, then send the application’s tokens to unexpected endpoints. When an attacker manages to steal a legitimate access token, they will be able to call APIs and thus will harvest the company's data. The breach will worsen if tokens are issued with more privileges than a front-end application actually needs to operate. It allows the attacker to get even more data than they would by taking over the user's application.

Companies often focus on protecting against external actors penetrating a company's perimeter defenses, but usually spend less time thinking about internal threats. A malicious actor may manage to breach the perimeter. If the infrastructure services do not comply with the zero-trust policy, such an attacker might be free to issue unauthorized requests to services in the same infrastructure. They might also be able to steal tokens used internally, then reuse them to call other internal services or even the public-facing APIs.

A diagram showing an attacker inside the company's network that intercepts access tokens and replies them against a public-facing API.

An internal attacker can intercept tokens and replay them against internal services or public-facing APIs.

Sometimes, such an attacker might not even have to breach the outer defenses — it might be a malicious party acting from inside the organization, like an employee bribed by someone or going rogue. Companies should consider such risks as well.

The Privacy Risks of Information-Bearing Tokens

Another issue of access tokens is privacy. For the token to act as an API access credential, it must be associated with information, like who issued the token, when, or what privileges the token grants. Sometimes, the token acts as a reference to that information, but quite often, it carries that information directly. This means that anyone possessing that token can read that information, which can lead to leaks of information about users (or even personally identifiable information) or the infrastructure. All this data is valuable to attackers and should be protected.

When tokens carry information, that data can be misused, not necessarily in a nefarious way. Applications that integrate with the company's API should not be able to read an access token’s information. If they are able to read, and therefore rely upon, the access token's content, it can lead to disruptions when the company updates its API token data. To prevent this type of outcome, issue confidential access tokens to clients.

The Problems That Token Patterns Solve

Using token patterns helps organizations solve several technical and organizational issues. They elevate API security to a new level as they offer better token protection. Token patterns can prevent attackers from reusing stolen tokens or limit the impact of an exploit, regardless of whether the attacker intercepted tokens inside or outside the infrastructure. They also help to adhere to zero-trust principles, where authorization happens on every level in the infrastructure, not just the perimeter.

Protecting Privacy

Phantom tokens, split tokens, and wrapped opaque tokens help protect privacy, and make integrations more stable. They allow companies to regain control of their security implementations and not worry about impacting their partners' businesses.

Monitoring and Governance

Token patterns rely heavily on the role of a central token service — a service responsible for the implementations. As the role of this central service becomes greater, it becomes a good place to enforce policies and introduce monitoring and governance. Companies do not have to worry about rules being scattered in the infrastructure.

Facilitating Digital Transformation

Some token patterns can become potent tools in performing digital transformations. These days, digital transformation is not just about transferring business from paper to the digital world. It's also about modernizing the architecture and infrastructure that the organization uses. Token patterns simplify application-level code and work with any modern technology. Companies should be able to perform phased migrations to new architectures and continue to integrate with legacy systems.

Unlock Potential With Token Patterns

Companies want to be agile and minimize the time-to-market needed to keep up with the competition. This means using technologies and patterns that empower architects, security experts, and developers, not restrain them.

Enforce Least Privilege with Token Patterns in Zero-Trust Architectures

From the API perspective, zero-trust means constantly verifying whether the caller is authorized to perform a request. Part of that is ensuring that applications and services are issued with the least privilege needed to perform their tasks. With patterns like token exchange, organizations can ensure that tokens that flow in an infrastructure are always down-scoped to the minimum required entitlement. This ensures that attackers can't abuse a breached service, as they won't have the necessary privileges.

Streamline API Integrations Using Token Transformations

Interoperability enables organizations to quickly add new elements to their system, cutting down the time needed to create integrations. For example, when using the phantom token pattern, the organization's API gateway can ensure that internal services always use the same type of credential forwarded in a standardized way. Regardless of what kind of application calls the API — a mobile application, a web application, a connected IoT device, or an internal automated service — the API can easily be reused without needing time-consuming adjustments.

Modernize Legacy Systems with OAuth and Token Patterns

With token patterns, companies can move from the old to the new more easily. OAuth federation and token exchange perfectly integrate legacy systems with modern infrastructure. OAuth tokens can be used to wrap the legacy technology and allow services to perform authorization in a modern way. Eventually, the token service can change how it issues tokens so that the legacy system is dropped.

People-Centric Security Drives Business Value

An important driver for company change is to positively impact people — both customers and employees — as this eventually leads to better results.

When companies apply token patterns, they better protect user privacy. Privacy should naturally be a concern in today's world, but its protection is also increasingly enforced by regulations like the European Union's GDPR or California's CCPA. When using tokens that no one can harvest for data, companies close one of the gaps that could leak data.

Security teams and governance teams can work more efficiently when token patterns are implemented. They can use the centralized token service to enforce certain policies (for example, ensuring that only a limited set of services can perform token exchange). It's also simpler to focus on one part of the system than to seek out the information scattered across the whole infrastructure.

The security enhancements introduced by token patterns allow the organization's customers to feel more confident doing business with them. Every data breach and security incident is a reputational loss, which reflects on the company's results. Better security for users, in the end, benefits the organization itself.

If an organization works with partners, creating more robust integrations will help it thrive. Integrators prefer APIs and partners that offer stable interfaces that will not cause unexpected outages to their business.

How to Implement Token Patterns

Implementing token patterns requires a centralized token service — a dedicated service for issuing and exchanging tokens. Organizations that already use OAuth are in a good spot — the OAuth authorization server is the place for implementation. Companies not yet using OAuth should consider moving to this established standard for API security.

Once OAuth is in place, organizations should use claims-based authorization for attribute-based access control. This allows associating all the necessary identity parameters with a token and using them for fine-grained authorization. It allows zero-trust techniques with least-privilege tokens and properly limits the token scope during token exchange.

The OAuth server is also responsible for implementing patterns requiring introspection or token exchange. Whether it's phantom tokens, split tokens, transaction tokens, or token exchange, they are all implemented in the server. Some patterns also require an extensible API gateway. However, most gateway technologies support extensibility, and this should not become a hurdle.

To further strengthen the overall security of communication between internal services, organizations can combine application security (tokens and user identities) with infrastructure security and non-human identities (NHI). NHIs provide stronger client credentials to get or exchange tokens. For example, backend components can use short-lived and auto-renewed Kubernetes service account tokens rather than client secrets. Specifications like the ones the WIMSE group is working on can help implement that.

Token Patterns: A Standards-Based Approach for Any Organization

Regardless of their size or industry, organizations should consider implementing token patterns. Many are based on standards, so implementing them usually requires only a few lines of code.

If you want to learn the technical aspects of the different token patterns, then have a look at the following resources:

Photo of Michal Trojanowski

Michal Trojanowski

Product Marketing Engineer at Curity

Newsletter

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Newsletter

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial