The API Security Maturity Model
On this page
API security has become a forefront issue for modern enterprises. As API attacks grow in frequency and sophistication, organizations need a structured way to evaluate and improve their security posture. Too often, APIs only adopt HTTP basic authentication, API keys, or token-based authentication, overlooking a major concern: identity. To prevent vulnerabilities and reap efficiency benefits, a comprehensive identity focus is critical for fully evolved APIs.
This is why we've created the API Security Maturity Model, a framework that outlines progressive levels of protection based on identity, authorization, and trust. Inspired by the Richardson Maturity Model, which outlines increasing degrees of web service development maturity, the API Security Maturity Model reframes the model within the context of security. Within this model, security and trust are improved the higher up you go. As a result, organizations are provided with a roadmap to adopt better API security practices, transitioning from basic controls to robust identity-based architectures.
The Different Levels of the API Security Model
- Level 0: API Keys and Basic Authentication
- Level 1: Token-Based Authentication
- Level 2: Token-Based Authorization
- Level 3: Centralized Trust Using Claims
The more evolved the API security is, the more identity emphasis it tends to have. So, how do we encapsulate identity with APIs and make it useful? APIs that utilize OAuth and OpenID Connect can take advantage of claims, an advanced form of trust. Tokens such as JWTs utilizing subject and context attributes can delegate platform-wide trust.
More on the specifics of that below. But first, let's expand on each maturity stage within the model to understand its benefits and drawbacks.
Level 0: API Keys and Basic Authentication
APIs at Level 0 use basic authentication or API keys to verify API calls. These are inserted within the header or body of the URL of the API request. This is the level of security that most APIs adopt. Most APIs established this authentication years ago and, unfortunately, never evolved from there.
For example, consider an e-commerce store. It makes API calls to a payment API based on user purchases. It sends authentication in the form of an API key or basic authentication in the header to the app and passes it to APIs. The user ID is placed in the body or URL. In the example below, there are two APIs: BILLING and INVENTORY. Since HTTP basic authentication or API keys only authenticate the STORE_WEB, the store must pass on user data.
The Problems with Level 0
You may be thinking: aren't API keys sufficient? Well, this method is very basic, fraught with vulnerabilities. Not only are keys constantly compromised, but API key verification relies on machine-to-machine verification, not bound to the identity of the user at all. Lastly, this method only provides authentication, the act of proving an assertion, and does not cover authorization at all.
Level 1: Token-Based Authentication
APIs at Level 1 utilize access tokens for authentication within a token-based architecture. Such access tokens delineate the type of user (machine, app, user, etc.). As this enables privileged access, it helps in environments where the separation of internal and external users is required. Level 1 provides better auditing since user identity is part of the request.
For example, consider token-based authentication at the e-commerce store. When we introduce a back office, the same problem occurs. Custom logic is needed to know if the request is a back-office request with elevated privileges or if it comes from the store web.
The Problems with Level 1
At Level 1, anyone with a token can modify the API, meaning privileged access can be hacked. Furthermore, Level 1 only covers authentication, not authorization. In other words, this strategy doesn't ask what are you allowed to do? When only using tokens for authentication, all authorization becomes custom code. Thus, custom mechanisms like if statements must be coded. This is negated in Levels 2 and 3, where you can utilize token data for authorization, thus generalizing authorization logic.
Level 2: Token-Based Authorization
APIs at Level 2 are more evolved, using token-based architecture for authorization. Authorization delineates privileges for the requesting party, asking what are you allowed to do? APIs in Level 2 adopt OAuth, a widely adopted authorization standard in which client requests require an OAuth server for authorization. Maintained by the IETF, OAuth 2.0 defines varying flows to obtain tokens, enabling the ability to grant access to resources without the need for a password.
One great benefit of OAuth is scopes. Scopes can be utilized as “named permissions” within a token. These scopes can specify user privileges. OpenID Connect defines standard scopes that can be used to generate standard identity arguments. Or, you can create custom scopes for your API. Scopes have more useful data and are better than building if statements into a system.
Let's consider our e-commerce store again. Now, we introduce scopes, so that the public web store and back office can have different privileges. However, some operations overlap. The Scope LIST is used to list invoices in the billing API. The ID to list for is in the URL or passed as a request parameter. Thus, it's possible to manipulate the call to list invoices for another user. Thus, the Scope is not sufficient. Scopes also lock down what the client application is allowed to do; they don't help with the particular user since they are only “names” and not “values.” Instead, claims, should be used so that the parameter is baked into the token. Then it's easy to separate back office privileges from store_web privileges.
The Problems with Level 2
By introducing OAuth 2.0 and scopes, this level marks a shift toward proper authorization and separation of concerns. But scopes alone are not enough for rich authorization — APIs need contextual validation, role awareness, and runtime evaluation to fully secure transactions.
Level 3: Centralized Trust Using Claims
The final tier, Level 3, is the most evolved API security platform. This level reflects the principles of zero trust security and advanced identity and access management (IAM). Here, secure API design becomes centered on verifying claims issued by trusted identity providers, often using JSON Web Tokens (JWTs) with verifiable digital signatures. In doing so, we solve all the problems outlined above.
What are JWTs? Well, to clarify common misconceptions, a JWT is NOT a protocol. It is a signed piece of data. OAuth flows utilize JWTs to verify transactions. JWTs can be used to share scopes.
And claims? Claims are essentially assertions. For example, consider a written statement: “Jacob is an identity specialist, says Travis.” This claim has a subject (Jacob), an attribute (that he is an identity specialist), and an asserting party (Travis). If you trust Travis, then you trust the claim. Many attributes can make up identity. There are subject attributes, like name, age, height, weight, etc. For these attributes, the asserting party would be the police or tax authorities. There are also context attributes, such as the situation, timing, location, weather, etc.
Instead of trusting the attributes themselves, it is far better to trust claims made by common parties. Identity systems use claims with similar anatomy for verification. If you trust the OAuth server that issues keys, then you trust the claim being made. To verify a claim (simplified):
- The requesting party calls the issuer
- Issuer returns data, signed with a private key
- Requesting party sends to another party
- Replying party verifies the signature with a public key
This method solves the issue of trust, by trusting the issuer of tokens rather than the claims themselves.
JWTs Require OAuth & OpenID Connect
In cybersecurity, it's rarely encouraged to invent your own traffic rules. For centralized trust to function, authorization systems require the use of stable protocols. Just as street traffic follows common protocols, identity systems require their own shared open standards. These protocols are OAuth and OpenID Connect. Utilizing these standards, an app can share secure, asserted data within JWTs for verification.
Claims: Highly-Evolved Identity-Based API Security
Trust is a subjective thing. In designing a secure API-based system, should we trust keys, tokens, passwords, machines, or users themselves? The answer is more complex than most API designers think, and maybe pivotal to safeguarding your platform as a whole.
As the API Security Maturity Model displays, highly mature APIs place trust in very few sources. Especially, these evolved APIs place trust in the issuer of tokens. This does not guarantee the truth, but is the closest representation to validating the identity of the requesting parties. Furthermore, standardizing this process with centralized trust removes spaghetti code and wasted effort on custom code.
Essentially, the pinnacle of API security is to trust claims, not attributes. When building an identity-based API security system based on claims, remember some best practices:
- Organize sensitive data so that only the identity server can access it
- Include identity data in the token, not context attributes
- Opaque tokens for the public, JWTs internally
- Limit data exposure only to when the client needs it
- Avoid app-specific rules
Why the API Security Maturity Model Matters
The API Security Maturity Model is not just a theory - it's a practical tool for CISOs, architects, and developers to improve their API security posture. It helps organizations to:
- Identify gaps in current API authentication and authorization strategies
- Adopt secure coding practices for API design and integration
- Implement zero trust principles through identity-centric controls
- Reduce reliance on custom access logic and improve maintainability
- Protect against evolving threats in the modern API landscape
As APIs continue to power mobile apps, cloud services, and microservices, adopting a maturity model approach ensures security is not an afterthought but a foundational design principle.
Jacob Ideskog
Identity Specialist and CTO at Curity
Frequently Asked Questions
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
