CIAM and API Security
On this page
A Customer Identity and Access Management (CIAM) system should meet the detailed business security requirements for an organization's digital solution, to protect access to business data. In modern architectures, that business data is exposed by APIs or microservices.
User-facing areas are the most visible part of CIAM. For example, an organization may want external users of their products to get a themed login experience and choices over how they authenticate. However, the deeper CIAM capabilities enable secure API access, ensuring API security, data protection, and compliance with modern standards.
Modern CIAM solutions are a foundational component of API security architecture. This article explains the invisible steps so that APIs can implement authorization in modern ways and receive the context they need to make authorization decisions.
CIAM End-to-End Flow
A modern CIAM system uses interoperable security standards. To enable APIs to protect business data the CIAM solution should use security standards centred around the OAuth 2.0 Authorization Framework. The CIAM system then acts as an authorization server. The following diagram shows an end-to-end flow, where a client (application) redirects to the authorization server to authenticate users. After user authentication, the client gets an access token that it uses to interact with APIs.
Externalizing user authentication reduces code and future complexity. This means that if there are multiple applications, it requires the same few lines of code to authenticate users. Many people within the software industry understand this benefit of a CIAM system and how it improves the time to market.
On the API side of the architecture, there are even more compelling benefits to using a CIAM platform. However, to realize authorization benefits, you must clarify your API security requirements and do some large-scale thinking on the following topics.
- API Authorization Design
- Consistent API Authorization
- Token Issuance Foundations
API Authorization Design
APIs should base authorize on the access token. A CIAM system should issue access tokens that represent the right level of access. In addition, a CIAM solution should serve API teams and enable them to implement authorization logic productively. To implement such a CIAM solution, you should use the following design principles.
- Limit each client's access tokens to particular APIs by business area.
- Meet each API's requirements for user identifiers.
- Provide each API with the security-related values it needs to restrict access.
- Protect security-related values so that an attacker cannot alter them.
- Use API auditing to measure how secure resources are accessed in real time.
- Scale the use of API authorization over time.
A Customer IAM system should enable you to easily partition access to APIs using strings called scopes. These can be any fixed strings that you design, but think of it as slicing up your business based on areas of data sensitivity. Within each scope, you configure claims, which are evaluated at runtime for the authenticated user, then issued to tokens that have that scope. Used correctly, this is a simple and highly scalable mechanism.
Consistent API Authorization
API should authorize access using JWT Access Tokens, where strong asymmetric cryptography protects the integrity of the payload. This means a malicious party cannot create or change access tokens. In code, the claims in token payloads become an object with which the API can authorize and lock down access to business resources.
The following example payload has a scope that restricts usage to a trades business area. APIs for a different business area should immediately reject the access token. The API also receives an existing business user identity in the user_id claim and uses it to restrict access to resources that the user owns.
{"scope": "trades","sub": "8027379034","user_id": 2998,"given_name": "John","family_name": "Doe","roles": ["trader"],"locations": ["NY"]}
Claims are the main building block to enable authorization. A CIAM system should enable you to issue any custom claims you need to access tokens, regardless of where the underlying values are stored.
When required, API developers can derive additional fine-grained business rules or permissions (which may change often) from the claims in the access token. For example, a role might have many permissions, in which case you only need to issue a role claim to the access token and not all of the permissions. Such an approach gives each team autonomy and prevents manageability problems as you scale the use of access tokens to many APIs.
You can even externalize most authorization responsibilities from API code to an Entitlement Management System that enables policy-based authorization. With policy-based authorization you can share authorization rules across APIs, consolidate auditing of resource access and make it easier to change authorization dynamically, without requiring API code changes or redeployments. Authorization can then audit access and aggregate audit events to a system that security teams use to monitor resource access at scale.
The following diagram illustrates an example end-to-end policy-based authorization approach. Security teams create identity policies in the CIAM system that result in APIs receiving the most useful tokens via the client application. Security teams also distribute authorization policies to a Policy Decision Points (PDP). The PDP can be distributed and deployed with each API as shown in the diagram. Each API acts as a Policy Execution Point (PEP) that calls the PDP with an access token. The access token is a Policy Information Point (PIP) since it provides additional input to the policies via claims that the PDP then uses for authorization. Finally, aggregated audit events can enable security teams to understand secure resource access at scale.
Token Issuance Foundations
To issue APIs with your preferred access tokens, you need to take control over identity data. Aim to manage user accounts in the CIAM system, to make it easier to handle regulatory concerns like Privacy and GDPR. The CIAM system may be able to connect to existing user data sources. Alternatively, it may provide User Management APIs that allow for migrating users to the CIAM system.
The following JSON payload represents a user account using the SCIM schema. Among the standard attributes, the user data also includes the custom attributes locations and userId. If the CIAM system supports it, you can use such a payload to create a user account with custom attributes, and later have the CIAM system resolve those attributes to claims during token issuance.
{"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],"userId": 2998,"name": {"givenName": "John","familyName": "Doe",},"emails": [{"value": "john.doe@example.com","primary": true}],"roles": [{"value": "trader","primary": true,},],"locations": ["NY"],"active": true,}
When required, you can separate the storage of user attributes across multiple data sources. For example, you might prefer to store main user attributes in the CIAM system but manage product-specific user settings in APIs if that improves manageability. If you need to include such product-specific settings in tokens, the CIAM system should be able to retrieve the claim values from the APIs at the time of token issuance.
User account attributes are not the only source for claims. Claims can originate from the authentication method itself, like authentication attributes from External Identity Providers (IDPs). When using an external IDP, the CIAM system serves as an identity broker that serves APIs while maintaining or reusing existing login systems and their user experiences. Your APIs might need a claim (or claim value) that the external IDP provides, like the role(s) of a helpdesk person who signs into your application with an IDP for employee accounts. In this case the CIAM system should allow you to run custom logic to transform the authentication attributes from an IDP token to claims in access tokens.
A CIAM system should have strong support for using security standards to retrieve authentication attributes. You might need to authenticate users with a business partner's IDP and retrieve attributes from a Security Assertion Markup Language (SAML) response. In future, you may need to authenticate users with mobile wallets that provide claims from Verifiable Credentials. The end result is that APIs gain the capability to use external attributes in their authorization.
That is, to ensure accurate API authorization, claims often need to deliver values that APIs cannot otherwise know. In some cases, you may need the CIAM system to send user identities or other claims to external systems that analyze data or usage patterns and return a risk score, to allow or deny access. Therefore, another essential ingredient of the CIAM system is extensibility, to enable future unknown integrations.
CIAM and API Security: A Unified Approach
CIAM and API security go hand in hand. A strong CIAM solution doesn't just manage users — it serves as the core security layer for APIs by issuing secure tokens, enforcing access policies, and handling dynamic claims. CIAM enables a zero-trust security model, enhances data privacy, and supports compliance frameworks like GDPR, Open Banking, and PSD2. The result is an API ecosystem that is resilient, governable, and future-ready.
The token-based architecture of a CIAM solution can use various security design patterns to enable token confidentiality, token exchange and security hardening. You can read about them in the Token Patterns article. However, the most essential building block for modern API security architectures is a setup that enables you to scale the use of scopes and claims. Read more about getting integrated in the Tokens and Claims tutorials for the Curity Identity Server,
Gary Archer
Product Marketing Engineer at Curity
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
