Identity and Access Management (IAM): What It Is

Identity and Access Management (IAM): What It Is. What is identity and access management (IAM)? Its four functions, the standards behind them (OIDC, SAML, SCIM, LDAP), machine identities and a checklist.

Identity and access management (IAM) is the set of policies, processes and software that creates and maintains digital identities, verifies who a user or service is, and decides what it may do. It covers four functions: identity administration, authentication, authorization and audit, so each identity gets the access it needs and loses that access when it no longer should. The NIST glossary entry for identity and access management describes the same scope as the administration of individual identities and of the roles and access privileges attached to them.

If you have inherited a login system, or you have been asked to choose one, you probably already know what a login page and single sign-on (SSO) are. This guide explains IAM as a whole discipline: the four functions, the open standards that implement each one, how the lifecycle of a person’s access should work, how machine identities fit in, and how IAM relates to the neighbouring terms IGA, PAM and CIAM. We stay vendor-neutral until the final platform section, which shows how the same ideas look in Keycloak.

Key takeaways

• IAM combines identity administration, authentication, authorization and audit, as the NIST IAM glossary and Microsoft’s identity concepts guide describe.
• Each function has open standards behind it: OpenID Connect and SAML for authentication, OAuth 2.0 scopes and roles for authorization, SCIM and LDAP for administration.
• Directory federation reads identities from an existing directory, while SCIM provisioning pushes account changes into a receiving system; most organizations need to know which one they rely on.
• Services, scripts and workloads are identities too, and they need the same lifecycle and audit as people.
• A useful test of any IAM setup follows one person through joining, moving and leaving, and checks every connected application at each step.

What is identity and access management?

IAM answers two questions every time something asks for a resource: who is this, and what are they allowed to do. A digital identity is the system’s record of that someone or something. NIST’s Digital Identity Guidelines, SP 800-63-4, call the record for a person a subscriber account: at enrollment, the credential service provider (CSP) establishes one “to uniquely identify each subscriber and record information about the subscriber and any authenticators bound to that subscriber account.” The authenticators section of the same guidelines says “An authenticator is a means of demonstrating the control or possession of one or more factors in an authentication protocol”, and lists the factor types, such as something you know (for example, a password) and something you have (for example, a device containing a cryptographic key).

The “management” part matters as much as the login. NIST’s subscriber account guidance, SP 800-63A-4, sets requirements for maintaining subscriber accounts and says when a credential service provider must suspend or terminate one, so IAM is something you operate every day rather than something you configure once. A person who joined two years ago, changed teams twice and still holds permissions from the first team is the typical failure IAM exists to prevent.

IAM has also become central to how organizations think about network security. The abstract of NIST SP 800-207 on zero trust architecture says zero trust “assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location”, and that “authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.” In practice that means your IAM system, not your office network, decides who gets in.

Identity management vs access management vs IAM

People use these three terms loosely, and the official definitions overlap. Microsoft’s IAM concepts guide treats identity management, authentication and authorization as responsibilities within IAM, and the NIST IAM glossary includes both identity administration and the management of access privileges. In this guide we use them as follows, with a test employee named Alex who joins engineering, later moves to support and eventually leaves.

The split is useful when you investigate a problem. For a missing account, start with provisioning and directory lookup. For a signed-in user who cannot open a page, start with authorization, which is a different system and often a different team. Our guide to authentication vs authorization goes deeper on that boundary, including why one should answer 401 and the other 403.

The four functions of IAM and how they work

Most IAM systems, whatever they are called, do the same four jobs. The animation below follows one request from Alex through all four.

Alex’s account already exists because the joiner process created it (1); Alex signs in and the identity provider checks the password and second factor (2); the application allows reading a support ticket and denies editing billing (3); and the login and both decisions are written to an event log (4).

Identity administration

Administration creates, updates and retires identities and the groups and roles attached to them. It includes the source of truth for each attribute (often an HR system or an employee directory), the rules that turn a department into group memberships, and the provisioning that creates accounts in the applications people use. Our user provisioning explainer covers the ways accounts get into applications, from manual creation to automated provisioning.

Authentication

Authentication establishes that the person or service at the door is the identity they claim to be. That covers passwords, one-time codes, passkeys and other authenticators, and the policy that says which of them a given application requires. A central identity provider, or IdP, usually does this job for many applications at once, which is what makes SSO possible. Our introduction to identity providers explains how an IdP and the applications that trust it divide the work.

Authorization

Authorization decides what an authenticated identity may do. The common models are role-based access control (RBAC), where permissions follow from roles such as support-agent, and attribute-based rules, where a decision also looks at attributes such as department or region. The IdP often puts roles or scopes into the token it issues, but the application or API still has to enforce them on every request, because the token only carries the claims and cannot block anything by itself.

Audit

Audit records what happened: logins, failed attempts, administrative changes and, ideally, the access decisions that matter. It is how you answer a reviewer who asks who had access to a system last quarter, and how you notice an account being misused. Audit also closes the loop on administration, because periodic access reviews read these records to find permissions that should have been removed.

The standards behind IAM, and when to use each

If you are choosing or inheriting a system, it helps that the interfaces between IAM components are mostly open standards. Knowing which standard does which job tells you what to ask a vendor and what to test.

OpenID Connect describes itself in the abstract of its core specification as “a simple identity layer on top of the OAuth 2.0 protocol”, which is why the two often appear together: OAuth 2.0 handles what a client may access, and OIDC adds a standard way to say who the user is. Our comparison of SAML vs OIDC explains how to choose between them per application, and the short version is that you use OIDC wherever the application supports it and SAML where it does not.

SCIM and LDAP both move identity data, but in opposite directions, and confusing them is a common cause of offboarding gaps. The abstract of the SCIM protocol specification, RFC 7644, calls SCIM “an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service”: a source system calls a receiving system’s SCIM endpoint to create, update or deactivate an account, and the singular attributes of the SCIM core schema, RFC 7643 section 4.1.1, define active as “A Boolean value indicating the User’s administrative status.” Directory federation over LDAP works the other way round, because the IAM system reads identities from the directory when it needs them. Our SCIM protocol guide covers SCIM in more depth.

The joiner, mover and leaver lifecycle

Joiner, mover and leaver are the three events your identity process must handle, and they make a good acceptance test for any IAM system. Write down an expected result for each application, then run Alex through the events. The account creation, maintenance and termination responsibilities behind this test are described in NIST’s account lifecycle requirements, and our joiner, mover and leaver process guide explains how to organize the flow across your applications.

• A joiner needs an account and appropriate starting access. Decide which source establishes the person’s identity, which attributes you need and how they register their first credentials.
• A mover needs revised attributes and access. When Alex moves to support, remove the access tied to engineering and add the support permissions the new job needs. Check for old permissions explicitly, because a new assignment says nothing about whether the old access was removed.
• A leaver needs access removed across connected systems. Disable the account, end active sessions and retire any separate application accounts. Decide when to delete the identity according to your retention policy and the records that still reference it.

For this exercise, also write down which system owns each change. Your employee directory might own department membership, while an application owns permissions on its own records. Without that ownership map you cannot tell which system should correct an inconsistent account, and mover problems in particular tend to sit in the gaps between owners.

Pay special attention to what “disabled” means after the leaver step. Many APIs validate signed access tokens locally, without asking the IdP, so a token issued before Alex was disabled can keep working until it expires. Test a new login, an existing session and a previously issued token separately, and decide whether short token lifetimes are enough for you or whether some APIs should check token status with the IdP.

Machine and service identities

People are not the only identities in an IAM system. Backend services, scheduled jobs, CI pipelines and workloads running in Kubernetes all call APIs, and each of those callers needs an identity, credentials and permissions of its own. Machines usually authenticate with the OAuth 2.0 client credentials grant, where, in the words of RFC 6749 section 4.4, “The client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server.”

Machine identities fail in different ways from human ones. Nobody leaves the company, so nobody triggers a leaver process, and a secret created for a project three years ago can still work long after the project ended. Treat each machine identity like a person in the lifecycle test: give it an owner, the narrowest scopes it needs, a credential you can rotate, and a log of what it does. Where your platform supports it, prefer credentials the workload already has, such as a platform-issued service account token, over long-lived shared secrets copied into configuration. Our guide to Keycloak machine-to-machine authentication walks through the client credentials grant in practice.

IAM vs IGA vs PAM vs CIAM

Several neighbouring terms describe parts of IAM, or IAM applied to a particular audience. They are easiest to compare side by side.

Workforce IAM and CIAM differ mainly in who owns the identity. For employees, your company creates the account and HR drives the lifecycle. For customers, the user creates the account themselves, may sign in with a social or business identity provider, and expects the sign-in page to look like your product. Many organizations run both, sometimes on the same platform with separate configurations, and the four functions apply to each.

How to evaluate an IAM system

Whether you buy a SaaS identity service, run open source yourself or choose a managed option in between, the same questions separate a system that fits from one you will fight. Our guide to identity as a service (IDaaS) explains the hosted end of that range.

• Standards coverage. Check that it supports OIDC and SAML as an identity provider, OAuth 2.0 for APIs, and SCIM in the direction you need (receiving accounts, sending them, or both).
• Directory integration. If you have LDAP or Active Directory, check whether it can federate users from it, whether it can write changes back, and how it learns that a directory account was disabled.
• Authorization model. Look for roles and groups that map cleanly onto your applications, and for a way to put the claims your APIs check into tokens.
• Authentication options. Confirm the second factors and passwordless methods you need, and whether you can require stronger authentication for sensitive applications.
• Machine identities. Look for a client credentials flow, scoped service accounts and credential rotation that does not need downtime.
• Audit and export. Confirm which user and admin events it records, how long they are kept, and whether you can forward them to your own log or SIEM system.
• Lifecycle behaviour. Run the joiner, mover and leaver test against a trial instance, including token lifetimes and session termination for a disabled user.
• Exit path. Ask how you would export users, configuration and, where possible, password hashes if you later move to another system.

Implementing IAM with Keycloak and managed Keycloak

Keycloak is an open-source identity and access management server that the Cloud Native Computing Foundation accepted on April 10, 2023, at the Incubating maturity level, according to the CNCF’s Keycloak project page. It maps directly onto the four functions above, which makes it a useful reference even if you end up choosing something else. The links below go to the Keycloak Server Administration Guide; check the documentation for your deployed version, because sections change between releases.

How Keycloak maps to the four functions

• Administration. The guide’s core concepts and terms say “A realm manages a set of users, credentials, roles, and groups” and “Realms are isolated from one another and can only manage and authenticate the users that they control”, and the user profile defines which attributes each user carries. A user who joins a group receives that group’s attributes and role mappings, so moving Alex between groups changes access in one place.
• Authentication. Keycloak acts as an OIDC and SAML identity provider for the applications registered in a realm, which it calls clients. It can also broker logins to external identity providers, such as a customer’s corporate IdP.
• Authorization. Realm roles and client roles give you RBAC, and the roles a user holds can be mapped into the tokens your APIs validate.
• Audit. Keycloak can save user events, such as logins and failed passwords, and admin events for actions taken through the Admin Console. The user events section notes “By default, Keycloak does not store or display events in the Admin Console”, so follow its procedure, which turns on Save events on the User events settings tab under Realm settings > Events, before you rely on them.

Directory federation and SCIM in Keycloak

Keycloak’s LDAP and Active Directory provider lets a realm read users from a directory and map their attributes into its user model. Its Edit Mode setting controls what happens to changes. The guide says that in READ_ONLY mode “You cannot change the username, email, first name, last name, and other mapped attributes” and “Password updates are not supported”; in WRITABLE mode you can change them “and synchronize them automatically with the LDAP store”; and in UNSYNCED mode “Keycloak stores changes to the username, email, first name, last name, and passwords in Keycloak local storage, so the administrator must synchronize this data back to LDAP.” For Active Directory offboarding, the MSAD User Account Mapper uses the userAccountControl and pwdLastSet attributes to carry the Active Directory account state into Keycloak. The guide says “if the value of pwdLastSet is 0, the Keycloak user must update their password” and “If the value of userAccountControl is 514 (disabled account), the Keycloak user is disabled”, so test a disabled directory user against your actual login flow before you rely on it. Our Keycloak LDAP integration guide walks through the setup.

For the other direction, Keycloak includes a native SCIM API for managing users and groups within a realm, which the guide says external systems such as identity governance platforms, HR systems or other identity providers can use to provision and manage users. The Keycloak 26.8.0 release notes list it as “SCIM API (supported)”, and the guide’s section on enabling SCIM for a realm says “Once the feature is enabled on the server, you must also enable SCIM for each realm individually”, which in the Admin Console is the SCIM API toggle on the General tab of Realm settings. In this setup Keycloak is the receiving SCIM server, so creating Alex in the realm does not by itself create an account in a downstream application.

Service accounts for machine identities

The guide’s core concepts and terms say “Each client has a built-in service account which allows it to obtain an access token”, and its section on using a service account shows how to set one up. You give that service account roles the same way you give them to a user, which keeps machine permissions visible next to human ones. For workloads in Kubernetes, the guide’s section on Kubernetes identity providers says “A Kubernetes identity provider supports authenticating clients with Kubernetes service account tokens.”

Run the lifecycle test in a test realm

You can run Alex’s lifecycle against a test realm with the Keycloak Admin CLI, which calls the documented Admin REST API user operations. The commands below assume an Admin CLI session that is already authenticated as an administrator of a realm named lifecycle-demo, with engineering and support groups whose identifiers you have copied from the Admin Console.

# Joiner: create Alex and capture the new user's identifier
USER_ID=$(kcadm.sh create users -r lifecycle-demo \
  -s username=alex -s email=alex@example.com \
  -s enabled=true -i)

ENGINEERING_GROUP_ID='replace-with-engineering-group-id'
SUPPORT_GROUP_ID='replace-with-support-group-id'

# Mover: leave engineering, join support
kcadm.sh delete "users/$USER_ID/groups/$ENGINEERING_GROUP_ID" \
  -r lifecycle-demo
kcadm.sh update "users/$USER_ID/groups/$SUPPORT_GROUP_ID" \
  -r lifecycle-demo -s realm=lifecycle-demo \
  -s userId="$USER_ID" -s groupId="$SUPPORT_GROUP_ID" -n

# Leaver: disable the account and end its sessions
kcadm.sh update "users/$USER_ID" -r lifecycle-demo -s enabled=false
kcadm.sh create "users/$USER_ID/logout" -r lifecycle-demo \
  -s realm=lifecycle-demo -s user="$USER_ID"

The create command follows the guide’s user creation example, the group calls follow adding a user to a group, and the logout call follows logging out a user from all sessions, which ends the user’s sessions and notifies clients that have an admin URL. Set a temporary password for Alex in the Admin Console before the first login, and after each step sign in to a test application and record which actions succeed and which are denied. After the leaver step, check whether your API still accepts a token issued before the account was disabled, and compare that with the realm’s Access Token Lifespan.

Managed Keycloak on Skycloak

If you want IAM on open source without running Keycloak clusters yourself, our managed Keycloak page describes Skycloak’s offer as the open-source Keycloak identity platform hosted and operated for you. Our pricing page lists unlimited users, full Keycloak admin access, all Keycloak features including SSO, MFA and SAML, and full API access with a Terraform provider on every plan, with user events and analytics from the Launch plan up. The feature pages describe user management, role-based access control, SCIM provisioning, identity providers and audit logs in more detail, and the user management documentation shows how to create users, assign roles, organize groups and watch active sessions from our dashboard.

Frequently asked questions

Is IAM the same as single sign-on?

IAM is broader than SSO. SSO is one capability of the authentication function: it lets a user sign in once at a shared identity provider and reach several applications. IAM also covers creating and retiring the accounts behind that login, deciding what each user may do, and recording what happened. You can have SSO and still leave former employees with accounts in applications that SSO never provisioned.

Does SSO replace provisioning?

SSO does not replace provisioning. It centralizes the login, while provisioning manages the account record in each target system. You still need to decide how each application creates and retires its records, and the SCIM protocol specification defines a standard set of operations for doing that.

What are the four pillars of IAM?

The four functions are identity administration, authentication, authorization and audit. Administration keeps the identity records and their access current, authentication verifies who is signing in, authorization decides what they may do, and audit records it all so you can review and prove it later.

Is IAM only for employees?

IAM is not only for employees. Workforce IAM serves employees and contractors, customer IAM (CIAM) serves the users of your product, and both need the same four functions. Machine identities such as services and pipelines also belong in IAM, and they are often the accounts with the least oversight.

Where to start

Start by listing your identities (employees, customers and services), the systems that own them and the applications that trust them. Then map each of the four functions to the component that performs it today, note which standards connect them, and run the joiner, mover and leaver test against one application before you widen it to the rest.

If you would like to run that test on real Keycloak without operating it, you can start with managed Keycloak hosting on Skycloak.