What is an Identity Management System?

An Identity Management System is a security framework that provides authorized access to technology resources by authenticating users and applications using a token-based approach. Alternative names with the same meaning include Identity and Access Management (IAM) System and CIAM System.

This article provides a brief overview of the main functions of an Identity Management System.

Identity Management Components

By following the principle of Separation of Concerns, each component (or subsystem) handles a singular logical function. Together the components implement the full scope of the Identity Management System.

An Identity Management System should consist of logical components for the following services:

• An Authentication Service

  Responsible for authenticating users, providing user self-service for password resets, sign-ups etc.

• A Federation Service

  Responsible for cross-domain Single Sign-on for web applications.

• A Machine Authentication Service

  Responsible for authenticating applications and workloads.

• A Token Service

  Responsible for security token issuance and introspection. Primarily for API access and for modern web and mobile application access.

• A User Management Service

  Responsible for user provisioning operations.

The Authentication Service

An Authentication Service should be built as a hub (or multiplexer) for serving different identity sources. An identity source is the entity that provides the attributes that describe an authenticated user. In other words, identity sources answer the question of who the user is by describing that user according to its premises.

Identity sources are also known as Authenticators. Authenticators implement authentication processes and aggregate the necessary data about the user. When new authenticators are added to the system, they can be added without requiring any updates to dependent systems, such as the websites or applications utilizing these identities.

While authentication methods follow standards, authentication processes do not. Authentication processes adapt to organizations needs and differ from case to case. The Authentication Service helps separate those non-standard integrations from the standard protocol functions like federation and token issuance. It serves as the broker between all different authentication methods and the applications requiring a user to be authenticated according to some policy.

Applications rarely communicate directly with the Authentication Service, but use either the Token Service or the Federation Service via standard protocols to request or trigger authentication. These in turn communicate with the Authentication Service when needed.

The Token Service

A Token Service, sometimes referred to as Security Token Service (STS), issues and verifies tokens. A Token Service uses different protocols to communicate tokens to clients; some of them are standardized and some are not. The most common, standard protocol in this context is OAuth.

In OAuth, the Token Service is called the Authorization Server (AS). An AS issues two kinds of tokens: Access Tokens (ATs) and Refresh Tokens (RTs). It passes those tokens to clients “by value” or “by reference”. See OAuth Token Types. The most common types for by-value tokens are JSON Web Tokens (JWTs). By-reference tokens are only meaningful for the authorization server and thus are non-standard types of tokens.

OAuth facilitates delegated authorization to enable the correct access controls. Delegated authorization builds on a four-party trust model. The four parties are:

• The Token Service or Authorization Server
• The client application (OAuth client, actor)
• The user or Resource Owner (RO, subject)
• The API or Resource Server (protected resource)

The Token Service authorizes a particular client application to act on behalf of an end user. The tokens that the authorization server asserts represent the authorized delegated access. The client application presents its token to the fourth party, the Resource Server (RS) or API. The API verifies the authenticity of the token through its trust in the authorization server and then determines if the delegated authorization meets its own security policy.

The Token Service validates any delegation request from a client application for a user against its policies. As part of that, it integrates with the Authentication Service to authenticate the end user. Similarly, it integrates with the Machine Authentication Service to authenticate the client application.

The Machine Authentication Service

To be able to securely authorize client applications and other software in an IT architecture to access protected resources in or outside delegation scenarios, the Identity Management System needs to be able to authenticate such software. There are many ways for software to authenticate. The Machine Authentication Service consolidates the methods in one service.

The Machine Authentication Service supports various credential types for software like shared secrets (client ID and secret), certificates (mutual TLS) or JWT-based credentials (Kubernetes service accounts, SPIFFE SVID, attestation JWTs, self-signed JWTs). Depending on the credential, it federates to the Machine Identity Management System to authenticate software such as a workload. After authentication, it can describe the software with attributes and link it to a known identity like an OAuth client.

The Federation Service

The Federation Service brokers trust across organizational boundaries using security tokens. It is similar to the Token Service in that it also issues tokens. However, the purpose of those tokens differs from access tokens. The Federation Service issues identity assertions that represent an identity and allow for cross-domain identity propagation. Typical protocols that a Federation Service supports include SAML and OpenID Connect with its ID token.

Because of the similarities, the Token Service typically also acts as a Federation Service. In the case of OpenID Connect, for example, the OAuth authorization server and the OpenID connect provider are the same entity and Token Service. In the role of a Federation Service, the Token Service issues ID tokens to applications in a different organizational domain than itself (like a partner's Authentication Service or Token Service that trusts the Federation Service).

The User Management Service

A User Management Service is an abstraction of one or more identity repositories. It provides user management capabilities, such as the ability to create, retrieve, update, and delete (CRUD) user data. Its primary consumers are outside of the Identity Management System. For example, a Policy Decision Point (part of the Entitlement Management System) may use the User Management Service to retrieve data about a user for its fine-grained policies. Another example is onboarding, where an administrator may need to find and furnish a user with a license or permission to access a cloud service that they have not accessed yet.

For this abstraction to be interoperable, the CRUD interface that the User Management Service exposes must be standards-based. The best, most adopted choice is System for Cross-domain Identity Management (SCIM). This lightweight RESTful protocol exposes a resource-oriented API to perform CRUD operations on users and groups. The API also supports bulk updates and precision updates to just certain attributes (an operation known as patching). SCIM also defines a normative set of user attributes and group attributes, necessary for widespread interoperability.

Conclusion

Managing identity is an involved process. By separating the different aspects of identity into discrete logical components it becomes easier to map requirements onto functions. The Identity Management System has complete coverage architecturally of the use cases that arise when building large scale mobile, web and API driven applications like AI agents.

Last updated: 2026-09-30

Jacob Ideskog

Identity Specialist and CTO at Curity