Identity and Access Management (IAM) is undergoing a significant transformation. Modern use cases demand more - more identities, more complexity, more speed, and far more dynamic behavior than traditional IAM was designed for. Meeting those demands requires a mindshift in IAM from static rules based on user permissions to dynamic rules with a holistic view that includes both human and non-human identities.
To meet these demands, IAM needs a new mental model—one that moves beyond static, user-centric permissions toward context-aware, dynamic authorization.
Why User-Centric IAM Falls Short in Modern API Architectures
Most IAM systems are built around a simple question: “Is this user allowed to perform this action?”.
This model works well in controlled environments where the main challenge is human user login.In modern architectures, authorizing solely on user permissions neglects an important detail, though: users never perform requests on their own.
Technically, it's always an application that makes requests on behalf of a user. In fact, some applications do not even operate in an end-user context. So when authorization decisions are based only on user permissions, an important part of the picture is missing. The system has no way of understanding how a request is made or whether it is expected in that context.
Users never perform requests on their own - they always depend on applications to perform requests, present data, and interact with data.
Application-Centric IAM: A Better Model for APIs and AI
A more accurate way to think about IAM is to start with the application.
Applications exist to fulfill a purpose. They interact with APIs—some act on behalf of users, others operate independently. Treating all requests as if they come directly from a user flattens this difference.
The application-centric approach decouples the permissions applications have from the permissions a user has. It lets you define rules where one application may act on behalf of a user in one way and another application in another way. Many companies realize just now that this mindset is extremely useful for emerging use cases such as AI and automation where actions are delegated and context changes continuously.
What APIs Need: Context for Authorization
Ultimately, applications access data from backend systems (APIs). The important questions to answer are:
whether the application is allowed (expected) to send certain requests (access certain data), and
whether the API should allow the request (release data) given the current circumstances.
To be able to enforce authorization rules, the backend systems (APIs) need information, some context - called claims. APIs may need a user identity to authorize a request. They may also need an application identity or other data. Ultimately, what information they need depends on the rules.
To securely grant access to the assets, APIs need data - data that gives them the power to evaluate whether, according to their rules, it is safe to allow a request in the current context.
The Curity Token Intelligence: Turning Context into Authorization Decisions
This is where Curity’s token intelligence comes in. Instead of being simple credentials, they become carriers of context providing APIs with the information needed to make access decisions based on real-world conditions. This enables a more dynamic and precise form of authorizations, supporting least privilege access and easily adapting to changing scenarios.
The Curity Identity Server enables you to define permissions for applications (based on their expected behavior) and to provide data (claims) that help the backend system to perform authorization. This approach makes it, for example, comparably easy to support AI use cases with the Curity Identity Server. AI use cases require just-in-time, least-privilege access, which you can convey via access tokens. As mentioned before, this approach also implies a mental model that is fundamentally different from the mental model of other vendors.
The Curity Identity Server utilizes a mental model that enables the enforcement of challenging authorization rules, including AI use cases, with the help of specialized access tokens.
Curity acknowledges that authentication and authorization are very specific to a context. Consequently, the Curity Identity Server is highly customizable both in terms of user authentication and the authorization details that it can provide to the backend system via access tokens. The latter is what we refer to as "Token Intelligence".
Further Reading:
