Curity Blog

Beyond Login: Building Secure Authorization with the Curity Identity Server

Jonas Iggbom — Thu, 19 Mar 2026 00:00:00 GMT

In modern API-driven systems, authentication is only the starting point. Simply logging a user in is no longer enough. Organizations need to control how APIs are accessed, how microservices communicate, how tokens are protected, and how permissions are enforced across distributed environments.

Real-world authorization is rarely simple. It requires precision, flexibility, and strong security guarantees.

The Curity Identity Server is designed to address this broader challenge. It goes beyond authentication to provide a solid, standards-based foundation for secure authorization across modern API and application ecosystems.

Supporting Real Authorization Complexity

Modern authorization isn’t just about checking whether someone is logged in. In distributed systems, access decisions often depend on multiple factors, such as:

User roles and attributes
Resource ownership
Tenant boundaries
Device context
Risk signals
Service-to-service communication

APIs frequently need fine-grained, resource-level permissions. At the same time, microservices should only receive the minimum access they need when calling each other. In regulated industries, there may also be requirements for strong client authentication, auditing, and real-time policy enforcement.

As organizations adopt zero-trust principles and multi-cloud architectures, authorization must become more adaptive and context-aware. Static, role-only checks are no longer enough.

So, can the Curity Identity Server handle this level of complexity?

At its core, Curity is a fully standards-compliant OAuth 2.0 authorization server and OpenID Connect provider. It issues access tokens and ID tokens that can include custom claims configured through token procedures and claims mapping, such as roles, groups, tenant identifiers, and other business-specific attributes.

This enables fine-grained access control. APIs and gateways can evaluate not just whether a user is authenticated but also what they are allowed to do, which resources they can access, and under what conditions. Instead of relying solely on coarse role checks, organizations can move toward attribute-based access control (ABAC) and enforce least-privilege policies across APIs and services.

For even more advanced scenarios, Curity integrates seamlessly with external policy engines like Open Policy Agent (OPA), Cerbos, or any AuthZen-enabled Policy Decision Point (PDP). In these setups, the Curity platform handles authentication and token issuance, while the policy engine evaluates context-aware rules at runtime. This clear separation of responsibilities supports scalable, policy-driven authorization in multi-tenant, regulated, or zero-trust environments.

But secure authorization is not only about architecture. OAuth and OpenID Connect also need to be configured correctly, and small mistakes can easily introduce vulnerabilities.

Preventing OAuth and OpenID Connect Misconfiguration

OAuth 2.0 and OpenID Connect are powerful and flexible frameworks. But that flexibility can also introduce risk. Because they support multiple flows, client types, and token handling patterns, insecure configurations can easily occur.

Common mistakes include:

Using the wrong grant type for a client (for example, enabling implicit flow instead of authorization code with PKCE)
Failing to strictly validate redirect URIs
Allowing overly broad scopes
Issuing long-lived tokens
Not clearly separating public and confidential clients
Storing tokens insecurely in front-end applications

Misconfigurations can also occur on the API side. Services may skip signature verification, accept tokens meant for another audience, or fail to validate expiration and issuer claims. In distributed systems, inconsistent validation across gateways and services can significantly increase risk.

The Curity Identity Server helps reduce these risks by enforcing strict standards compliance and secure-by-default configurations. It supports PKCE, strong redirect URI validation, and clear separation between public and confidential clients. By guiding teams toward recommended flows and secure token handling practices, it lowers the likelihood of common implementation mistakes that can lead to vulnerabilities.

Securing Tokens Throughout Their Lifecycle

Token security does not stop at issuance. It covers the entire lifecycle: how tokens are created, protected, validated, refreshed, and revoked.

Security starts at issuance. Tokens should be cryptographically signed to guarantee integrity and, when necessary, encrypted to protect sensitive claims. They must include correct audience, issuer, and expiration claims so that receiving services can validate them properly.

Token lifecycle management balances security and usability. Short-lived access tokens reduce exposure if a token is leaked. Refresh tokens allow users to maintain sessions securely without frequent reauthentication. Techniques like refresh token rotation help detect and limit replay attempts.

Revocation and introspection mechanisms are also essential. They make it possible to invalidate tokens before they expire—for example, after a credential compromise or logout. In distributed systems, consistent validation across gateways and services ensures that expired or revoked tokens are not accepted.

Token Security and Lifecycle Management in the Curity Identity Server

The Curity Identity Server manages tokens securely from creation to expiration. Tokens are signed and can be encrypted when required. Token lifetimes are configurable to strike the right balance between usability and risk. Refresh token rotation helps mitigate replay threats, and revocation and introspection endpoints provide real-time control when tokens must be invalidated.

Curity’s identity server also supports standards-based capabilities such as token exchange, enabling controlled delegation and on-behalf-of scenarios in service-to-service communication. This allows services to obtain tokens appropriate for calling downstream systems, helping enforce least-privilege principles and reduce the impact if a token is compromised.

Reducing Token Leakage and Replay Risks

Access and refresh tokens are typically bearer credentials. That means anyone who possesses a valid token may be able to use it until it expires. If tokens are exposed, they can be misused.

Leakage can happen in several ways:

Insecure storage in browsers
Logging tokens in application logs
Sending tokens over unencrypted channels
Misconfigured CORS policies
Exposing tokens in front-end code
Passing tokens between services without proper scoping
Accidental check-in to the code repository

Replay attacks occur when an attacker intercepts a token and reuses it to access an API or impersonate a legitimate client. Long-lived tokens and a lack of sender constraints make this easier.

Protecting Against Token Leakage and Replay Attacks

The Curity Identity Server addresses these risks with sender-constrained tokens, including mutual TLS (mTLS) and DPoP. These mechanisms bind tokens to a specific client or cryptographic key, making intercepted tokens useless to attackers.

In addition, the Curity Identity Server supports secure architectural patterns such as short-lived access tokens, the Phantom Token Pattern, and the Split Token Pattern. These approaches ensure that front-end applications only receive opaque reference tokens, keeping JWTs containing sensitive user data (PII) out of public-facing contexts. This while guaranteeing that internal APIs receive properly validated, cryptographically verifiable tokens.

These capabilities allow organizations to implement secure authorization without building complex token and policy infrastructure from scratch.

Beyond Login

Modern authorization requires more than verifying identity. It demands enforceable policies, secure token handling, runtime decision-making, and alignment with zero-trust principles.

The Curity Identity Server provides these capabilities within a standards-based, API-first architecture. By combining fine-grained access control, strong token protection, and rigorous

protocol compliance, it helps organizations move beyond login and implement real-world authorization across modern API architectures.

API Security: Common Misunderstandings for Business Teams

Stefan Nilsson — Tue, 17 Feb 2026 00:00:00 GMT

APIs sit at the center of most digital services today. They connect organizations to partners, support mobile apps, and enable new products to reach users faster. Gone are the days when APIs could be thought of as a technical detail in the background. They are, and should be, an essential part of how the business operates and grows.

For enterprises with complex infrastructures, APIs are also the primary way to manage that complexity. They make it possible to connect teams, systems, and partners without slowing everything down. In that sense, APIs are not just part of the platform, they are a key business enabler.

Despite this, API security is still very often treated as a purely technical concern, something to be handled by infrastructure teams or added once an API is already live. In reality, how access to APIs is designed and enforced directly affects business risk, customer trust, and the ability of the organization to move quickly.

One part of the problem is that many discussions about API security focus on tools and protocols, rather than on what actually matters to the organization. For example: who is allowed to access which services, under what conditions, and what happens when those assumptions turn out to be wrong?

Here, we’ll look at some of the most common misunderstandings about API security and why they frequently lead to problems later. The goal is not to turn business teams into security experts, but to clarify why API security deserves earlier and wider attention than it often gets.

Misunderstanding 1: APIs Are Internal so They’re Low Risk

It’s not unusual for APIs to be labelled as “internal” and assumed to be safe by default. If end users cannot see them, the risk feels limited. In fact, most APIs are accessed by many systems beyond a single team or application. Mobile apps, cloud services, partners and other B2B integrations, as well as automated processes all rely on them. That means these APIs are exposed, even if they are not public.

The thing to remember is that the risk is not about whether an API is meant to be internal but about how many systems can reach it, and what they are allowed to do once they do.

When APIs are treated as low risk, access rules are often unclear or inconsistent. Over time, this creates blind spots that only surface when something goes wrong, often at the cost of trust, time - or both. By ensuring that all APIs, including internal ones, have authentication and authorization controls implemented, you're sure the API is protected against threats from within your organization also.

Why this matters: Treating internal APIs as low risk leads to vague access decisions that are hard to audit, explain, or correct once systems scale.

Misunderstanding 2: API Security is Just about Blocking Traffic

Another misconception is that API security is just about stopping bad requests. Firewalls, gateways, and rate limits become the main focus, with the assumption that blocking enough traffic equals security.

Blocking bad traffic is important but not enough because the approach misses a key question: who or what is calling the API, and why. Many API requests are valid on the surface but inappropriate in context. This fact becomes more prominent as APIs are increasingly used by automated workflows and AI-driven agents that act independently, trigger actions across systems, and call APIs without a human-in-the-loop. Without clear access rules, systems cannot reliably tell the difference between good or bad requests.

This is where identity becomes central, not as a one-time login, but as something that needs to be evaluated every time an API is used.

From a business point of view, blocking traffic without considering identity in the decisions leads to either over-blocking, which slows things down, or under-protecting, which creates risk. Neither supports reliable growth nor good user experiences.

Why this matters: Without identity-aware access decisions, organizations either restrict legitimate use or fail to prevent misuse, weakening trust and agility.

Misunderstanding 3: OAuth and Tokens are Implementation Details

Standards like OAuth are often seen as something technical teams deal with after the real access decisions have already been made. In practice, tokens shape how access works across products, partners, and services. Tokens are not just credentials; they carry the information that APIs use to make access decisions. When designed and issued intelligently, they can reflect context, roles, and risk. When treated as static values, they limit how precisely access can be controlled.

When access security choices are made late, teams end up working around them. That usually shows up as friction for users, complex integrations for partners, or limitations that are hard to change later.

OAuth and token design directly shape partner integration speed, user experience, and the cost of change over time.

What looks like a technical detail early on often turns into a business constraint further down the line.

Why this matters: Treating OAuth as an afterthought locks organizations into access models that are expensive and risky to change once APIs are in use.

Misunderstanding 4: Security Can Be Added Later

API security is frequently postponed in the name of speed, with the plan to launch first and tighten controls once things are proven.

The problem is that access decisions tend to spread quickly. Once APIs are in use, changing how they are secured becomes much harder and a lot more expensive. Your team may be forced to balance fixes against existing integrations and expectations.

Addressing API security earlier in the process avoids rework and makes it easier to scale with confidence, rather than constantly reacting to risk. APIs are particularly vulnerable now with the rise of AI agents, where an attacker doesn’t necessarily need a major flaw, only weak enforcement.

Why this matters: Access decisions made under time pressure often become long-term constraints that slow growth instead of enabling it.

How Curity Supports API-First Access

At Curity, we work with teams that are building and operating APIs at scale, often across complex environments with many moving parts. A common challenge is that access decisions end up scattered across gateways, applications, and custom logic, making them hard to reason about and even harder to change.

Curity helps bring those decisions together at the API layer. Instead of relying on static rules or perimeter controls, teams can evaluate access based on who or what is calling an API and under what conditions, every time that API is used.

This becomes especially important as APIs are increasingly used by partners, automated workflows, and AI-driven agents that act without a human-in-the-loop. This kind of token intelligence becomes especially important as APIs are used more heavily by automated workflows and AI-driven systems. The Curity Identity Server makes it possible to handle these cases consistently, separating authentication from authorization and applying policies across APIs as systems and usage evolve.

The result is an API-first approach to identity and access that supports growth without adding friction. Teams can move faster, adapt more easily, and keep control as their platforms and integrations expand.

How to Think About API Security

API security works best when it is built into how digital services are designed, not as a control added at the end. The most common problems tend to arise when access decisions are assumed to be simple, static, or someone else’s responsibility.

The goal is not for business teams to master technical details, but to recognise where and how identity and access choices affect outcomes. APIs determine how systems interact, how partners integrate, and how trust is maintained at scale. In that sense, trust is not just protected by security controls, but designed through the access decisions applications make every day.

When identity and access are considered early and applied consistently at the API level, teams are more likely to grow without constantly revisiting decisions made under pressure. That shift in thinking is often the difference between security that slows the business down and security that supports it. For organizations building API-first platforms, that difference directly impacts how quickly they can adapt, integrate, and compete.

In summary, API security is less about individual controls and more about how access decisions are designed and maintained over time:

APIs are where access decisions actually happen
API security is about identity and authorization, not just blocking traffic
OAuth and tokens are business infrastructure, not implementation details
Access decisions made late are costly and difficult to change
Designing API security early enables growth without constant rework.

Learn how Curity helps teams design and enforce strong API access from the start.

API Security Trends 2026

Judith Kahrer — Tue, 16 Dec 2025 00:00:00 GMT

Looking back at Nordic API’s Platform Summit that took place last October, 2025 was the year of AI and MCP. Both will remain hot topics to a great extent even in 2026, and they already bring some good changes as they are forcing organizations to rethink their IAM strategies, alter their frames of mind, and improve security.

AI will continue to drive IAM in 2026. I'm convinced that its impact on authorization will be long-lasting. With that in mind, I believe 2026 holds some exciting trends worth watching.

Machine Identities Will Take Center Stage

In the context of AI and autonomous applications, it will become increasingly important to authenticate and authorize machines, AI agents, and their human operators, if any. Consequently, machine IAM will get quite some attention in 2026. Questions like how to trust arbitrary applications whose code organizations can't control, how to onboard them, and how to authorize requests will be hot topics.

Simply strengthening machine identities will not be enough. AI demands speed and dynamics in authorization decisions - particularly for applications. Authorization will need to be fast and secure.

Access Control Will Concentrate on Speed

Conventional Privileged Access Management (PAM) and Identity Governance and Administration (IGA) solutions struggle to meet modern requirements for provisioning access for machines or applications in a timely manner. IAM simply cannot rely anymore on processes with manual steps and approvals, where it may take weeks to onboard applications and provision access. Autonomous applications require autonomous decisions.

Admin-time authorization will need to focus on setting up the trust and defining the rules for how to retrieve permissions for applications and users dynamically during runtime. Runtime authorization will need to continuously evaluate permissions.

Permissions can change quickly depending on events at other parts of a system architecture. Therefore, analysing and sharing data and signals between components will be important for the success of IAM. This is a great chance for the adoption of certain standards.

OAuth Integrations Will Mature

Along with the focus on machine identities, more organizations will start to strengthen OAuth client credentials. More organizations will utilize their infrastructure, such as workload identities for client authentication. However, as with usernames and passwords for humans, it will take decades to get rid of client secrets or their equivalent to authenticate applications. At least, 2026 will spark off some initiatives in the right direction. With MCP dictating an OAuth profile, organizations will become more aware of the best practices. In 2026, OAuth integrations will improve beyond strong client credentials: More organizations will make use of token exchange for least privileged access and of the JWT-assertion-grant protocol to cross security boundaries. How to enable Single Sign-On for users across trust domains and federate authorization without compromising security is one of the challenges to solve in 2026.

While AI and the resulting requirements will dominate IAM to a great extent, some regulations, namely eIDAS and PSD3, will also have an impact during 2026.

Verifiable Credentials Will Begin to Shine

There is quite some work happening in the European Union for the rollout of Verifiable Credentials and a European Identity Wallet. As the deadline is getting closer and the results get more and more reliable in 2026, organizations that are far-sighted will prepare for the change. Verifiable Credentials enable a new, convenient, and cheap method for identity verification and authentication for a large part of the population in Europe. 2026 is the year when things will start to feel real.

Open Finance Will Disrupt the Finance Sector

As with PSD2, which created quite some excitement and anxiety in the banking sector, PSD3, PSR, and FIDA will have a similar impact on more actors in the financial industry. It's likely that the regulations will be finalized during the first half of 2026. So, 2026 is the time to have a closer look and prepare for the impact. The regulations promise more harmonization and stronger customer protection. Among other things, PSD3 strengthens Strong Customer Authentication (SCA). For example, SCA implementations also need to be accessible to all users, including people with disabilities, elderly people, or people with less technical skills. Sounds good and human in my opinion.

Weak API Security Will Continue

Companies will continue to make mistakes because there will still be gaps in the understanding between infrastructure teams, application developers, API developers, and the business. Such misunderstandings, together with other implementation flaws, represent the main threat to API access control. The increase in automated API attacks that target broken authorization adds to the risk. Consequently, broken authorization is the area where most exploits will occur.

Organizations need to proactively improve their API security implementations to avoid broken authorizations from the beginning. The ability to communicate and convey business requirements, and translate them into technical implementations while providing seamless user experience (including developer experience) and keeping up with security will remain important for the success of an IAM program.

Refine Your API Security in 2026

IAM for APIs and API clients remains a complex topic. In fact, the trend is towards more complexity, which requires more sophisticated building blocks such as non-human identities. The best practices for API access control and AI agents are going to be more relevant than ever in 2026. I believe that the new year will bring some exciting improvements regarding IAM. Who knows, maybe 2026 is the year that will rewrite the list of top API vulnerabilities and contain fewer authorization problems?!

Identity and Access Management for AI Agents

Judith Kahrer — Thu, 27 Nov 2025 00:00:00 GMT

Many companies are starting to experiment with AI agents to automate tasks or support users, but these agents don’t behave like the applications we’re used to securing. They make their own decisions, adjust their actions as they go, and interact with systems in ways that aren’t always predictable. That shift exposes gaps in today’s machine identity and access controls. Before getting into the details, it helps to look at why these agents challenge some of the assumptions in traditional IAM.

The Characteristics of AI Agents

AI agents use advanced algorithms to determine the steps needed to solve a task. They not only use algorithms to resolve required steps dynamically but also feed back results to improve the execution of the algorithms. This allows AI agents to dynamically adapt their behavior, making their execution indeterministic and unpredictable.

AI agents are software systems with the ability to operate autonomously or semi-autonomously, often on behalf of a user, in an indeterministic manner.

The interdeterministic characteristic of AI agents stands in contrast to conventional software, where the steps to solve a task are predefined and execution is deterministic. This contrast highlights a fundamental change in how applications operate. It implies that the assumptions on which many security solutions were built have changed as well.

Authorization Premises Are Changing

Historically, the focus of IAM has been authentication and authorization of human users. The adoption of multi-factor authentication, passwordless login methods, together with identity governance and administration (IGA) processes to, for example, approve access requests for humans serves as proof. IAM for applications (machine IAM) did not follow a comparable evolution.

With applications being indeterministic and issuing unpredictable requests on behalf of users, being able to perform authorization on the correct premises becomes more prevalent. Static entitlement mappings for service accounts are not enough to meet the requirements of the new dynamic in applications. Instead, the identity and entitlements of applications need to play a greater part in access control decisions.

What really becomes important when protecting access to data from AI agents is identity governance and administration for applications. IGA for applications implies that there are processes and tools that allow organizations to assign and enforce access rights for machines which include AI agents. This requires setting up (machine) identities for AI agents.

Identities for AI Agents

AI agents are applications and, as such, fall under the umbrella of machine IAM. The industry has identified that the dynamic characteristics of AI agents require similar approaches for access control to what is typically in place for human users. However, this does not mean that AI agents are human users and should be treated as such. Mixing human and machine identities creates ambiguity that is hard to maintain. Instead, AI agents remain machines and should use existing means of machine identities.

Common forms of machine identities are:

Service accounts + secrets
API keys
JWT-based workload credentials
X509 (client) certificates

As with usernames and passwords for human users, symmetric credentials for applications like secrets and API keys pose security risks. Therefore, whenever possible, use application credentials that are based on asymmetric cryptography, such as JWT-based credentials and X509 certificates. Prefer authentication mechanisms that use key-bound credentials and require a proof-of-control of a private key like X509 certificates with mutual TLS (mTLS). Mutual TLS has been around for many years and is widely supported by various tools in a technology stack.

Since AI agents are applications, you can assign identities as you do for other applications and learn from best practices. For example, for a self-hosted AI agent on the backend, consider workload identities. For public agents, consider self-assigned identities using mechanisms like dynamic client registration, which is a common approach for mobile applications.

An argument for treating AI agents differently than other applications is delegation, the fact that they (autonomously) act on behalf of a user. Any user-facing application performs delegation, actually, and batch applications also run autonomously - sometimes with user identity involved. There are already well-established protocols that solve user delegation to applications: OAuth and OpenID Connect. Apply them to AI agents!

(O)Authorization for AI Agents

The fact that AI agents perform automatic, unpredictable tasks on behalf of users does not mean they need dedicated identities or authentication mechanisms. AI agents are still OAuth clients like other applications. Consequently, the challenges that arise from onboarding public clients are not specific to (public) AI agents and remain similar across various applications. The challenges have just become more prevalent.

In the context of OAuth, AI agents are simply OAuth clients.

Theoretically, AI agents can run the same OAuth flows to retrieve access tokens like other applications. However, you need to adapt how you enforce access control rules for AI agents and applications in general. For example, with AI agents performing unpredictable tasks, it becomes important to keep a human in the loop, such as triggering approval requests where appropriate before granting access. These kinds of processes are typically part of identity governance and administration.

Identity governance and administration for applications means focusing on which application can access what under which circumstances, independently of the operating user. Part of that logic already resides in an application-centric identity server, an authorization server like the Curity Identity Server, that maintains a list of all (registered) OAuth clients and scopes they are allowed to request.

In the long run, and to enforce global policies, APIs and any other policy enforcement points should support integration with external access management systems that maintain access policies and can return access control decisions in real time. In that way, access control decisions can take into account many data points across a system and time. This enables risk-based access control decisions that address the challenges from AI agents.

Reducing AI Security Anxiety

AI agents and any other indeterministic applications change certain premises with regard to API access control. However, while AI agents may significantly change how we interact with machines, they do not rescind the foundations of API access control. OAuth was designed for delegation and continues to be the tool of choice for that purpose. In that context, AI agents are simply OAuth clients.

What you need to update are access control rules beyond OAuth integrations and the enforcement of those rules. This includes identity governance and administration for applications, and OAuth is part of it.

The following capabilities are the new basic requirements for API access controls. You need to

design access control rules targeting applications,
be able to identify and optionally authenticate clients,
add relevant identity information in access tokens and
integrate with external authorization systems to dynamically enforce policies.

There is no need for agentic identities, no magic, just robust API access control with an emphasis on identity governance and administration for applications.

Learn more about how Curity can help you to secure IAM in the age of AI.

And make sure to attend a live webinar - MCP and AI Agents: Identity Strategies for Safe API Access - on December 4. Learn more and register.

Guarding Against AI-Agent Attacks: A Cautionary Tale from a Recent Incident

Jacob Ideskog — Mon, 17 Nov 2025 00:00:00 GMT

In the wake of a recent cyber incident described by Anthropic involving an army of AI agents, we’ve witnessed a striking example of how attackers can leverage artificial intelligence to exploit weaknesses and gain access at a scale and velocity impossible before. AI agents were able to systematically extract and steal large volumes of sensitive data, running tasks in Claude Code that would be tedious and time-consuming (and therefore somewhat easier to spot) for human operators. The Claude agents had been granted enough leeway to operate for quite a while before anyone realized what was going on.

This is not just a cautionary tale for AI focused enterprises; it’s a wake-up call for everyone exposing APIs and digital services.

In that incident, an army of AI-driven agents orchestrated a sophisticated attack, taking advantage of whatever access they could gain. While the specifics in that case didn’t revolve solely around APIs , the broader principle remains universal: any exposed surface, especially APIs, becomes a prime target for malicious agents.

APIs are particularly vulnerable here because AI agents excel at rapid, repetitive, and incremental probing. If privilege boundaries are too broad or too static, an attacker doesn’t need a major flaw, only weak enforcement.

What could make a difference? By enforcing the use of OAuth to acquire fresh tokens with expanded privileges only when truly needed, you introduce checkpoints that require every meaningful access request to be justified. If your APIs have stricter access models, for example, more granular rules on what constitutes reasonable access, how often data can be requested, and when elevated privileges are required, then the whole scenario could be different.

In practice, this means leveraging mechanisms like human-in-the-loop approval or policy enforcement engines to evaluate whether a particular request for access is legitimate. How often has this agent asked for data? Is this frequency normal? Is it even allowed? Additionally, you can forward signals from your token issuance system to other systems, like risk engines, that can analyze usage patterns and help detect anomalies early. By doing this, you stand a better chance not just of spotting attacks in progress, but potentially mitigating them before they cause significant harm.

Ultimately, as we expose more APIs, and in particular more AI-friendly APIs, we need to think ahead. Monitoring traffic alone will not suffice. Having a ubiquitous and robust privilege management system, like the one Curity provides, helps you catch these signals and respond more swiftly to threats and risks.

Takeaways From the 2025 Nordic APIs Platform Summit

Michal Trojanowski — Thu, 06 Nov 2025 00:00:00 GMT

I’ve attended Nordic APIs’Platform Summit a few times, even before my time at Curity, but this year felt a bit different. It was still the same time and place — mid-fall in Stockholm in the halls of hotel Clarion, which offers unique views of the city (for those of you who haven’t been there, or maybe did not notice: the hotel is built on top of an entry to a highway tunnel and offers a nice view of the disappearing road and a part of the Stockholm archipelago).

To me, two reasons made this year’s experience exceptional:

The conference was accompanied by a half-day unconference focusing on API security.
You could not hide from hearing about the new cool kid on the block — Model Context Protocol (MCP).

The API Security Unconference

An unconference is a great platform for exchanging experiences, sharing knowledge, and learning. Unlike a “regular” conference, an unconference has no designated speakers — everyone is an attendee — and there is no fixed agenda; the attendees choose the topics they want to discuss during the day. In my opinion, this worked really well. We managed to get some good discussions, where people actively shared their experiences or challenges.

Some conversations did not reach any specific conclusions, but they allowed us to confirm that all the participants deal with similar issues and have similar reservations — this in itself can be reassuring, even if it is not immediately helpful. But there were also sessions that allowed people to learn a lot. For example, we had a very good discussion on API authorization patterns. The person who started it wanted to learn about modern, scalable approaches to API authorization and got exactly that — there were attendees who work with the OpenID Foundation on the AuthZen project, who were able to share their knowledge and present different approaches.

The unconference was a great place to network — it made it easy to meet new people and have great discussions. I recommend trying this format to anyone who finds hallway discussions at conferences an important part of the experience. I’m really glad that Nordic APIs has already announced that there will be another edition next year.

Platform Summit

The conference itself stuck to its well-established format with opening and closing keynotes and breakout sessions in one-hour-long blocks. Each block ended with a joint Q&A which acted as a mini-panel with speakers from the block’s talks. The 20-minute limit for a single talk is enough to get the most important information distilled.

And it turns out that 20 minutes were enough to squeeze MCP into almost every talk, even if not directly mentioned in the title. Apparently, people were placing bets on whether they would manage to attend a talk in which MCP was not mentioned. I don’t know if that really happened, but I know I have been to a few talks that didn’t mention MCP.

Model Context Protocol Taking the API World By Storm

I have never seen a technology or specification become such a buzz like MCP this year. Even in the early days of GraphQL, people were talking a lot about it, but it wasn’t as ubiquitous as MCP currently is. And MCP is just one year old! To illustrate what I mean — MCP was covered so much, that I felt sorry for my listeners that I added an “MCP explainer” slide to my talk, which was in the afternoon of the second day.

I think the reason for this is that MCP can affect APIs from so many different angles:

An MCP server is an API in itself, protected by OAuth, and you can focus on the security of its connection to the MCP client.
You can focus on the authorization requirements of APIs that will be consumed by MCP servers’ tools.
You can focus on how to design and document your APIs so that they can be more easily consumed by MCP servers.
You can view all the above topics from two perspectives — external customers and enterprise (workforce). Both of them have different challenges and available solutions.
You can talk about how MCP servers can help you with the design, development, testing, or management of APIs.

Even though MCP dominated the discourse, it wasn’t the only thing people presented at the conference.

API Security is as Important as Ever

API security is still a popular topic. It is good, as it proves that we understand its importance. On the other hand, it also shows that we need to continue talking about it to get even more people to think about security first (and get authorization issues off the top of the OWASP list).

I always enjoy security talks, as they allow me to expand, or at least consolidate, my knowledge. Being physically at the talk also allows me to better concentrate on the content, unlike reading an article online.

I especially enjoyed a talk by Roger Bergling on hacking APIs, where he showed a number of tools useful for checking the resilience of your APIs. It was both enjoyable and disturbing to see that it takes seconds to crack a JWT signed with a weak symmetric key. This is exactly why at Curity we have been discouraging people from symmetrically signing JWTs for a long time now.

Platform Summit as a Technology Radar

Another reason I like conferences is that you can learn a lot. Of course, I try to follow trends and news around APIs and API security, but sometimes things slip under the radar. And, also quite obviously, I can’t just sit in front of a web search engine and start to search for the things I don’t know. After every conference I go to, I come back with a list of at least a few technologies or specifications and usually around a dozen tools or vendors I want to check out.

Here are the things that caught my interest at the Platform Summit that I’d like to learn more about:

Fuzzy testing of APIs, which means using algorithms to automatically generate tests that try to break your APIs in creative ways.
Event Destinations specification, which tries to enhance interoperability in event-driven systems.
I first learned about TypeSpec in 2024, and it was nice to see more talks about it this year, even though I still confuse the name with TypeScript… I hope to try it out with the next API I will design.
I already mentioned the talk about hacking APIs, and it mentioned a lot of tools I hope to play around with.
SAFE-MCP, a security analysis framework for MCP.

Learning From Real-Life Experiences

I mentioned how the unconference is a great place to learn from others’ experiences, but of course, the “regular” conference had no shortage of educational talks. It’s always appreciated when speakers share their journey, so you can either find guidance in how you should approach a similar problem, or what to avoid. This might be why I kept hearing in hallway conversations that one of the most interesting talks at the conference was about an API governance journey in a very large and old insurance company.

Sometimes, the thing you learn might not even be the main topic of the session. For me, the most interesting part of the talk on combining Webhooks and REST, was learning about the architecture of a mostly air-gapped system that runs on an airplane to process sales. How it uses an onboard web server to host a website for passengers, and connects to point-of-sale terminals. It was interesting to hear about some other architecture than a simple web server exposed on the internet.

Conclusion

I enjoyed this year’s Platform Summit a lot, and I’m really glad that Nordic APIs has already announced the dates for next year: 12-14 October 2026. I hope I will be able to join both the unconference and the main event.

I am curious to see how MCP will evolve and how the worlds of AI and APIs will work together. At Curity, we have been working with it a lot recently. This is why we have just set up a dedicated AI Lab, where we will develop AI agents and reference API architectures that can interact safely with them, either via MCP, or any protocol that emerges. Keep an eye on our blog and website, as we will share our insights as we progress.

If you are curious about this year’s Platform Summit talks, or you have been there and want to refresh or share some with your colleagues, then head down to the Nordic APIs YouTube channel. You will find this year’s recordings there soon, but you can already enjoy all the sessions from previous years.

From Screws to Software: The Power of Standards

Michal Trojanowski — Tue, 07 Oct 2025 00:00:00 GMT

We are surrounded by standards, even if we don't realize it. A lot of different things, from cars and home appliances to electrical grids, screws and paper sheet sizes, are standardized. Standards make our life safer and allow for interoperability. For example, when you buy a screwdriver, you don't have to worry too much about which manufacturer produced the screws or whether the tool will fit.

The situation is similar with software. There are plenty of standards that regulate many aspects of software, like architecture, security features, data structures, flows, and interfaces. Some are created by professional standardization bodies like IETF, CNCF, or OpenID Foundation. Others, like the recent Model Context Protocol, are maintained by communities of dedicated practitioners.

The origin of the standard is not the most important factor. What matters is if it becomes widely adopted. Some standards are initially created by companies or communities, but once they gain popularity, they are taken over by professional bodies.

This ensures quality and proper support for the standard. However, even though we have some popular and well-established standards in the IT ecosystem, I still meet people who are reluctant to follow them. I think there are two main reasons for this reluctance:

perceived implementation difficulty
illusion of vulnerability

Myth: Standards Are Hard To Implement

People sometimes look at a standard and think it is overcomplicated and hard to implement. While I'm not saying this is never the case (we developers sometimes have this innate ability to over-engineer), I think that more often than not, it is just a feeling.

For example, look at OAuth 2.0 and its authorization code flow. I had conversations about why the flow is so complicated, why the authorization server returns a temporary code instead of tokens, and how it only complicates things.

In this case, the standard’s authors made design decisions to introduce better protections for the flow — the additional request to get tokens is there to better protect them. And when you distill the flow, it turns out that its implementation is pretty straightforward — an OAuth client needs to send a POST request, be able to receive a GET request (the authorization server's response sent through a redirect), and send another POST request. Sometimes, a standard might look complicated, but very often the decisions are well thought through, and we might just not know the details.

When we are consumers of standards, it is hard to know the reasoning behind every design decision, so we usually have to accept that the standard solves the issues in the best way. Very often, when we try to come up with a better and simpler solution than the standard proposes, we start small and build up to create the new solution, solving any issues as they arise. In the end we usually just come to the conclusion that, indeed, what the standard proposes helps solve the issue pretty well.

Myth: Standards Make Vulnerabilities More Dangerous

Another argument I heard against using standards, especially the popular security standards, are the vulnerabilities that inevitably show up in any software. If everyone is using OAuth, and someone finds a way to hack an OAuth flow, then everyone becomes vulnerable. In essence, this is true, but there is another side to this.

When you have a popular standard, you also have a group of maintainers that looks after it. If someone finds a vulnerability, then you have these experts who can quickly come up with a solution and propose an update to the standard.

To stick with the OAuth example, when people found out that in a mobile environment, an attacker can intercept the authorization code and steal tokens, they came up with PKCE. Because you are using a proprietary solution doesn’t mean you are automatically more secure — you don't have the community of experts that vet standards and can help with patching them. If someone hacks your proprietary solution, then you are on your own to patch it.

Yet, the support from maintainers is not the only reason why it is beneficial to follow standards.

Standards Facilitate Adoption and Innovation

Using standards makes it easier to adopt innovations and shorten the time to market.

For example, if you are using OpenAPI to define your APIs and implement standardized API error responses, it is then much easier for both internal and external integrators to consume your APIs. Internal teams can deliver products and features faster, while external developers are more willing to integrate with your API.

Another advantage is when new trends and technologies emerge. Like AI agents and Model Context Protocol, for example. The specification mandates the use of OAuth to secure the MCP server. This means that companies that already use OAuth will be able to implement MCP servers more easily and deliver them faster.

Companies that do not yet use the OAuth security standard to protect their applications and APIs will need much more time and effort to work with MCP. In this case, using one well-established standard makes it easier to integrate another.

Even when there are no novelties on the horizon, you still benefit from using standards. Popular standards spark community support, which makes your life easier.

Ecosystem Support

Popular standards gain organic support from the community. People create tools that facilitate working with standardized systems. For example, if you use OpenAPI, you can then utilize products that automatically create documentation pages or generate SDKs to integrate with your API.

Systems that use OAuth can be easily integrated with applications through the use of OAuth libraries. Without these standards, companies would have to build bespoke solutions every time they needed a feature.

When deciding to use a standard, you might not even know what its adoption will eventually enable. For example, in the space of AI agents and MCP, companies that already implemented GraphQL as a standard for APIs can now leverage solutions like Apollo's MCP server for GraphQL to set up an MCP server in no time. Again, using the standard, allowed for easier and quicker innovation thanks to tools provided by the community. This wouldn't be possible without implementing standards.

Always Use Standards

Whenever possible, utilize a standard for your architecture or implementation. Following standards is beneficial to your organization, even if it takes time to understand it and its ecosystem. You will quickly see the returns from such an investment — whether in support from the community with patches or tools, wider adoption of your product, or ease in onboarding new employees.

Standards make your solution future-ready, simplifying replacements, integrations and innovations. Bespoke solutions can rarely match these benefits.

At Curity we wholeheartedly believe in standards. We participate in the works of standards bodies like the OpenID foundation, and we make sure that our flagship product — the Curity Identity Server — follows as many of them as possible.

Exploring the Future of API Security and Identity at Platform Summit 2025

Curity — Wed, 24 Sep 2025 00:00:00 GMT

Every year, Platform Summit gathers the global API community to explore the most pressing challenges and opportunities shaping the world of APIs and the digital world as a whole. In 2025, these conversations feel more critical than ever. APIs are powering all the essential services across finance, healthcare, public sector and many other industries, while AI-driven clients and automated processes are transforming the way systems are built, consumed and secured.

At Curity, we see several themes as most critical for the future of API security and identity - and we are excited to share some of those in October.

API Security: a Longstanding Focus

API security has always been at the core of our work, and it is a topic we have consistently championed at Platform Summit. Over time, we have seen the field grow from protecting endpoints with API keys to securing entire digital ecosystems, with identity and authorization playing a central role.

That’s why we’re especially excited about the introduction of the API Security Unconference on Day 0 (October 13) where participants are encouraged to bring their most challenging questions and experiences and to explore them in an open and collaborative way. Curity identity specialists will join as moderators, helping guide the conversation and connect real-world challenges to practical solutions, as well as share their knowledge and expertise. For us, it’s inspiring to see API security take center stage in such a dynamic format, reflecting how essential it has become.

The Rise of Non-Human Identities

Traditionally, APIs were built for human users or business integrations, authenticated and authorized through predictable flows. But today, APIs are increasingly consumed by AI clients, autonomous agents and ephemeral processes that exist only for moments at a time. These non-human identities create new challenges: permissions that linger after their purpose, workloads that operate outside human oversight and risks that can be hard to detect.

Curity’s CTO, Jacob Ideskog, will explore this shift in his talk, Ghosts, Zombies, and Robots: Handing Off Control to the Non-Humans. Using these metaphors, he will examine how OAuth can be adapted to protect privacy, reduce risk and restore control in a world where API actors are often invisible, uncontrollable, or short-lived.

MCP and the AI-to-API Connection

The emergence of the Model Context Protocol (MCP) highlights how AI systems are increasingly using APIs at scale. While MCP leverages OAuth, its unique patterns raise important questions. Is an MCP client just another OAuth client, or does it demand new infrastructure, policies and safeguards?

In MCP Client — Just Another OAuth Client?, Michal Trojanowski will examine how securing MCP differs from traditional client security, offering best practices for consent, refresh tokens and MCP gateways.

Complementing this, Gary Archer will deliver How to Design Secure MCP Deployments, a lightning talk that looks at authorization-first architectures, the threats MCP introduces and practical flows that maximize value while mitigating risk. Together, these sessions will offer both a conceptual and hands-on view of how to secure AI-to-API interactions responsibly.

Identity as a Strategic Lever

As more digital services are built API-first, identity has become the decisive control point. Whoever governs access effectively governs the system itself. With rising geopolitical tension and growing dependence on third-party cloud services, identity management becomes a matter of sovereignty.

Daniel Lindau will speak on this in Identity: The Kill Switch for API-Driven Digital Sovereignty. He will address the systemic risks of outsourcing identity and authorization to external providers, and show how open standards and wallet-based identities offer a path to restoring autonomy at organizational, sector and even national levels.

Looking Ahead

The intersection of AI, APIs and identity brings enormous potential, but also unprecedented challenges.

Platform Summit 2025 provides an important opportunity to explore these topics together. For Curity, it is a chance to contribute to the ongoing conversation about how we can build an internet that remains open, secure, and sovereign in the age of automation.

We look forward to seeing many of you at the Summit this October.

Modernize SAML Web Architectures the Right Way

Gary Archer — Wed, 03 Sep 2025 00:00:00 GMT

Many existing websites use legacy web architectures and outdated security solutions. One example is the Web Browser Profile from the Security Assertion Markup Language (SAML) 2.0 security standard, which was released back in 2005. In this model, websites externalize user authentication to SAML Identity Providers. After logins, websites receive user attributes in SAML assertions and use them to authorize requests from the browser frontend.

However, web architecture has moved on. Modern applications increasingly rely on APIs to manage data security. The move to APIs significantly changes how organizations should implement both data security and web architectures. Many companies are now working on SAML to OAuth migration and web modernization projects, replacing legacy SAML web architecture with more scalable and secure models. But what does an optimal solution look like?

Web modernization is also an area of much confusion for developers. There is a large amount of technology marketing about the best ways to develop web applications. Almost none of this marketing explains how web applications should manage data security and API integrations. In this article, I demystify some web jargon and show how the web and API sides of the architecture should interact to create a unified, secure architecture.

Modernization Requirements

Modernizing a web architecture means rethinking how technology, hosting, security, and integration patterns work together. It’s not just about updating frameworks — it’s about aligning with modern API-first architectures and strong identity practices.

Web Technology Requirements

For new apps, developers often choose a single page application (SPA) technology stack such as React or Angular. Instead of using SAML assertions, developers build solutions using the most up-to-date security standards, centered on the OAuth 2.0 Authorization Framework. The browser-based application receives an access token (AT) to send to APIs and a refresh token (RT) with which to silently renew it.

Although this technology update adds modernization, developers may follow insecure practices. Using tokens in the browser is considered less secure than the SAML solution. In some cases, the new app may fail security reviews and be unable to go live. Browser security is a hot topic for security reviewers, so any web modernization should first consider security modernization. You should also consider the crucial impact hosting has on the security and web architecture.

Hosting Requirements

Some older architectures, like SAML, had dependencies on legacy infrastructure. For example, you might need to store user accounts in Active Directory and use Windows Servers. Static web content does not contain secured assets, so it can use newer hosting technologies, like content delivery networks (CDN). For APIs and data, cloud native hosting usually provides the best technical control.

CDNs improve web performance by deploying static content to hundreds of locations so that the latency of requests is the same globally. Cloud native enables you to deploy APIs and data anywhere, perform phased modernizations, or take control over difficult requirements like data sovereignty, where you store user data in each user’s home region. These capabilities are often key goals when designing zero-trust, API-centric architectures.

Security Requirements

In 2025, your data security architecture should protect against many threats that can impact APIs, frontend applications, and users. You achieve the best protection when you apply the OAuth authorization framework while also following best practices.

For new web applications, pay particular attention to the latest security best practices from the OAuth 2.0 for Browser-Based Applications document. The main browser threat is cross-site scripting (XSS), a serious vulnerability that can expose sensitive data in many ways. For best protection, use the following approaches:

Prevent and contain XSS exploits.
Keep OAuth tokens out of the browser.
Use hardened HTTP-only cookies as short-lived API message credentials.
Prevent untrusted web origins from sending cookies to APIs.

You can perform a phased upgrade from SAML to OAuth with an identity and access management (IAM) system that supports both protocols. Start by repointing SAML apps to the new IAM system so that they continue to run as previously. At a suitable time, upgrade each SAML app to OAuth. This phased SAML-to-OAuth web modernization approach enables organizations to modernize their legacy web architectures without downtime.

Integration Requirements

Web development should be centered on the customer experience. There should be no need for web developers to run backend infrastructure that manages data security. Also, choose technologies that keep code bases modular, to support techniques like splitting large web applications into micro-frontends.

Another point to consider is that APIs are now the unit of reuse. Older practices like embedding webviews that render sensitive data into mobile apps or external web domains are no longer considered secure in the modern era, since browsers will not allow cookie sharing across domains. To scale UI architectures, organizations will need to develop views multiple times, in both web and mobile applications.

Web Architecture Styles

Unfortunately, many web modernizations produce suboptimal results. Developers make choices based on the latest technology stacks and their marketing. Online articles encourage the use of pre-rendering, client-side rendering, or server-side rendering, with little to no mention of data security. So let’s take a closer look at each of these styles from an API integration viewpoint.

Pre-Rendering

Organizations often have some frontend content that renders public data. For this content, you can use the architectural style of a blog or news site. Since all data is public, you can use technologies like NEXT.js to pre-render fixed content to HTML bundles without the need for the browser frontend to call APIs.

Pre-rendering is usually the optimal choice for unsecured web content. Deployments only need to upload HTML bundles to a CDN. The UI structure becomes HTML at deployment time, and the content is the same for all users. Pre-rendering performs well and can result in good search engine optimization (SEO) performance.

Client-Side Rendering

Both mobile applications and SPAs can use client-side rendering. To do so, an app must initiate user authentication and get an API message credential. The app then calls APIs to get data and update its view model. UI elements are then created from the model. The following Swift code snippet demonstrates the approach for a mobile application.

return VStack {

if model.data != nil {

List(model.data!.transactions, id: \.id) { item in

TransactionItemView(transaction: item)

}

The UI structure for sensitive data is unavailable until the frontend receives an API response and updates its model. You cannot pre-render the data since it varies by user, and it is not secure to pre-render sensitive data. Client-side rendering can work identically for web and mobile apps, which helps when you need to implement the same views on multiple platforms.

However, some suggest that web applications should instead use server-side rendering (SSR). Let’s look at how SSR works to serve HTML containing sensitive data to the browser at runtime.

Server-Side Rendering

In the days of SAML, it was common to use SSR for secured data. To see an example, check out the SAML 2.0 example website. The web host uses SSR to combine HTML with sensitive data.

<ul class='list-group'>

<% for (const item in model.transactions) { %>

<li class="list-group-item">Description: <%= item.description %></li>

<% } %>

</ul>

In OAuth you should aim to use short-lived cookies in requests from the browser to backend endpoints, so that if a cookie is somehow intercepted, an exploit only lasts for a short time. With client-side rendering, JavaScript frontend code can handle expired cookies and perform a refresh operation. With server-side rendering, the web host has to return an HTML response if a cookie expires, which is difficult for the frontend to handle with good usability.

When you use SSR for sensitive data, you do not get the SEO benefits that pre-rendering provides, since internet searches cannot reach secured views. More generally, the fact that the web host and HTML responses use sensitive data adds complexity and unwelcome side effects.

Hidden Complexity

The SAML example website uses a runtime that enables cookie-based web sessions, server-side redirects, and server postbacks. A session store maintains the web state during these operations. For production deployments, the session store needs clustering and persistent storage. Many CDNs are unlikely to support running web backends with these dependencies.

Many OAuth website technology stacks continue to use this type of complex backend. In fact, complexity may increase when you integrate OAuth and APIs. The web backend needs to implement an OAuth code flow, translate cookies to tokens, route requests to APIs, process backend error and expiry responses, and write backend logs. Therefore, server-side rendering requires web frontend specialists to implement many backend data security concerns.

Often, web developers start with a website solution that implements security and then evolve their setup into a hybrid app. The main frontend might be a single-page application like a React App. However, the developer must also run and maintain a complex web backend for all future development. Over time, this overhead adversely affects the time to market.

Modern Web Security Design

A key design principle for building an optimal web architecture in 2025 is to separate concerns. In the API era, you only need cookies to transport access tokens to APIs, and any session-related data should be stored on the API side of the architecture. Since cookies are an API message credential that transports access tokens to APIs, you should think of them as an API concern, not a web concern.

Separated Web Deployments

You can combine OAuth web security best practices with the client-side rendering of a modern web technology stack if you use a backend for frontend (BFF) that runs on the API side of the architecture. You then use utility APIs to manage secure cookies. Doing so externalizes backend data protection, and all of its complexities, from the web side of the architecture.

The token handler pattern separates concerns to provide a web security design for the modern era. Web developers only need a lightweight static content host and can focus on a frontend app that interacts with APIs. Deployed APIs include an OAuth Agent that gets tokens and issues cookies to the browser. An OAuth Proxy runs in the API gateway to apply web-specific protections during API requests.'

For some example frontend security code, see the SPA using Token Handler code example. This demonstrates a modern low-code approach where frontend developers do not run any backend infrastructure. The token handler pattern elevates the security of a browser-based application to the same level as a correctly implemented OAuth-secured website. In fact, it can exceed the security of older SAML websites.

Hardened Browser Security

Many older website technology stacks do not support the latest protections or may make it easy to misconfigure security settings. For example, they may use long-lived session cookies that increase the security impact of a stolen cookie header.

By contrast, modern implementations, especially those designed by security experts, can stay aligned with evolving browser standards. For example, if you migrate SAML apps to the Curity Identity Server, you can upgrade to OAuth by deploying the Curity Token Handler as a BFF. This enables a hardened setup that surpasses the security posture of most traditional websites:

SameSite and CORS protections restrict cookie access to an SPA’s precise origin.
A modern cookie encryption algorithm ensures confidentiality and integrity.
Short-lived cookies (e.g., 15 minutes) reduce the impact of cookie theft.
Pushed Authorization Requests (PAR) prevent browser tampering of OAuth requests.
JWT client assertions provide strong backend OAuth client credentials.

User Consent Best Practices in the Age of AI Agents

Michal Trojanowski — Wed, 20 Aug 2025 00:00:00 GMT

Every day we use systems, applications, and websites for all sorts of purposes — work, personal, entertainment. Many systems are interconnected, where you might use one application to aggregate data and another to modify data.

Think of an application that books a restaurant table that can access your calendar to add a reminder about the booking. Whenever you delegate access from one application to another — especially when they come from different vendors — you want to remain in full control of what the delegate will be able to do in the remote system.

This is a mechanism that we call consent; you give explicit consent as to what an application will be able to do in your name. With the rising popularity of autonomous agents, large language model-powered (LLM-powered) applications that can perform actions on other applications, the need for consent management for AI agents becomes even more important than ever.

What is User Consent and How Does It Empower Users?

In the context of applications and digital systems, consent is the explicit granting of privileges to an application. When a user wants one application to be able to access their data or act on their behalf in another application, they need to acknowledge:

What application is asking to be granted access?
To what application will the access be granted?
What data will the asking application be able to read?
What data will the asking application be able to modify?
For how long will the asking application have this access?

Collecting explicit user consent happens when the two applications in question come from different vendors, what we call “third-party applications” (less commonly, it can also happen when the applications come from the same vendor but are governed by different terms and conditions). When a mobile application from company A wants to access a backend API of that company, it will normally not ask for explicit consent.

The user already granted consent to how the company processes their data when they created an account with company A. When the application wants to access APIs that belong to another company, however, the user should have explicit control over this.

When the user is supposed to grant access, they are presented with a consent screen that should contain all the relevant information needed to make an informed decision. It is a tricky balancing act — the screen should not be cluttered with too much information nor be too vague.

The user should be able to easily identify what application is asking for access and what it will do with their data. Below is an example of a well-designed consent screen used by GitHub:

Clear information on the consent screen also helps prevent impersonation attacks, where a malicious application pretends to be a legitimate one. Furthermore, it allows the user to ensure that they give an application the minimum amount of privileges that it needs to perform its intended tasks.

Very often, consent is asked for only once for a given application. Once you give the application access to a given set of privileges, you will not have to do it again, unless the application wants to change the set of permissions. This means that organizations should allow users to manage the consents they’ve given.

You should be able to browse which applications you granted access to and revoke it if needed, like when you no longer use the application or you have a suspicion that access to that application was compromised.

Enter AI Agents

AI agents are hailed as the next step in the evolution of AI applications. LLM-based applications offer a natural-language interface to query the model for information. They allow you to freely converse with the chatbot. These applications gain the ability to perform actual tasks, like placing orders or bookings, sending emails, or filling in and submitting forms. To achieve that, agents use their ability to invoke preprogrammed “tools.”

There are different approaches to how a tool is implemented in an AI application, but a popular approach means calling an API to read or modify data. As the AI application is calling an API, it means that it becomes that API’s client, with the usual client attributes - it needs credentials to call the API on the user’s behalf.

One of the most popular approaches for applications to gain access to APIs is to use OAuth and access tokens. OAuth is an established standard that supports granting least-privilege access to limit what the application is able to do at the API. OAuth flows, used to obtain tokens, also support the collection of granular user consent for autonomous agents. Applications use scopes to get credentials with limited capabilities, and users can use that information to decide whether to grant or deny access to their data.

This approach can be used in pretty much the same way when working with AI agents.

Consent in the Context of AI Agents

From a purely technical perspective, an AI agent is just another client that requires access to the API — it needs to obtain access tokens to be able to perform actions on the API. However, agents have some important differences from the applications that we are used to operating. When you use a “regular” application, most of the time, it is you who is actually operating it. You click on buttons, enter data into form fields, and select options.

Even if the application or system has parts that are automated, or run in the background, you are pretty confident of the actions that will be undertaken — if you click a button that says “move all files,” you don’t expect the application to start sending emails. When you introduce an AI agent, however, you add a sort of intermediary that is capable of some autonomy.

This means that the agent can decide to perform some actions because it “thinks” it needs to do it to fulfill the task that you originally asked it to do. You might not have total control of the actions that the agent will perform. And sometimes, unfortunately, the actions can meander into an unexpected territory, either because the agent “hallucinated” what it needed to do, or it was accidentally or deliberately tricked through prompt injection to take some dubious actions. Because of this, modern user consent for AI agents must guarantee that users retain full control over any AI-driven action.

This is why you should approach the topic of consent a bit differently when it comes to agents. Firstly, you should treat all agents like third-party applications. This means that the user should give explicit consent whenever delegating access to an AI agent. It allows the user to stay informed of what actions the agent will be able to perform and for how long. This ensures proper user control over AI agent actions and prevents unintended behavior.

The Need for Fine-Grained Permissions

Secondly, the consent should be even more fine-grained when it comes to the privileges the agent receives. Ideally, the agent should receive only the permissions it needs to perform the concrete action that it currently plans to perform — if the agent decided that it needs to check the content of emails and properly label them, then the access token should not allow the agent to send or delete emails. This means that backend systems and APIs should be prepared to operate with a granular approach to authorization.

Time-Limited and Transaction-Based Consent

Finally, you want the consent to always be time-limited, unlike with regular applications. The consent should automatically expire so that the agent is not able to unexpectedly gain access to a system after some time. Even better, the consent should not be persisted and given on a per-transaction basis—the user should be prompted for consent every time the agent asks for a new set of tokens.

Balancing Usability With Security

Following such an approach can mean that the user will have to give their consent numerous times during one session with an agent or even during the processing of a request. This becomes a delicate but important balancing act - the user should not be overwhelmed with the consents, as it raises the risk of blindly approving everything. At the same time, the user should not be limited to giving consent only once, with overprivileged access.

Best Practices for Granting AI Agents Access to APIs

The best practices below outline how you, as a user, should behave when interacting with AI agents. However, to be able to act this way, AI applications vendors and API vendors must ensure that they implement their systems in a way that allows users to adhere to these recommendations. These recommendations describe how users should behave, but serve as a guideline to vendors.

Always Limit the API Privileges of AI Agents

You should employ the rule of least privilege — give the agent the minimum set of permissions to perform the task at hand. This way, you limit any abuse the agent could perform. It’s better to grant the agent permissions numerous times, increasing the privilege if required, than allowing the agent to have over-privileged access to APIs.

Make Sure the User Consent Expires

Ensure that the consent you grant to an agent expires. Ideally, the consent should be valid only for the time of the current request or session. This means that you will have to consent every time the agent needs a new set of tokens to call the API. Note that asking for consent is unrelated to any user session you might have with the token provider.

You shouldn’t have to reauthenticate every time you see the consent screen. Vendors should allow you to choose how long you are granting the consent. For longer-running jobs, or when you know that the agent will constantly work in the background, you might want to grant a longer-living consent.

Use Reconsent Before High Privilege Operations

In some cases, the AI agent may receive an initial access token and then need to perform a higher privilege API operation that is outside the original user’s consent. APIs can deny access and trigger step-up authentication where the user must again grant consent. The AI agent can then be issued an access token with a higher privilege scope that the API accepts, ensuring ongoing consent management for AI-driven actions.

Customize User Consents

Vendors should allow you to tailor the contents of the consent. In some cases, consent can mean that the user grants access but places additional conditions. When the user consents to a scope, claims associated with that scope get issued to access tokens. Some claims can originate from user input, such as values the user inputs into a custom consent form. The following form shows an example where the user consents to a level of access but with a user-defined limit on a transaction and the time of access that an AI agent can use.

Allow Revocation of Long-Lived Consents

If you assign the agent long-lasting access, then make sure that the vendor allows you to manage the consent after granting it. You should be able to revoke the consent at any time, like if you no longer plan to use the agent or if you learn that the agent has been breached or is otherwise faulty. Revoking consent will, in effect, invalidate any refresh tokens, as the agent will not be able to use them to get new access tokens. Ideally, revoking consent should also revoke any active access tokens.

Conclusion

In current systems, the consent screen tends to be lacking — either it is too vague or too detailed, or it does not give the user the necessary options. With the rising popularity of AI agents, it becomes more important than ever to properly acquire the user’s consent — what they allow the agent to do in their name.

This requires careful and informed actions from users, but is only possible if users have the right tools available. Vendors of both backend systems and AI agents should take this into consideration and ensure that their products offer the correct features for the whole ecosystem to remain secure.

Learn more about how Curity helps to secure IAM in the age of AI.

Quantum-safe API Security

Judith Kahrer — Tue, 05 Aug 2025 00:00:00 GMT

How to Prepare APIs for the Post-quantum Future

Quantum computing changes the security assumptions for APIs. With the help of specialized algorithms, quantum computers can speed up calculations and potentially break common cryptographic algorithms. To keep data safe, things need to change. This article discusses controls that you should take to boost an API security architecture and prepare for quantum computing.

Fortunately, several practical steps - including robust token design and proxy configuration - already allow teams to build quantum-resilient APIs today, even before new cryptographic standards are fully deployed.

What is Quantum Computing?

Quantum computing takes advantage of physical properties such as superposition and entanglement. Superposition allows tiny particles to be in multiple energy states at once, while entanglement links particles so their states remain synchronized, even across distance.

While conventional computers operate on “bits” to store information that can either be on (1) or off (0), quantum computers use quantum bits, “qubits”, that can be in multiple states. That is, qubits can be zero, one and anything in between at the same time. Furthermore, the states of qubits can be entangled giving a quantum computer exceptionally much more computing power. As a result, the main benefits of quantum computing are parallelism and processing speed.

Quantum computers are not good at everything; they perform very well for special computations. It turns out that quantum computers are good at breaking crypto, which impacts the techniques used to protect APIs and business data.

What is the Impact of Quantum Computing on API Security?

API security relies heavily on cryptographic algorithms to deliver key security properties such as confidentiality, integrity, authenticity and non-repudiation. These typically rely on mathematical problems that are difficult for traditional computers to solve.

Quantum computers change the current state of the art significantly. They can eventually solve common cryptographic problems in a fraction of time compared to conventional computing (e.g., hours instead of years). Such computers are called Cryptographically Relevant Quantum Computers (CRQC). They basically deprecate many common cryptographic algorithms.

In practical terms, there is a risk that transport encryption such as HTTPS can be decrypted and requests manipulated on the fly, or that unauthorized parties can create valid signatures to undermine any integrity and authenticity. In other words, the availability of CRQC potentially breaks common API security controls and neutralizes any trust in digital communications.

There are still challenges with quantum computing that prevent a big rollout of CRQCs. Quantum computers are error-prone, for example, and can only process a limited amount of data. So far, researchers have only managed to crack RSA with very small keys (such as 80-bit) using quantum computers. However, attackers may already harvest encrypted data for later decryption with CRQC (an attack called “harvest now, decrypt later”), putting data from the past (archived documents), present and future at risk.

Researchers estimate that a quantum computer with less than a million noisy qubits could factor a 2048-bit RSA integer in less than a week. In line with that risk, NIST recommends in its initial public draft deprecating ECDSA, EdDSA and RSA in 2030 and stopping using them after 2035. Similarly, the European Commission recommends member states to transfer to post-quantum cryptography as soon as possible.

What is Post-Quantum Cryptography?

Post-quantum cryptography (PQC) encompasses algorithms whose security properties hold despite the processing power of quantum computers of tomorrow. It means that not even cryptographically relevant quantum computers will be able to break such algorithms, decipher encrypted communication or calculate private keys from public keys. Other names for post-quantum cryptography are quantum-proof, quantum-resilient or quantum-safe cryptography (QSC).

Standardization and guidance is very important when it comes to the selection of cryptographic algorithms. The following list includes algorithms that either the National Institute of Standards and Technology (NIST) or the German Federal Office for Information Security (BSI) calls out to be quantum-safe.

Key Agreement: FrodoKem, ML-KEM

Symmetric Encryption: AES

Hash Functions: SHA2, SHA3

Message Authentication Code: HMAC, CMAC

Signature Schemes: ML-DSA, SLH-DSA

The above list includes new and traditional algorithms because cryptographically relevant quantum computers have a higher impact on asymmetric algorithms than on symmetric ones. If you are already using SHA2, and AES such as AES-GCM, for example, then you may not have to change (much) in certain areas of your API security architecture.

How Does Quantum Computing Affect the Curity Identity Server?

The Curity Identity Server uses cryptography across several key areas. Here’s how it’s affected.

Area	Algorithms (available)	Quantum-Safe	Comment
Configuration	AES	yes
Hashing functions	SHA2 (SHA-256, SHA-512)	yes
TLS 1.3 (Handshake)	ECDSA, EdDSA, RSA	Not yet	Can be solved via a reverse proxy that supports TLS 1.3 with quantum-safe algorithms.
TLS 1.3 (Encryption)	AES-GCM	yes
Access Tokens	N/A	yes	External clients receive access and refresh tokens with an unguessable and quantum-safe opaque access token format.
Token Signatures	RSA, ECDSA, EdDSA	Not yet	Mostly used in the internal network, where APIs receive JWT access tokens. Future product versions will support quantum-safe signature algorithms.
Symmetric Signatures	HMAC-SHA	yes
Symmetric encryption	AES	yes

The above table lists two current vulnerabilities: TLS and token signatures. TLS is typically out of hand of the Curity Identity Server as the TLS communication terminates at an API gateway.

a proxy. It means that you don’t have to rely on Curity to solve the problem but can address it independently via the proxy. This leaves token signatures as the only open issue. With the correct architecture, you don’t even have to bother with that.

Phantom Tokens: A Practical, Quantum-Safe Token Strategy

Curity has been advocating the phantom token approach as a best practice for years. Typically we explain the privacy and architecture benefits. But it turns out that phantom tokens are also the most effective and immediately implementable strategy for quantum-safe access tokens.

The phantom token approach is simple to understand:

The authorization server issues opaque, random tokens (not JWTs).
Clients receive and use these non-parsable tokens.
At runtime, the API gateway introspects the token and exchanges it for a signed JWT inside the trusted network.

Opaque access tokens are quantum-safe tokens. They are random strings that the authorization server associates with some data. The only way to determine whether an opaque access token is valid, is via the authorization server using a protocol called introspection. A cryptographically relevant quantum computer cannot craft a valid, opaque token to pass validity checks.

With opaque tokens, a quantum computer must guess the correct value. It may, at best, be quicker to generate new random values than conventional computers, but it still needs to try each guess to check whether it found a valid token that gives access. This is no different from the current threat of brute forcing.

You should address the threat of brute force independently from the quantum computing risks. What is more, since brute force is not a new risk, you most likely already have controls in place. For example, you may already use mechanisms such as rate limiting and cooldowns to restrict requests with invalid access tokens.

By simply changing to opaque access tokens and applying the phantom token approach, you can reduce the API risks of quantum computing to those of brute force attacks. There is no need to support new, complex algorithms for access tokens that you return to external clients. Once quantum-safe algorithms are available, you can also update the internal network to use them without changing your deployment architecture. The phantom token approach is therefore future-proof.

Conclusion

Cryptographically relevant quantum computers (CRQC) appear scary because of their impact on the current ecosystem. Some solutions require a switch to post-quantum algorithms. For example, to mitigate the risk of harvest-now-decrypt-later threats, change to TLS 1.3 with quantum-safe algorithms in your reverse proxy or API gateway. Some proxy vendors already support quantum-safe TLS.

When it comes to access tokens, you can use the phantom token approach to achieve a post-quantum solution without quantum-safe algorithms. Sometimes, the simplest solutions are the best and most robust. The phantom token approach is one of them. The Curity Identity Server supports the phantom token pattern out of the box - letting you build secure, scalable, and quantum-resilient API architectures today.

5 Ways Curity Identity Server Solves Modern Identity Challenges

Stefan Nilsson — Wed, 16 Jul 2025 00:00:00 GMT

Identity is no longer a backend concern. It’s at the heart of digital security, user experience, and compliance. As organizations scale across cloud environments, adapt to shifting regulations, and serve increasingly diverse users, the need for a flexible and future-ready identity management solution has never been greater.

That’s where the Curity Identity Server comes in. Designed for real-world complexity, Curity offers a powerful solution that meets the needs of modern identity teams. From its adaptable architecture to its robust authentication capabilities and deployment flexibility, the Curity Identity Server empowers organizations to build secure, scalable identity infrastructure without compromising on customer experience.

In this article, I’ll share five key reasons why the Curity Identity Server stands out—and how it helps identity teams solve everyday challenges.

Key takeaways

Identity is central to security, compliance, and user experience
Organizations face recurring challenges in managing identity
Curity Identity Server provides practical, standards-based solutions

1. Flexible Architecture Built for Complex Environments

Today’s identity environments aren’t simple. Most organizations manage a mix of on-premise systems, cloud-native apps, and third-party services across multiple regions. The Curity Identity Server is designed for this complexity.

Its modular architecture, based on separation of concerns, allows teams to configure and extend functionality without reengineering their stack. Whether you’re rolling out multi-factor authentication across services or integrating legacy apps into a modern flow, Curity provides the tools to do it securely.

The server also supports microservices and event-driven systems, making it easy to embed identity services wherever needed. For security teams, that means fewer workarounds. For developers, it means faster, smoother integration. Together, these capabilities help maintain an effective identity lifecycle.

Key benefits:

Works across hybrid, multi-cloud, and legacy environments
Integrates with internal systems and third-party APIs
Reduces complexity while giving more control over authentication logic

2. Advanced Authentication Flows That Adapt to Real-World Use Cases

Authentication is rarely one-size-fits-all. Users, devices, and security contexts vary—and the authentication experience should reflect that.

The Curity Identity Server enables advanced, adaptable authentication flows that match real-world requirements without becoming unmanageable. At its core is user journey orchestration, which lets teams design chained and conditional authentication flows.

You can easily combine methods such as passwordless authentication, multi-factor authentication (MFA), and identity federation into a single, seamless user journey. Flows can also adapt dynamically to risk signals, user context, or application needs.

Examples include:

Triggering extra authentication for sensitive actions, like wire transfers
Using WebAuthn for strong security, while keeping fallbacks for older systems

With Curity, you balance security and user experience—without writing custom code or duplicating setup across apps.

Key benefits:

Chain and customize authentication using built-in or custom authenticators
Adjust flows based on user context, device, or risk level
Implement modern methods like Passkeys, WebAuthn, social login, or e-IDs
Keep your setup flexible and future-ready with reusable building blocks

3. Deployment Freedom: Cloud-Native, On-Prem, or Hybrid

Every organization has unique infrastructure needs. Some are fully cloud-native, others rely on critical on-premise systems, and many use hybrid models.

The Curity Identity Server is built with modern deployment practices in mind. It runs natively in Kubernetes and supports containerized environments out of the box, making it a natural fit for cloud-native DevOps teams. It’s equally capable in traditional on-premise setups, supporting secure, high-performance deployments in data centers and private clouds. This flexibility means identity doesn’t become a blocker as your infrastructure evolves.

Key benefits:

Deploy in AWS, Azure, GCP, on-prem, or any environment
Support hybrid and multi-cloud setups seamlessly
Enable high availability and scaling with modern orchestration tools
Align identity with your DevOps strategy

This flexibility ensures identity adapts to your infrastructure—not the other way around. That means less technical debt, fewer compromises, and smoother paths to your goals.

4. Data Sovereignty and Regional Compliance

As privacy laws tighten, identity systems must secure access and respect where data is stored and processed. The Curity Identity Server supports data sovereignty, helping organizations meet regional compliance requirements while staying scalable.

Curity makes it easy to deploy identity services in specific regions, so they can run closer to your users and their data. This helps you meet privacy regulations like GDPR, CCPA, and other laws that require sensitive data to stay within certain geographic areas. Whether you're operating in the EU, North America, or across multiple regions, Curity gives you the control to meet local compliance needs without added complexity.

In addition to the option of regional deployment, the Curity Identity Server supports fine-grained policy controls for authentication, data handling, and consent. You can configure flows to meet local compliance needs, audit user consent actions, and enforce data minimization by ensuring only necessary information is processed.

Key benefits:

Deploy services in specific regions to meet data laws
Align authentication and processing policies with regulations
Support compliance without architectural compromises

5. Seamless Integration and Developer-Friendly Operations

Identity must integrate easily with existing systems and workflows. The Curity Identity Server is designed for this, helping teams connect identity and access control without adding complexity.

Advanced configuration features let teams manage identity settings through version control, treating them like infrastructure-as-code. This supports DevOps and GitOps workflows, improves consistency, and reduces manual errors.

The Curity Identity Server also supports a wide range of standard protocols, including OAuth, OpenID Connect, and SCIM. This ensures compatibility with internal applications, third-party services, and access management tools. Clear documentation, flexible tooling, and templated patterns help teams move quickly without compromising security.

Key benefits:

Integrates with existing systems and CI/CD pipelines
Supports automation and infrastructure-as-code practices
Works with apps and services through open standards
Speeds up secure delivery of identity features

Conclusion

As identity becomes more central to digital security, user experience, and regulatory compliance, organizations need a solution that doesn’t force trade-offs between control, scalability, and flexibility.

The Curity Identity Server delivers:

Flexible architecture for complex environments
Advanced authentication for real-world needs
Deployment freedom across cloud, on-prem, and hybrid setups
Strong support for data sovereignty and compliance
Seamless integration that fits DevOps practices

Curious how Curity could support your identity strategy? Reach out to our team or book a meeting to see how the Curity Identity Server can help you build a secure, scalable, future-ready identity infrastructure.

Redefining IAM for Customers and Partners

Curity — Tue, 01 Jul 2025 00:00:00 GMT

The traditional B2C/B2B identity model no longer fits today’s digital landscape. The 2025 Gartner® report Innovation Insight for Customer and Partner Identity and Access Management contains new insights. This shift is crucial to effectively manage customer (CIAM) and partner (PIAM) identities.

So what does this shift mean in practice? Here are the top takeaways from the Gartner report and what they mean for your IAM strategy.

Redefine B2C and B2B to no longer represent user constituencies but instead describe collections of IAM functionality: one targeted at supporting individuals (B2C) and one targeted at supporting organizations.
CIAM tools manage identity, authentication, and authorization for customer identity use cases and will typically require a combination of B2C and functionality.
Uses for PIAM technologies include partner and vendor collaboration, including distributors, dealers, brokers, and supply chain activities.
These AM use cases have both overlapping and discrete drivers: CIAM’s focus is user experience, privacy, and security; PIAM’s focus is secure and controlled access for external business entities and partners.

Recommendations

If you’re updating or overhauling your IAM strategy, these are the steps Gartner recommends for IAM leaders:

Modify the definition of functionalities known as “B2C” and “B2B” in CIAM and PIAM projects. Success can be achieved through redefining these terms in CIAM and PIAM use cases as AM services for individuals (B2C) and AM services for organizations (B2B).
Build a solid foundation for CIAM and PIAM projects by investigating and understanding the unique requirements for both use cases and addressing each as a unique and discrete initiative in your IAM program.
For PIAM, plan early for identity data and identity provider (IdP) integration strategies, both from a self-service (B2C) and federation (B2B) perspective.
For CIAM, plan early for integration with adjacent tools, such as DXPs, CPM tools, and identity verification (IDV) tools.
Balance user experience and security. It is tempting to go “all in” and protect all attack surfaces in CIAM and PIAM initiatives as much as possible. However, adding overly strict ATO prevention controls can cause friction and compromise the UX, ultimately frustrating existing consumers, prospects, and partners.

By following these steps, we believe organizations can better support identity-driven use cases across all sectors.

Market Snapshot

As identity needs grow, so does the market response. As per the report, “CIAM has a market penetration of a little over 40%, and the technology is in the early mainstream stage of maturity.” Meanwhile, PIAM is just gaining momentum; most implementations are still custom-built, but new vendors are entering the space with purpose-built tools.

This trend reflects a broader industry shift away from building in-house IAM platforms toward purchasing specialized, integrated solutions, reducing costs while improving security and user experience.

Conclusion

The bottom line? Identity today is more complex and more strategic than ever. The Gartner Innovation Insight for Customer and Partner Identity and Access Management report makes it clear that effective IAM today means moving past rigid B2C/B2B labels and embracing flexible, user-focused strategies. By tailoring identity services for individuals and organizations, businesses can streamline access, reduce risk, and support both growth and compliance. Dig into the full report here.

Gartner, Innovation Insight for Customer and Partner Identity and Access Management, Michael Kelley, Abhyuday Data, Akif Khan, Nathan Harris, 28 April 2025

A Decade of Identity Innovation: Curity at 10

Curity — Tue, 17 Jun 2025 00:00:00 GMT

This month, Curity turns 10. We sat down with one of the founders - Curity CTO Jacob Ideskog - to reflect on the journey so far and what lies ahead.

From day one, our vision has been clear: to make the internet safer by managing identity in a way that respects both privacy and security. That mission still drives us. What’s changed is the scale. Today, Curity powers a wide range of complex identity environments, all while staying true to the architectural principles we started with.

We’ve always taken a pragmatic approach to product development - solving real-world problems rather than building for edge cases or hypothetical futures, and deliberately avoiding technical debt. As Jacob says in the video:

At Curity, we take the time to do things properly. If we find something that needs to be redone, we take that time. Security is an architectural concern, but in software, it’s about getting all the details right.

Ten years in, we’re still doing the hard things well and thoroughly: securing complex systems, staying flexible, and building a product where security is in the details. Along the way, our global team has grown (and is still growing) - and with it, a shared mindset to challenge the status quo and keep improving.

Thanks for being part of the journey so far.

Watch the video to hear the full story:

What is Access Control?

Bill Doerrfeld — Tue, 03 Jun 2025 00:00:00 GMT

Access control is a cybersecurity mechanism that determines whether a requesting party — be it a user, device, API, or application — can access a resource or conduct an action. It consists of two foundational processes: authentication (verifying identity) and authorization (granting privileges based on identity and context). Together, they form the backbone of access control security.

Modern systems contain sensitive data and personally identifiable information (PII), so it's essential to implement access control methods that restrict unauthorized access and enforce compliance. Whether you're managing cloud environments, APIs, or legacy enterprise databases, robust access control solutions are critical for protecting confidentiality, integrity, and availability (CIA).

Types of Access Control

There are several types of access control in security, each suited to different use cases. Let's break them down by category:

Authentication and Access Control

Authentication methods confirm identity using multiple factors. Security professionals tend to group these into three core areas:

Something you know (password or PIN)
Something you have (OTP or hardware token)
Something you are (biometric data)

Common technologies include passkeys, one-time passwords (OTP), FIDO-based authenticators, and apps like Google Authenticator. Multi-factor authentication (MFA) uses two or more of these for stronger protection.

Authorization and Access Control

Authorization mechanisms determine what a verified user or system can do. There are three primary types:

Role-based access control (RBAC): Users are grouped by job function, and permissions are assigned based on roles. For example, admins, developers, and read-only users each have distinct access scopes. This is common in API access control and enterprise apps.
Attribute-based access control (ABAC): Permissions are based on user, resource, or environment attributes. For example, users over a certain age can access age-restricted content, or employees in a specific department can view internal reports.
Policy-based access control (PBAC): Access decisions are based on conditional, context-aware rules such as time of day, IP address, device, or location. PBAC often builds on ABAC by using policy engines to evaluate complex rules across many attributes.

These access control methods can be layered and combined for more dynamic and granular authorization.

Systems That Use Access Control

Many systems actively utilize access control to enhance their security posture. For instance, enterprise software relies on application access control to guard against external threats and insider misuse. In distributed environments, API access control ensures only trusted clients and services can retrieve or modify data, especially across microservices.

Industries like healthcare and finance are legally required to implement strict access control policies. Regulations such as HIPAA and GDPR demand that systems restrict access to authorized individuals, log activity, and enforce data minimization. In these contexts, authentication and access control are not optional — they're vital for meeting audit and compliance standards.

Modern access control solutions are often integrated into API gateways, identity and access management (IAM) platforms, and customer identity and access management (CIAM) systems. These technologies support employees, customers, and partners by granting different roles and permission scopes. For developers, managing access through centralized policies also simplifies implementation across teams and services.

The Benefits of Quality Access Control

Access control is critical for protecting systems from unauthorized access and abuse. Broken authentication is quite commonplace, and hackers continually scan to detect and exploit such gaps. Proper access control reduces the risk of unnecessary overexposure, which could result in legal consequences and financial losses.

It also helps enforce the principle of least privilege, ensuring that users and services have access only to what they require. This limits overexposure, improves system efficiency, and supports more secure defaults. As a result, organizations can reduce unnecessary data sharing and build leaner, more manageable systems.

Lastly, having a standard, decoupled access control mechanism benefits developers greatly. Instead of having to build their own authentication, authorization, and IAM solutions for each project, teams can rely on consistent, reusable policies. This streamlines development and supports a scalable approach to access management across the organization.

Implementing Access Control

Access control is typically implemented through a combination of identity standards and security protocols. Many organizations use IAM platforms to authenticate users, issue tokens, and manage authorization. These platforms often integrate with legacy identity systems like Microsoft Active Directory, LDAP directories, or SAML-based providers, as well as modern frameworks like OpenID Connect.

At runtime, a user or machine receives a token (usually a JSON Web Token (JWT)) from an authorization server. This token defines the scopes and claims associated with the request, which downstream systems use to enforce access decisions. These flows are typically based on OAuth 2.0, which provides flexible methods for securing APIs and applications.

In a token-based architecture, identity systems must validate tokens carefully to check their signature, issuer, and expiration to avoid misused or spoofed credentials. Organizations may also use Open Policy Agent (OPA) or similar tools to define access rules as code, enabling automated policy enforcement. Effective access control depends on these layered components working together to verify identity and apply consistent rules.

The Future of Access Control

Access control continues to evolve alongside trends in identity and security. For example, decentralized identity frameworks are emerging, enabling users to manage credentials independently while still supporting secure verification. These models use verifiable credentials stored in digital wallets.

As cloud adoption grows, access control solutions must also account for sovereign cloud requirements and data residency laws. This means adapting policies dynamically based on location, jurisdiction, or regional infrastructure.

However, as access control expands in complexity, organizations must also consider user experience. Access control must balance security with usability through streamlined login flows, delegated consent, and contextual prompts.

Access control is also expanding to include non-human actors. From bots and scripts to AI agents and IoT devices, systems must now manage credentials for machine entities. As all these interactions scale, security and access control will be key to managing complexity while maintaining trust across heterogeneous systems that involve various requesting parties.

Transaction Tokens: The New Phantom Tokens?

Michal Trojanowski — Tue, 20 May 2025 00:00:00 GMT

Software environments are constantly evolving. Changes to architectures, technologies, and company structures affect the threats our systems face. It is common nowadays to break down systems into smaller components that can handle concrete features. Sometimes this means adopting a microservice approach. But even if the system operates as a monolith, it will often rely on other components that it connects with via APIs. This means that nearly every request a backend system processes these days will eventually travel through a few services.

The popularity of componentized architectures has led security experts to develop solutions that allow processing requests more securely and adhere to zero-trust principles. The IETF’s OAuth working group has proposed a solution as a new standard: transaction tokens. A transaction token is a security credential that complements the usage of access tokens to provide stronger security. In this post, I will explain in more detail what transaction tokens are and the reasons for using them. I will also compare the technology to a pattern that we’ve advocated at Curity for almost a decade now — the phantom token pattern.

Why Do You Need Transaction Tokens?

In an architecture where one request traverses multiple services and components, it becomes important to view security from a zero-trust perspective and not rely solely on perimeter security. In a perimeter security approach, requests inside the infrastructure have implicit trust, which can lead to vulnerabilities.

Once the token is validated at the perimeter, the internal traffic uses implicit trust.

In this setup, if any of the services or components become compromised, then an attacker gains unlimited access to all elements of the system and can inflict a lot of damage to the company’s business. A component can become compromised in various ways:

A service uses an insecure implementation in its code that allows an external attacker to take control of the service, also known as remote code execution (RCE).
A service uses dependencies that become the target of a supply-chain attack, and an external attacker manages to breach a service despite correct security measures implemented in code.
An external attacker manages to break into the company’s virtual internal network using vulnerabilities in a public cloud used by the company.
A rogue employee operates from inside the company to steal the company’s data.

Companies can implement two types of security measures to create a zero-trust environment: infrastructure-level security and application-level security.

With infrastructure-level security, you lock down which services can talk to each other. If one service becomes breached, then the attacker can only call a limited number of services in the infrastructure. This limits the amount of data they can steal, but it does not offer complete protection. For example, an order-processing service might have access to a service that holds information about users’ addresses or credit cards. If the order service is compromised, the attacker can steal the sensitive data by querying the credit card service. This is where application-level security comes in.

With application-level security, you lock down the caller so that they can only operate on a limited set of data. This is where you use solutions like access tokens to authorize a request — for instance, a user can only request their own credit cards and addresses when placing an order.

Using a zero-trust approach also means that every service in the call chain independently authorizes the request using the incoming access token. If an attacker manages to breach the order service now, they won’t be able to steal any data from the credit card service, as they would also need to steal an access token that allows them to query the credit card service.

Even though the system now uses access tokens to limit access, the token might have too many privileges, which can still lead to data loss. If an attacker manages to get hold of an access token, they might still be able to perform attacks on the systems:

If the attacker manages to steal access tokens from the breached service, they can reuse them to call the company’s APIs to steal more data.
If the attacker manages to get an access token out-of-band, they can use it from the breached service to call other services, as access tokens have no information about the context in which the token is used — the services don’t know if the token is used as part of a legitimate request, or if it is used to perform an attack.

Transaction tokens try to address the above issues.

How Do Transaction Tokens Work?

When a system uses transaction tokens, it swaps an access token for the transaction token to be used for the duration of a given request.

A request that uses transaction tokens.

When the system starts processing an incoming request, it first exchanges the incoming access token for a transaction token. This should happen early in the process, so an API gateway will usually be the place that performs the exchange. The API gateway will send the access token to the token service (the authorization server if the system uses OAuth) and receive a specially prepared JSON Web Token (JWT) that should contain:

Relevant information associated with the access token that services might need for authorization, like the subject ID or the subject’s roles.
A unique ID of the current request (transaction) that can be used to correlate information about the request and prevent token replay.
Information about the request’s context, like the endpoint called and the HTTP method used, or the requester’s IP address.

The gateway then passes down the transaction token in a Txn-Token HTTP header, so it is not confused with an access token. A receiving service can then verify the context of the request and properly authorize the token subject. If an attacker manages to intercept such a token, they will not be able to use it at external-facing API endpoints (as this is not an access token recognized by the API gateway). They also will not be able to use it outside the token’s context, like calling other internal services with the token. The attacker will have only a limited time to try to abuse the token, as transaction tokens should have a lifespan limited to the request’s expected processing time.

Additionally, the specification enables services to replace transaction tokens and update them with new context information. This also allows a service to verify that a proper call chain was adhered to for the concrete transaction. For example, a payment processing service could accept a transaction token only if the context contained information that a fraud prevention service previously handled the request.

The Phantom Token Pattern

At Curity, we’ve been recommending using the phantom token pattern to protect the access token from some abuses. When using the pattern, the token service always issues an opaque token to clients (applications). Then, when an API gateway receives the opaque token, it performs token introspection and gets a JWT with all the information corresponding to the opaque token. The gateway then uses the JWT as the access token when passing the request down to internal services.

A request that uses the phantom token approach.

The JWT representation of the access token can only be used by internal services, hence the phantom token name — the original application would not be able to use it, and in fact, never knows of the existence of such a token. Internal services can conveniently use the token to authorize requests, but it can’t be replayed against public API endpoints, as it doesn’t match the original access token.

The phantom token pattern solves some of the issues that transaction tokens tackle, but there are also some differences between the two approaches.

The Similarities Between Transaction and Phantom Tokens

Let’s start with what the two approaches have in common. Both transaction tokens and phantom tokens use JWTs as a secure and convenient format for credentials. Services can easily verify the integrity of a JWT, and the token carries all the required information so that services can process it offline — this cuts down the amount of traffic between services processing requests and the token service.

Both solutions require that systems use different tokens inside and outside their infrastructure. This protects from the threat of an attacker stealing access tokens on an internal network and then reusing them at public-facing APIs. This is the main threat that both solutions help to tackle.

How Are Transaction and Phantom Tokens Different?

The phantom token approach expects the token service to issue opaque tokens to external clients. This allows protecting the token’s content. With an opaque token, no party handling the token can read its associated data. This means that the token can be safely associated with sensitive or personal information that internal services need for authorization purposes. The transaction tokens specification only describes how internal tokens are created and used, and does not impose any format on external tokens.

Transaction tokens are locked down to one concrete transaction or request, and they can include information about the request’s context. Phantom tokens do not contain this information. The introspected JWT is valid for the duration of the original access token’s lifespan, and every introspection request should yield the same JWT — the introspection response is cacheable. This also means that phantom tokens can’t carry information about the current call chain, something that transaction tokens can be used for.

The two approaches use different standards:

Phantom tokens utilize a variant of the introspection specification,
Transaction tokens are implemented using the token exchange specification.

This means the token service must support different solutions to implement these approaches. The implementation also varies on the services’ side, even though both approaches use JWTs. Phantom tokens are forwarded in the Authorization HTTP header, meaning services can work with standard libraries that handle authorization and JWT validation. Transaction tokens, on the other hand, are forwarded in a proprietary header, which requires bespoke authorization implementation, because there are still no libraries that support the standard.

How to Implement Transaction and Phantom Tokens

The two solutions are complementary, and you might consider implementing them both. However you decide to create the implementation, you should always fulfill some crucial requirements:

Always use opaque tokens when sending tokens outside your infrastructure.
Never use the same token outside and inside your infrastructure.
Once inside your infrastructure, enrich the token with additional information that can further limit its usage (like the request context).

Fulfilling the above requirements will usually mean following these steps:

Ensure that your token service (like the authorization server if you are using OAuth) issues an opaque token to clients that operate outside your infrastructure, like mobile apps or web apps.
Have your API gateway introspect or exchange the opaque token for a JWT. Then use the JWT among services when processing the request.
Enrich tokens with additional information when performing an exchange, so that the token contains information about the request context.

You will be left with an architectural decision, depending on the concrete requirements of your setup. You can either implement the transaction token standard (thus ensure proper JWT formatting and use headers required by the specification) or forward tokens in the usual Authorization header to simplify integration with your existing services.

Conclusion

Phantom tokens and transaction tokens are two approaches that help you solve concrete issues of a distributed system. While they both protect against internal token theft, they also have features that complement each other, so you might consider implementing both (or creating implementations that will take their best parts). For now, implementing the phantom token approach should be less intrusive, as it relies on a standard way for token validation in services. As the Transaction Tokens specification is in a draft state, the implementation details might still change. However, once it is published as an RFC, it will facilitate interoperability, and the industry will probably publish libraries for handling transaction tokens.

OAuth: What Everyone Should Know

Judith Kahrer — Wed, 23 Apr 2025 00:00:00 GMT

When you work as intensely with a certain technology as my colleagues and I do, you get a clear picture of how it works and should work. At some point, you realize that you have become an expert in your field; in our case, it’s OAuth. This is also the point where things that are obvious to you are not for others.

Securing API access is part of data security

OAuth enables integrated solutions between users, clients (applications), and APIs. OAuth systems provide the client with an access token with restricted API access. Although there are many guides on OAuth, they are commonly limited to retrieving the access token. As experts, we know there is much more to OAuth than sending the right protocol messages.

We found that there was a gap in the specialist literature around providing organizations with the strategies to integrate OAuth in particular ways so that security facilitates (modern) technologies and meets developer experiences. We realized that to make the internet a safer place, we needed to make our know-how available to the broader community. Slowly but surely, the idea of a book was born.

We decided on the title “Cloud Native Data Security with OAuth.” Some people may think the title is controversial because OAuth is all about securing access, while data security tends to be about securing data storage and encryption. However, this is exactly the pattern that we want to disrupt. You cannot talk about access control and authorization without also considering the data you want to protect. The goal of OAuth is to protect data (authorization) that APIs expose. It focuses on cloud native because it allows us to recommend solutions you can run anywhere.

Authentication is secondary to authorization

In OWASP’s top 10 API security risks list, broken authorization takes the front rank. It means that you need to secure access beyond simply authenticating users because your attackers may already have logged in, e.g., via stolen or compromised credentials.

Of course, securing the authentication process is part of the game. However, authorization is not the primary concern because authorization is about granting the least privileges to (authenticated) users. Newcomers to OAuth often focus on user authentication. Many misunderstand that the heart of OAuth is the content of the access token that should enable APIs to enforce least privilege access.

For data security with OAuth, you should rely on identity attributes when evaluating access control policies. For this, you should map scopes to a certain set of identity data to model the access token. The access token and related data are the source for APIs to enforce access rules. This approach combines token-based with attribute-based access control and provides a good foundation for an API security architecture.

A good access token design is essential for API security. Therefore, we devote a whole chapter to access token design, so that you can scale the use of access tokens to many APIs and clients.

There is more to access tokens than their attributes. The API gateway, for example, plays a vital role in an API security architecture with OAuth, as it provides the public interface of an API. The API gateway can compensate for client-application specifics so that you can implement a unified approach for access controls in API services. Having one way to do things simplifies development and, as a result, reduces vulnerabilities.

Cloud-native technology gives you many choices

The cloud-native aspect of the book focuses on choices like where you store identity data, the components you can use, and where you can operate OAuth. For example, it highlights how to integrate workload identities in an OAuth architecture to strengthen credentials.

The book lists best practices for client applications to address the weakest links in the security chain. It provides guidance and examples on implementing OAuth in browser-based and platform-specific applications (“native applications”), covering desktop and mobile clients.

The cloud native focus enables us to provide code examples that show how to run end-to-end OAuth flows with exactly the same technologies on local computers and cloud deployments. In the last chapter, the book discusses how to fortify authorization with strong authentication to improve assurance in the identity attributes.

In the end, implementing data security with OAuth is all about the attributes — the characteristics you provide to gain access to data. This is very apparent to us, but we found this message was missing in the OAuth-related literature. We filled the gap with Cloud Native Data Security with OAuth so that more people can utilize the building blocks OAuth provides and combine them with cloud-native technology to protect business assets in a secure and scalable way.

Why InsuranceTech Companies Need to Rethink Identity Security

Jonas Iggbom — Wed, 09 Apr 2025 00:00:00 GMT

Insurers are building faster, smarter, always-on digital experiences to keep up with customer demands. Whether it’s a mobile claim submission or API-powered policy updates, the industry is fully embracing digital transformation. But here’s the problem: every new convenience opens another door. And behind that door could be identity fraud, API abuse and compliance headaches.

Here I’ll explore why identity security needs to be at the center in these new circumstances, and how InsuranceTech firms can adopt an identity-first approach to protect their customers and business.

Modern Insurance Security Challenges

Insurance companies store large amounts of sensitive personal data, from medical records to financial details, making them prime targets for cybercriminals.

And the more digital touchpoints you offer, the bigger the attack surface becomes. We've seen this for a few years now; in a report, 42% of European insurance leaders reported a sharp rise in security vulnerabilities - and this number is most definitely growing.

Here are some of the specific security challenges insurers must address:

Identity Fraud and Account Takeovers

Fraudsters have always been impersonating customers to file false claims or steal benefits. Now they are no longer faking paperwork - they’re faking people. In the US alone, the insurance industry, excluding health insurance, already loses an estimated $40 billion per year to fraud.

The shift to online onboarding and self-service has, in some cases, made it easier for criminals to create synthetic identities or use stolen personal data. Credential stuffing and phishing attacks make things worse. With a fake but valid login, malicious actors can access personal data or submit bogus claims while appearing as legitimate users. This kind of identity breach can go undetected until significant damage is already done.

API Security Vulnerabilities

InsuranceTech applications rely heavily on APIs used for mobile apps, partner integrations, IoT devices, and more. If these APIs aren’t properly secured, they become easy targets. Attackers can often exploit stolen tokens or credentials to fool the system.

Weak API authentication or access control can let hackers pull massive amounts of customer data or even manipulate policy details.

Growing Regulatory Pressure

Insurance companies face a complex set of regulations on data security and customer privacy.

From broad frameworks like the European GDPR and California CCPA to industry-specific rules like the NAIC Insurance Data Security Model Law in the U.S., compliance requirements continue to grow.

Regulators are holding insurers accountable for protecting customer identities and reporting breaches promptly. Failing to comply can lead to legal penalties, and reputational damage. The challenge is to meet these overlapping requirements efficiently and without disruption.

Why Better UX Shouldn’t Come at the Cost of Security

Insurance is a competitive space. Customers expect instant quotes, self-service options, quick claims processing, and clear customer communication. But they also want their data to be secure. However, cumbersome logins, repetitive identity checks or multi-step forms can drive people away.

Leading insurers recognize this dilemma – they want both security and simplicity. The good news is that modern approaches can achieve both.

The Identity-First Approach

To address these challenges, InsuranceTech companies must recognize identity as the foundation of security. This involves:

Strong Authentication Across All Interactions

Given the prevalence of credential theft, insurers should deploy robust authentication methods. Multi-factor authentication (MFA) is now a baseline requirement for many apps and websites, adding an extra layer of protection against unauthorized access. Beyond MFA, passwordless authentication using biometrics, magic links, passkeys or hardware security keys enhances both security and usability.

Federated identity and single sign-on (SSO) solutions streamline authentication by allowing customers to log in via trusted digital identities, such as bank credentials or national ID systems. These methods reduce password fatigue, minimize attack surfaces, and improve user convenience.

Securing APIs with OAuth and Zero Trust Principles

APIs require identity-centric security just as much as user log-ins do. API keys are not enough on their own and can often result in serious consequences. Instead, insurers should implement OAuth 2.0 and OpenID Connect (OIDC) to manage API authentication and authorization securely.

OAuth 2.0 enables secure token-based access, ensuring that clients (mobile apps, web apps, and partner integrations) receive scoped, time-limited tokens. OpenID Connect builds on OAuth 2.0 to provide identity verification, allowing insurers to establish trust in API-driven transactions.

To further strengthen the safety of applications and APIs, InsuranceTech organizations should consider implementing the use of FAPI. This will greatly improve the process of issuing and safeguarding access tokens.

Zero Trust principles add an extra layer of security by requiring continuous verification for every access request. Instead of assuming trust, each API request needs to be validated to ensure user roles, attributes, and security context match the right permissions.

Compliance-Driven Security

An identity-first approach ensures security and compliance go hand in hand, reducing fraud risks and improving operational efficiency.

OAuth 2.0’s token-based approach ensures secure access delegation without exposing credentials, meeting key data protection requirements outlined in GDPR and similar frameworks. OpenID Connect enhances authentication assurance, simplifying identity verification and fraud prevention mandates while reducing friction for users and building customer trust in digital services.

Enhancing Customer Experience Securely

Security and convenience no longer need to be at odds. Adaptive authentication techniques dynamically adjust security requirements based on risk level:

Low-risk interactions, like checking a policy balance from a familiar device, may only require a simple login.
High-risk actions, such as changing a payout account or filing a large claim, may trigger additional authentication steps like biometric verification or multi-factor authentication (MFA).
Seamless identity proofing during the account registration process using facial recognition technologies. This involves detecting a live user as well as scanning the user's ID.

By leveraging user journey orchestration, insurers can optimize authentication flows based on real-time risk assessments. Instead of a one-size-fits-all security model, you can fine-tune authentication requirements based on behavioral patterns, location, device trust, and session history. Enforcing strong security where needed while maintaining a smooth user experience.

Conclusion

Identity security is the foundation of digital insurance. A single breached account or compromised API can break customer trust and lead to regulatory scrutiny. A strong, identity-first security strategy enables seamless user experiences, stronger fraud prevention, and business agility.

Updating identity security isn’t just about reducing risk - it facilitates growth, enables seamless integrations, and creates room for innovation.

Secure Online Banking with A Competitive Edge

Stefan Nilsson — Thu, 27 Mar 2025 00:00:00 GMT

A recent Gartner® report, Assess the Use of Banking API Standards for Competitive Advantage, explores the idea that as open banking regulations continue to grow worldwide, creating APIs for only compliance can lead to poor API uptake and limited business value. “Bank CIOs should set the vision for differentiating API products that go beyond regulatory compliance, including leveraging standards such as BIAN and FDX.” This blog post includes our main takeaways.

Moving Beyond Compliance: Secure and Competitive API Solutions

1. APIs as a Secure Alternative to Screen Scraping

Third-party fintechs often rely on screen scraping to access banking data, which increases fraud risks and compromises user credentials. By adopting FDX and other API standards, banks can provide a controlled, consent-driven data-sharing approach that enhances security while ensuring regulatory compliance.

2. Monetized API Marketplaces for Competitive Advantage

API marketplaces allow banks to showcase their API products to a broader ecosystem of partners, fintechs, and enterprise clients. Banks can monetize APIs through subscription models, transaction fees, or value-added services.

3. Real-Time Corporate Banking APIs

Corporate banking clients increasingly demand real-time access to financial data, yet many banks still rely on batch-file processing. Transitioning to real-time APIs allows banks to:

Streamline transaction processing and reconciliation
Enhance cash flow visibility for business customers
Offer premium, event-driven banking services through webhooks and streaming APIs

4. Partnerships for Digital Innovation

Strategic partnerships between banks and fintechs can drive digital transformation. Banks can integrate fintech solutions into their services through APIs, offering customers a seamless experience without building everything in-house. According to the Gartner report, “with banks lacking API maturity, the increase in banks recognizing fintechs as strategic partners to close their API and digital capability gaps rose to 89%.”

Implementing a Future-Ready API Strategy

To gain a competitive edge, CIOs should:

Invest in API Management and Security: Deploy full-lifecycle API management platforms and identity solutions like Curity to enforce consent-based access and secure authentication.
Standardize and Scale API Offerings: Adopt global standards such as ISO 20022 and BIAN to ensure interoperability and reduce development overhead.
Foster an API-Driven Culture: Establish API product management roles and promote collaboration between business and IT teams to continuously enhance API offerings.

Leveraging APIs as Strategic Assets

Banks that view APIs as strategic assets rather than compliance burdens will secure a significant competitive advantage in the evolving financial landscape. By delivering secure, scalable, and monetized API solutions, banks can foster customer loyalty, drive innovation, and position themselves as leaders in the digital financial ecosystem. Access the report here.

Gartner, Assess the Use of Banking API Standards for Competitive Advantage, Don Free, Andrew Humphreys, 6 May 2024

Is Your API Ready for the AI Agents?

Michal Trojanowski — Mon, 10 Mar 2025 00:00:00 GMT

You don’t have to be closely following the AI space to hear about AI agents. They're on everybody’s lips right now, framed as an evolution of our interaction with artificial intelligence. Tools like ChatGPT, DeepSeek, or GitHub Copilot allow you to have a “conversation” with the large language model (LLM). As a result, they might tell you what to do to fulfill your task—show you the code you should write, propose some steps you should undertake, or point you to a place where you can search for more information. Agents, on the other hand, take action on your behalf. While an AI chat can tell you where you should go to book your flight, an AI agent can book one for you. At least, that is the promise.

AI Agents Are the Next Big Thing…

… even though they’re not quite there yet. To say that the AI environment is rapidly evolving would be an understatement, and you can definitely see similarly rapid development in the AI agents space. Still, few products are completely production-ready, and many companies are still trying to figure things out.

Consider this anecdotal evidence. I recently tried out an AI agent that claims to be one of the best for travel assistance. Even though I allowed the agent to use my location (Poland) and shared my mobile number with it, the flights it proposed were priced in Australian dollars. I tried to change that but to no avail.

In the end, the agent concluded that it actually couldn’t change the currency at all and claimed that the prices were in fact in my local currency — PLN, even though they clearly were not. The whole process of trying to book a flight took a few times longer than it would have taken me if I had used a dedicated booking website, like Kayak or Expedia. It was also much more frustrating trying to figure out how to interact with the agent.

Even if the agents are not ready for the end user to utilize them, the market is clearly growing, which means that service providers should examine this space closely.

AI Agents Need Integrations

Most AI agents will eventually operate with an external service—they read data, perform searches, update data, and commit transactions. This means the agent needs a way to integrate with the external service, regardless of whether it’s a weather API, online store, or mailbox. Agents can adopt different approaches to integrating with external parties — some might mimic the user’s behavior and operate directly on the user interface, while others will operate on API, which is still the common way to integrate with external services.

This means that service providers should take this new reality into consideration when planning how to evolve their products. Consider the following:

Make sure that the service offers an API that AI agents can easily integrate with.
Create documentation that not only developers but also LLMs can consume.
Be prepared that the service might be used by an agent even when no API is exposed.

Some in the industry propose that agents will automatically find and connect to APIs they need to fulfill the user’s current request. However, this will not be as simple as it sounds. API providers should consider how to facilitate integration with agents but also acknowledge that this integration will most probably involve a limited amount of manual tasks. An AI agent will need to act as the usual API client, which means it will need a way to obtain credentials that allow it to access the API. This is important as the API provider needs its usual way to control which applications call the API and properly apply billing.

For some open APIs, like weather data or restaurant review APIs, authorization is not important. But, for APIs that handle user data or perform actions on the user’s behalf, properly authorizing API access is imperative. Even if the agent operates on its own, it will need the initial user authorization to perform certain actions. It might also require additional authorization whenever it performs a sensitive action, like placing an order or modifying the user’s data. The API providers have to start planning how these functionalities can be achieved so that agents can properly integrate with their APIs.

Let’s Not Make Stepbacks

Moving fast to develop new solutions incentivizes taking shortcuts. It is important, however, that we don’t sacrifice the good security practices we have built along the way. Consider the following AI agent example, taken from the Multi-ON Agent API:

At first sight, it may look impressive, as it allows performing an action in a fast and simple way, and uses natural language to do so. There are a couple of issues with this approach, however:

It requires disclosing user credentials to a third-party provider. Something we, the web industry, advocated to stop doing long ago (and pretty much achieved it).
It does not take multifactor authentication into consideration.
It does not allow using modern ways of authentication, like passkeys.

Utilizing AI agents should not compromise the security of our accounts nor impede the user experience. Companies should take that into consideration when thinking about the solutions.

AI Agents and Security Considerations

API providers should take time to design proper authentication and authorization solutions for AI agents, and they should remember that the necessary building blocks are already available. It’s just a matter of applying them.

OAuth

OAuth is a great framework that should form the basis of any access made by AI agents. It’s been created to solve the problem described above — it’s a way of delegating access to a user’s resources to another application. With OAuth, a user can decide what the agent will be able to do with their data, and as a result, the agent receives a credential that is limited both in time and scope — the access token. The user retains both: all the means of authenticating that they previously had and a way of having the AI agent perform some work on their behalf.

OAuth requires user interaction, and now it is up to the industry to come up with a way that provides a seamless user experience when working with agents.

Token Exchange

Once an agent obtains an access token, it can leverage the token exchange standard to obtain another token that will allow it to perform another action. If service providers can build a chain of trust among themselves, it could allow an agent to call services without needing additional authorization from the user. This will become especially important should the agent call numerous different services to perform an action. If an agent has to call five or more services and every service requires the user to authorize access, this does not result in a good user experience. If the user could authorize access only once, then the agent could exchange the token to access all the other services, creating a much smoother but still secure UX.

Dynamic Client Registration and AI Gateways

Dynamic Client Registration is a protocol that can allow agents to integrate with APIs in an automated way. Together with the aforementioned techniques — building a chain of trust and using token exchange — agents could be able to register at an API without any manual interaction whatsoever, where the initial access to the DCR endpoints is provided by another trusted service.

An emerging technology that might help with API integration is AI gateways. Similar to API gateways, these products can help introduce some central features, allowing agents to integrate more easily with external APIs.

Preparing for AI Agent Integration

AI agents might not have reached their maturity yet, but the industry is actively working on making them better. Service providers should keep that in mind and keep an eye on what is happening in the agentic-AI space. If your service is not using OAuth yet, consider adding it as a secure way for AI agents to integrate with it. If you already protect your service with OAuth, prepare for the automatic onboarding that AI agents will require to easily integrate. Remember that even if you don’t expose APIs, AI agents might be able to integrate with your services using user interfaces directly, which might mean that you have less insight into the integration. It is better to avoid such a situation and properly prepare for the agentic environment. Learn more about how Curity helps to secure IAM in the age of AI.

A Perspective on Modern Credential Management

Judith Kahrer — Tue, 25 Feb 2025 00:00:00 GMT

Managing Password Credentials

Credential management is a realm within Identity and Access Management (IAM) that focuses on the lifecycle of credentials, from provisioning, audits, and updates to deprovisioning and monitoring. In its essence, credential management is about keeping user credentials safe during transit and at rest to avoid security incidents. When it comes to passwords, credential management typically involves enforcing password complexity and password strength policies to minimize the risks of brute-force attacks and ensure secure password storage.

When passwords fall into the wrong hands, malicious actors can take over accounts and gain access (on the wrong premises, though). This often propagates to other, even unrelated, systems because users reuse the same credentials for different services. To mitigate the risk of compromised databases and password leaks, it’s crucial to salt and hash passwords before storing them in a data store.

An initial strategy for credential management could — and should! — be to minimize the places where passwords are stored. Instead of each application maintaining its own separate user directory and credential store, install a central credential management or IAM solution, such as an OAuth authorization server, to handle passwords consistently.

Moving to Central Credential Management

Centralization improves security hygiene by ensuring all applications follow the same rules. Commonly, centralization concerning credential management implies a single place for enforcing (password) policies, securely storing credentials (passwords), and monitoring and auditing events.

Centralizing credentials should not mean copying all data to a central store and abandoning all individual credential data stores at once. It should be possible to perform any transition — whether from multiple systems to a single one or from a legacy to a modern solution — while keeping business continuity and user experience in mind.

The Basis for Peaceful Transition

An IAM system should decouple credentials from user accounts to smooth the transition to centralized credential management. This means the system should manage account-related data such as usernames, emails, and user roles separately from passwords. As part of that, an IAM system should support various data sources and hashing algorithms with the possibility of more or less fully customizing integrations with existing password stores. This is important so that the IAM system can integrate with the variety of solutions that heterogeneous or legacy systems imply.

An IAM system should support retrieving passwords from multiple data sources and select the appropriate source depending on the use case such as the application the user interacts with. It can then store the password in the central data store using a secure algorithm — providing a unified approach and possibly replacing vulnerable implementations. In this way, you can integrate with the legacy systems and move users to the central system one at a time when improving credential management.

Flexibility via Decoupling

Decoupling credential management from account management provides flexibility for numerous use cases beyond credential transition. For instance, the ability to validate and store passwords using various methods allows for implementing multiple policies within the same system. Such policies can relate to different needs, such as addressing specific technical requirements or meeting compliance standards (e.g., GDPR, HIPAA).

Policies commonly vary from organization to organization. With dedicated credential management separated from account management, an IAM system can handle multitenant or even application-related differences within the same deployment. Thus, it provides an organization the freedom and flexibility to implement a solution that fits its needs for modern, secure credential management.

Three Points to Remember

From this blog post, you should take away three main points for modern credential management:

Passwords are still alive.
Centralize password management for improved security and compliance.
Decouple password management from account management to enhance flexibility.

Passwords are still in use and you have to manage them today as best as you can. The best way is to centralize password management. As part of that effort, choose an IAM system that decouples credential management from account management so that it can meet various requirements. In the long run, update your credential management strategy to focus on modernizing the credentials and authentication methods. Rely less on passwords and instead incorporate alternative authentication techniques such as multi-factor authentication (MFA) and passwordless authentication.

Identity Enables Digital Transformation Success

Jacob Ideskog — Tue, 11 Feb 2025 00:00:00 GMT

At the core of most digital transformation initiatives is a growing demand for scale as more functions are digitized, the number of applications exponentially grows, and organizations focus on acquiring more customers and serving more stakeholders online. Inevitably, the resulting increase in data and operational pressure exceeds the capabilities of individual systems and devolves into an architectural problem.

Monolithic systems that once adequately served the organization’s needs can no longer provide the fine-grained, customized functionality or multi-channel diversity required to stay competitive in today’s digital world. It is not uncommon during digital transformation initiatives for each department, business unit, or regional location to start adding specialized online tools and solutions to accommodate specific use cases.

The result is an infrastructure that morphs beyond the internal network into a tangled mass of various web apps, mobile solutions, cloud products, and AI tools - all connected to the network with individual APIs.

Digital Transformation Can Create Painful Challenges

Several challenges often arise for organizations as they undergo the digital transformation process. Multi-channel, multi-solution environments inadvertently create new problems that must be addressed before the full potential of digital transformation can be realized. These challenges include:

Additional security vulnerabilities

As more applications are added throughout the organization, the result is a proliferation of APIs introducing new entry points into the network. These connection points could include hidden vulnerabilities that attackers can exploit to gain access to systems and data.

Data silos

Adding new applications and systems introduces data sources not connected to existing data repositories within the organization. Data silos create another layer of challenges in the form of duplicate and incomplete records. Isolated data also poses cybersecurity risks by making it possible for attackers to gain entry undetected.

Inconsistent user experiences

When architectures are cobbled together during the digital transformation process, the result is often user experiences that vary between applications. In some cases, users may have multiple logins to access different services, causing frustration and poor customer engagement.

Inefficient data management

Without a unifying strategy, digitizing parts of the business can create a data environment that is difficult to manage consistently throughout the organization. Managing data and security best practices across disparate and decentralized applications becomes a daunting and resource-intensive challenge.

Regulatory violations

Inconsistent data management capabilities make it impossible to uniformly roll out and maintain privacy and security measures that adhere to mandates and laws. When security controls must be applied manually and individually to each API, it is difficult to ensure all areas of the organization comply.

Identity Management Is the Common Denominator for a Solution

Identity management intersects many of the challenges that digital transformation introduces. When the network is dispersed into a collection of external APIs and disparate systems, technology teams must rethink how information flows throughout the organization, and most importantly, how access to that information is controlled.

It is no longer enough to manage identity access and authorization at the perimeter of the network. Identity management must be woven into the fabric of the architecture in order to maintain security.

The good news is that managing identities correctly addresses many of the challenges inherent in digital transformation efforts. Connecting data to identities instead of use cases or departments can help break down data silos, deliver consistent user experiences, and facilitate efficient data management on the backend.

Similarly, strong identity management practices make it easier for organizations to uniformly implement data privacy and security protections across all APIs and data entry points in compliance with data management laws and regulations.

Integrate CIAM and IAM to Drive Digital Initiatives Forward

Customer Identity and Access Management (CIAM) allows organizations to create an identity layer that overlays data management abilities throughout the entire infrastructure. CIAM goes beyond access authentication and authorization. It provides a comprehensive identity interface for consumer-facing systems and applications.

A solid CIAM solution also gives organizations tools to deliver innovative digital experiences that help maintain a competitive edge. It establishes a centralized, efficient way to manage features, access policies, and security measures consistently across all APIs now as well as those introduced in the future.

What’s more, a robust CIAM solution enables integration with internal Identity and Access Management functions. For most businesses, a large number of APIs are associated with workforce systems. Even customer-facing applications are usually tied to back-end employee-facing solutions. Integrating CIAM with workforce IAM allows teams to effectively manage the flow of information securely across the network.

Consider implementing a CIAM and IAM architecture based on tokens to ensure that security controls are enforced at each and every API entry point. The best CIAM solutions support token-based architectures with fine-grained capabilities, enabling development teams to leverage OAuth and OpenID Connect industry standards for distributed authorization over all APIs.

CIAM Enables Ongoing Digital Transformation

Digital transformation is not a single point-in-time event. Technology continues to evolve, making digital transformation an ongoing part of doing business and keeping up with market demands.

The right CIAM solution can be a powerful ally in the continuous improvement and growth of digital operations and services. It can function as a unifying platform for managing APIs while ensuring streamlined customer experiences and employee productivity.

2025's Most Important API Security Trends

Michal Trojanowski — Tue, 28 Jan 2025 00:00:00 GMT

Security paradigms do not change on a yearly basis — look at OWASP, they released their top 10 API vulnerabilities list only twice since 2019, and problems with authorization remain the top concern. However, the environment around us and technologies do change quite rapidly, and the start of a new year is always a good point to have a closer look at the trends. At Curity we always try to keep our eyes open on the API and identity space to understand how things will evolve in the near and more distant future.

Below I describe the topics that I believe will be relevant for API developers and architects in the coming year, especially when thinking about API security.

AI Meets API

It’s definitely no surprise that AI will be an important topic in 2025. The trend that especially affects API security is the rise of AI agents — these are pieces of software capable of using other tools and APIs to perform tasks and which the user operates using natural language commands.

For example, you can ask an AI agent (using voice commands or by typing sentences) to book a flight and hotel for your next trip. The agent must then somehow integrate with a system that will eventually fulfill the task — if it finds a suitable API, then it will use it.

This means that you need to think about your API not only from an integrator’s developers’ perspective but also from AI agents’ perspective. Think how an agent will be able to find the API, understand how to use it, register, sort out billing, receive proper permissions, etc. It’s important that you know and control how agents will use your products.

Remember that even if you decide not to open up an API, some agents will be able to integrate with your products using the same interface your users utilize. You might then have less control over how the agent integrates.

APIs and AI Gateways

The abundance of AI agents and LLMs have resulted in the emergence of a new type of product on the market — AI gateways. They have similar functionality to API gateways, but are tailored for some AI-specific features. For example, they are able to route traffic to concrete LLMs and can implement centralized security features, like protections against prompt injection. You should have a look at these if you’re working with AI integrations.

Auditable Authorization

Authorization is not a trivial matter, and companies continue to search for better approaches to properly implement it. Especially in large organizations with many APIs, it’s important to ensure that authorization rules are manageable and auditable. That’s why we see a growing trend of externalizing authorization to dedicated systems.

In the coming year we will see organizations use more solutions like Open Policy Agent, OpenFGA, or Cedar, as API developers focus on trying to tame the top API vulnerability — broken authorization.

Using OPA to implement manageable and auditable authorization

Passwordless Authentication

If you’re not yet familiar with passkeys, now is the time to catch up. This cryptography-based technology will eventually replace passwords by offering better security and better usability than the classic authentication method. Major browsers and operating systems are constantly improving their support for passkeys, and this year the support is good enough to safely migrate your users to the new solution. Many websites already allow you to use them for passwordless logins, with some big-player examples being Gmail, Paypal, and GitHub.

Even though it’s not a technology that you will use directly in APIs, improving the security of your users’ authentication improves the security of your APIs and data — it’s harder to steal data through your APIs. Especially because passkeys come with an important security improvement — they are phishing-resistant by design because every passkey is tied to a specific domain name.

Verifiable Credentials

In 2024 there was a bit less buzz around verifiable credentials, but this does not mean that they are less relevant. On the contrary, the standards are becoming more mature, and more and more countries are closer to rolling out nationwide wallets, or at least finalizing regulations (like the EU’s eIDAS).

VCs will not become widely available in 2025, but they are coming, and companies should be prepared. As Jacob Ideskog explained in this Nordic APIs Platform Summit keynote talk, their introduction will impact APIs as well. As users will have more control over their data and what they share with other parties, APIs will have to ensure that they are ready for potentially limited user information.

Zero-Trust Security in Cloud Native Environments

In a microservice and cloud environment, it is important to understand that perimeter security is no longer sufficient. When you work with distributed systems, you want to ensure that every service and every instance is able to strongly authenticate and authorize the callers—the user or software that initiated the request, the other service in your system that is calling this service, or the machine instance that is calling this machine instance.

This is the work that the IETF’s working group Workload Identities in Multi System Environments (WIMSE) is trying to wrap its head around. Watch their space this year as they will be publishing their first best practice documents that will facilitate secure implementations of zero-trust solutions that consider both application-level security (access tokens) and infrastructure-level security (mTLS and SPIFFE).

A big part of WIMSE work is dealing with “workload identities”, that is, identities of applications and instances. Managing these identities is an important part of your system’s security. This year OWASP released a new list from their top 10 series that tackles specifically the risks associated with, what they call, “non-human identities”.

Sender-Constrained Tokens

The vast majority of APIs are secured with bearer tokens. When an API receives such a token, it only checks whether the token itself is valid and whether the requested action is allowed. The API does not check whether the sender was allowed to actually use that token, because it has no means of verifying that.

This means that when someone manages to intercept an access token, they can call your APIs and steal data, and you might not even notice the theft because they will be using legitimate tokens. With sender-constrained tokens, you tie the token to the application that initially received the access token.

There are now standards and solutions that allow the use of sender-constrained tokens on almost any device. For example, you can resort to things like Dynamic Client Registration (DCR) and Demonstrating Proof of Possession (DPoP) to change bearer tokens into sender-constrained tokens in mobile apps. I think that in 2025 more APIs should require its integrators to use sender-constrained tokens to better protect their users’ data.

A malicious client cannot reuse a stolen sender-constrained token

Evolving the API Spec

We’ve lived with the OpenAPI spec for a long time now, and most people in the API space are familiar with it and most probably use it. Its maturity does not mean stagnation, and I don’t mean just new versions of the spec itself. There are new tools emerging that enhance working with API specifications.

Two notable examples that you will hear more about in the coming year are Typespec and Arazzo. Typespec introduces a new, code-like, typescript-like way of writing the API specification, which is then transpiled into a standard OpenAPI YAML. Arazzo allows using YAML in a standardized way to define API workflows, something that, until now, has been missing from the OpenAPI spec.

An interesting new approach that is emerging in the space of specifications is the Common Architecture Language Model, which tries to standardize architecture as code.

The Great Unbundling and Cloud Repatriation

I heard the term “the great unbundling” quite a few times last year, and I think the trend will continue. It means that companies will continue using smaller API tools that are tailored for concrete jobs rather than using large platforms that offer every solution possible. This trend allows companies to find solutions with more specific features.

It also allows them to more easily switch vendors as they don’t need to swap every feature at once. Smaller vendors also tend to react more swiftly to new trends and needs, thus offering new features more quickly. In the API security space, this will allow companies to more easily integrate with new, innovative products that provide better security solutions.

Another trend I noticed emerging last year is cloud repatriation — companies now tend to go back to private, self-hosted clouds and infrastructure, because costs of using public clouds often spiraled out of control. Leaving public clouds means also regaining control of the physical location of data, which became important with the advent of regulations like GDPR and CCPA. This does not directly affect API security, but abandoning public clouds can require changes to infrastructure-level security.

Look Beyond AI

Going into 2025 we should look beyond AI. It’s definitely all over the place now, but it’s far from being the only, or the most important thing, happening in the API security space. 2025 will be an interesting year for APIs, and I think we will see many technologies both emerge and mature as the year progresses.

API security will be as relevant as ever, and I hope that we will finish the year with more secure APIs. Maybe the next OWASP top 10 list will have to look for a new vulnerability to crown.

Strengthen M&A Cybersecurity with Zero Trust Architecture

Stefan Nilsson — Thu, 16 Jan 2025 00:00:00 GMT

Merger and acquisition (M&A) activity can bring opportunities for growth and innovation, but it can also increase cybersecurity risks. M&A announcements often draw the attention of threat actors making the organization a prime target for attacks. In some cases, acquired companies have reported phishing attempt increases as high as 400% after releasing news of a deal.

Many businesses have complex, customized IT infrastructures. Combining them brings up issues like incompatible systems, legacy technology, differences in security maturity, and varying regulatory requirements. Compounding the cybersecurity challenge is the tight timeframes that IT and cybersecurity teams must work within to help the business rapidly realize investment returns. Existing vulnerabilities can be exposed while the risk of introducing new attacker entry points rises. Cybercriminals often seek to capitalize on these security weaknesses during an M&A transition.

Network Perimeter Security Falls Short

At the center of this heightened risk dynamic are two main elements - digital identities and API connections. Cyber threat actors typically gain access to systems and data by compromising employee and customer accounts, including accounts in apps connected to the network via APIs.

When companies rely on traditional network perimeter security methods, identities and API connections are indirectly protected behind broad security measures like network firewalls and system-level permissions and controls. This broad approach to security breaks down during an M&A transition when data is decoupled from network-level security controls and migrated into a new network.

It can be difficult to consistently implement network-level security measures across all entry points and possible use case scenarios during a migration. The result is that developer and cybersecurity teams find themselves executing security tactics for each use case, regulation, department, tool, app or service.

Replicating these controls can take immense amounts of time and tie up resources. Plus, the scope of this manual effort makes it easy to make mistakes that can open up more opportunities for attackers.

Perimeter Security vs Zero Trust

Zero Trust Architectures (ZTA) can help circumvent the weaknesses of traditional security in M&A scenarios by focusing on access authorization at the identity and API level. Zero Trust Security assumes that no user, device or app can be trusted until its identity can be verified.

It relies on authentication and authorization controls applied directly to identity data and APIs. This approach results in several advantages for M&A transitions.

Benefits of Zero Trust Security

Reduce Security Risks

A hallmark feature of Zero Trust Architecture is network microsegmentation. If an attacker does gain access, they are restricted to one area instead of moving freely throughout the network. The practice of least privilege access further helps to confine an attacker’s movement by ensuring users, APIs, and devices obtain only the access and permissions needed to perform relevant tasks.

Additionally, systems and devices are not automatically trusted in Zero Trust Architectures. This can help teams identify potential security vulnerabilities before they become part of the network. ZTA also centralizes infrastructure management so teams can uniformly apply security controls across the network and correctly allocate security measures limited to specific regions or use cases.

Simplify Integration

Identity and access management (IAM) sits at the core of successful Zero Trust Architectures. IAM centralizes access management making it possible to easily onboard employees and customers from the acquired organization.

Fine-grained access level permissions can also be applied to each account and correctly enforced. Plus, developers can uniformly apply security controls across the network and correctly allocate security measures limited to specific regions or use cases.

Maximize Deal Value

A zero trust approach to security can help organizations realize a return on acquisition investment sooner. By simplifying integration, ZTA enables developer and security teams to complete the IT transition more efficiently and quickly.

It can also help minimize data and service access disruptions for employees and customers so the business continues to operate effectively. What’s more, it reduces security risks and the likelihood of a costly data breach triggered by the merger.

How to Implement Identity-level Security in ZTA

Establishing security around identities and APIs is a key aspect of Zero Trust Architecture. With the right systems in place, including an advanced identity server and a reverse proxy, such as an API gateway, developers can configure highly secure identity and access management capabilities.

They can customize authentication to the newly merged business use cases. Here are some best practices to consider when designing an identity infrastructure capable of handling an M&A scenario.

Strengthen Authentication Methods

When merging systems, identities and APIs, single or weak authentication methods can become a security liability. Layer additional authentication requirements using Multi-factor Authentication (MFA) and introduce stronger authentication methods, such as biometric and passwordless authentication.

Use the Token Handler Pattern

Implement the Token Handler Pattern to maintain security in an omnichannel environment that manages access from multiple device types, including single-page applications, mobile and web browsers. This pattern leverages OAuth and OpenID protocols to create a backend-for-frontend authentication flow that keeps sensitive token data out of browsers where it can be stolen.

Limit Authorization

Carefully consider the context for each use case and user type. Then limit authorization to only the permissions that are necessary for the scenario. If an attacker is able to breach the network, this can significantly reduce the damage.

Leverage Industry Standards

Look to industry standards, like OAuth and OpenID Connect, as much as possible to lean on already established best practices and protocols. Similarly, use certified security profiles, like OpenID’s Financial-grade API (FAPI) profile.

Not only will this simplify regulatory compliance, but it also provides additional assurance that the most-up-to-date and effective security measures are in place. Plus, it lays a foundation for future regulations and technology innovation.

Build a Path to More Secure M&A IT Integrations

Whether an organization is acquiring or being acquired, investing in Zero Trust Architecture can help make the M&A process easier and more profitable for both entities. What’s more, ZTA’s benefits, including stronger security and faster time to market for new products and services, will continue well into the future.

Stopping the Heist: How FAPI Secures Your APIs Against Modern-Day Thieves

Michal Trojanowski — Tue, 10 Dec 2024 00:00:00 GMT

The world of APIs is a big city filled with opportunities, where sensitive data is equal to cash in a bank vault. But as we know from movies, there is always a share of masterminds out there planning their next big heist. Similarly, APIs attract attackers eager to exploit vulnerabilities. No matter your industry, the challenge remains the same: stay ahead of the attackers and prevent breaches before they happen.

The Financial-grade API (FAPI) security profile from the OpenID Foundation is a high-tech security protocol designed to stop attackers or at least make their task much harder. Originally created for financial institutions, its principles apply across industries. Let’s explore how to protect your APIs like a security system stopping a heist, preventing bad actors from walking away with your data.

Step 1: Lock the Vault – Centralize Configurations

Imagine you’re guarding a vault with multiple entry points. If each door is managed separately, inconsistencies and possible vulnerabilities create easy opportunities for intruders. The same goes for APIs - fragmented security configurations leave your ecosystem exposed.

FAPI acts as the blueprint for securing the vault. It centralizes configurations across your APIs using metadata endpoints, automatically guiding clients to the right settings. This eliminates guesswork and prevents attackers from sneaking in through misconfigurations or outdated defenses.

With every API aligned to the same high standards, you minimize weak links, streamline operations, and enhance your ability to respond to threats. Just as a well-secured vault doesn’t rely on mismatched locks, centralized configurations ensure your entire API system is uniformly secure and resilient.

Step 2: Secure the Keys – Protect Your Tokens

Tokens are the keys to your API vault. If an attacker gets their hands on them, they can open the doors and access sensitive data. Protecting these tokens is critical to keeping your APIs secure.

FAPI provides a range of safeguards to ensure these keys can’t be used by criminals:

Keep Tokens Out of Sight: Tokens should always be kept in headers, never in URLs where they might be exposed in logs or intercepted.
Bind Tokens to Clients: Certificate-bound tokens or Proof of Possession (PoP) ensure that stolen tokens are useless without the private keys tied to them.
Protect Refresh Tokens: Compromised refresh tokens allow attackers to generate new access tokens, so securing them is just as vital as guarding the access tokens themselves.
Reinforce Access Points: Confidential clients, dynamic client registration, and client attestation (for mobile apps) act as additional barriers, ensuring only legitimate apps can use tokens.

Just as a skilled thief can bypass a weak lock, attackers can exploit poorly secured tokens. By implementing these layers of protection, you ensure your tokens remain locked down, even if an attacker manages to breach one layer of defense.

Step 3: Secure the Escape Routes – Avoid Misconfigurations

Every great heist requires an escape route, but in API security, misconfigurations accidentally create those escape paths for attackers. Redirect URI mix-ups, for instance, allow intruders to reroute authorization responses to their own systems.

FAPI closes these loopholes with recommendations like push authorization requests (PAR), which secure the authorization request, preventing their interception and abuse.

Authorization code injection is another common risk. Implementing the authorization code flow with Proof Key for Code Exchange (PKCE) ensures attackers can’t use stolen authorization codes. By following standards like OAuth and OpenID Connect, and automating configurations with metadata endpoints, you reduce human error and seal off escape routes attackers might exploit.

Step 4: Upgrade the Alarm System – Strengthen Authorization Flows

Even if thieves breach the perimeter, a robust alarm system can stop them before they reach the goods. PKCE is that alarm system for APIs, ensuring authorization flows are secure.

Originally designed for mobile apps, PKCE is now recognized as a good practice for all client types. It adds an extra layer of security by requiring a dynamic, client-generated secret during the authorization process. This makes it much harder for attackers to use intercepted authorization codes.

By enabling PKCE in your OAuth flows, you create a strong final line of defense that’s simple to implement but highly effective in preventing unauthorized access.

No Heist Here – FAPI is on Guard

While FAPI originated in the financial sector, its principles extend far beyond banking. Any organization handling sensitive data can benefit from the added security FAPI provides.

By centralizing configurations, safeguarding tokens, and reinforcing your authorization flows with measures like PKCE and Proof of Possession, you create an API system so secure that even the most resourceful attackers will move on to easier targets.

Just like a bank heist can leave lasting damage on its reputation and customer trust, an API breach can harm your brand and break the confidence of your customers. Protecting your APIs with FAPI safeguards not only your data but also the trust and loyalty your business depends on.