What Is IAM? Identity and Access Management Explained

Every protected system needs to answer two questions: who is requesting access, and what are they allowed to do? Identity and access management (IAM) provides the processes and technology used to answer those questions across many users, applications, and services.

IAM also manages what happens before and after login:

• Creating accounts when someone joins
• Changing access when responsibilities change
• Removing access when someone leaves
• Recording identity-related events

What Is Identity and Access Management (IAM)?

Identity and access management (IAM) is the set of processes and technologies used to manage digital identities and control which resources those identities can access.

In simple terms, IAM answers two questions:

• Can you prove you are the account you claim to be? — authentication checks whether the claimant can prove control of a credential associated with that account
• What are you allowed to do? — authorization controls access after the identity is known

The identity may represent:

• A person, such as an employee or customer
• A non-human workload, such as an application, service, or device

IAM is not just a login page. It also covers:

• Account creation at hire
• Permission updates during role changes
• Access removal at exit
• Audit records
• Shared sign-in across applications

A useful shorthand is the right identity, right access, right resource, right time model:

• Right identity — the correct person or workload is authenticated
• Right access — permissions match what that identity should be allowed to do
• Right resource — the identity receives access only to the applications, systems, or data it needs
• Right time — access matches current role, policy, and session state

Cloud platforms, on-premises directories, and IAM servers such as Keycloak implement parts of this model with different products, but the vocabulary stays the same.

Identity, Account and Digital Identity

In this IAM model, Priya is one identity that may be represented by many accounts across different systems:

• Active Directory for corporate sign-in
• GitHub for source control
• A payroll application for HR data

IAM tries to connect those accounts to the correct identity and keep access aligned with Priya's current role.

Groups, roles, and authentication history are often associated with an account or digital identity, but they describe access policy and activity — not the identity itself.

How IAM Works Across the User Lifecycle

A simple way to understand IAM is to follow an employee from joining to leaving. Security teams often call this the joiner, mover, leaver model.

Joiner — Priya starts on the operations team. HR records the hire. IT then:

• Creates an account
• Assigns baseline groups
• Enrolls MFA
• Grants access to monitoring and deployment tools she needs on day one

Mover — Six months later Priya transfers to the platform team. Her underlying identity is the same, but her access must change:

• Remove access she no longer needs from the operations role
• Add platform groups, roles, and permissions for her new job

If her old operations access is not removed, Priya gradually collects permissions she no longer needs.

Leaver — When Priya resigns, IT should:

• Disable the account
• Revoke active sessions
• Remove group and role assignments

If offboarding is incomplete, Priya may retain access to applications after she leaves the company.

  HR hire event          Role change event         Termination event
        │                        │                         │
        ▼                        ▼                         ▼
   ┌─────────┐             ┌─────────┐              ┌─────────┐
   │ JOINER  │             │ MOVER   │              │ LEAVER  │
   │ create  │             │ change  │              │ disable │
   │ account │             │ access  │              │ account │
   │ assign  │             │ remove  │              │ revoke  │
   │ access  │             │ old     │              │ sessions│
   │ enroll  │             │ access  │              │ remove  │
   │ MFA     │             │ add new │              │ access  │
   └────┬────┘             └────┬────┘              └────┬────┘
        │                       │                        │
        └───────────────────────┴────────────────────────┘
                                │
                    IAM policy + audit trail

Each stage requires different access changes:

• Provisioning — create or update accounts and assignments
• Authentication policy — password rules, MFA requirements, allowed login methods
• Authorization update — roles, groups, and entitlements that define what Priya can reach
• Deprovisioning — remove or suspend access on exit
• Audit — log who changed what and when for later review

An entitlement is a specific access grant on a resource — for example, permission to deploy to a production cluster or read a finance report. Entitlements often come from roles and group membership.

Large organizations split responsibilities:

• HR — hire and termination dates
• Identity governance and administration (IGA) tool — access requests, approvals, and periodic access reviews
• IAM server — sign-in, sessions, and tokens (Keycloak is one example)

The lifecycle stays the same; more tools appear as compliance requirements grow.

Authentication vs Authorization in IAM

Authentication and authorization are often confused because both appear during login. A useful sequence is:

Identification  →  Authentication  →  Authorization
"I am Priya"         "Prove it"          "What may Priya do?"

In this simplified model, the three stages answer different questions:

• Identification — the claim: Priya states a username or selects an account
• Authentication (AuthN) — proof: whether the claimant can prove control of an authenticator associated with the claimed account, such as a password, security key, passkey, or certificate
• Authorization (AuthZ) — permission: whether that identity may perform the requested action

Identity proofing is separate from day-to-day authentication. It establishes a person's real-world identity when the digital identity is first created — for example, verifying employment documents during onboarding.

In a typical authenticated application, authentication happens first and authorization follows. Successful authentication does not automatically grant access to every resource. Priya may authenticate successfully but still lack permission to administer the billing system. For API bearer tokens, HTTP 401 versus 403, and OAuth versus OpenID Connect in this split, see Authentication vs Authorization.

Authentication can use different factors:

• Something you know — password or PIN
• Something you have — a registered phone or authenticator device, hardware security key, or smart card
• Something you are — fingerprint or other biometric

Multi-factor authentication (MFA) combines factors from more than one category. A password followed by another password is not multi-factor authentication.

Applications and APIs still need to enforce authorization decisions, even when IAM supplies roles or claims. Keycloak can authenticate Priya and include role claims in an access token, but each API still decides which operations those roles permit. See Keycloak realm roles vs client roles for how role claims reach tokens.

Provisioning, Federation, SSO and MFA

Provisioning, federation, SSO, and MFA solve different IAM problems.

Provisioning creates, updates, or removes accounts and access:

• Manual admin tasks
• HR-driven workflows
• Automated interfaces such as SCIM

When Priya joins, provisioning creates her account and assigns groups. When she leaves, deprovisioning removes them.

Identity federation establishes trust so authentication or identity information from one identity system can be used by another. For example, an application might trust an external IdP instead of maintaining its own passwords.

Some IAM products also use the term user federation for connecting to an external user directory. In Keycloak, user federation connects a realm to LDAP or Active Directory. That is a directory integration, not the same protocol flow used for an external OIDC or SAML identity provider.

Single sign-on (SSO) lets Priya authenticate once and open multiple connected applications without entering credentials again while the shared session remains valid. SSO is a user experience outcome, not a synonym for IAM itself. Federation and central IAM servers are common ways to deliver it.

Multi-factor authentication (MFA) strengthens sign-in by requiring more than one authentication factor, as described in the authentication section above.

User records in a dedicated Keycloak realm can be created locally or linked from a directory. Create and manage Keycloak users covers local accounts; user federation is a separate integration path.

IAM Components and Common Technologies

Most IAM systems use the same basic building blocks:

Terminology varies between IAM products and standards; NIST uses authenticator more precisely for the mechanism used to prove control during authentication.

An identity provider (IdP) authenticates users and sends trusted identity information to applications using protocols such as OpenID Connect or SAML.

Protocol names differ for the application that trusts the IdP:

• SAML — Service Provider (SP)
• OpenID Connect — Relying Party (RP) or OIDC client

Adjacent systems often sit beside core IAM:

• LDAP directories or Active Directory — common directory systems used to store workforce users and attributes
• IAM servers — sign-in and tokens in front of applications
• PAM systems — privileged administrator access
• Secrets vaults — application secrets and credentials
• Certificate authorities (CAs) — issue certificates used for cryptographic identity and authentication

Workforce IAM, CIAM and Machine Identity

IAM programs differ by who the users are.

Workforce IAM covers employees and contractors on internal applications. Priya's story is workforce IAM:

• HR-driven lifecycle
• Corporate directory
• MFA for admin tools
• Least-privilege role design

Customer IAM (CIAM) covers external product users and usually emphasizes:

• Self-registration and account recovery
• Social or enterprise login
• Consent and profile management
• Authentication at customer scale

Machine identity covers services, CI jobs, and devices:

• Authenticates with client secrets, cryptographic keys, workload identities, or certificates
• Authenticates programmatically without an interactive human sign-in
• Still needs authorization that limits each workload to the resources it requires

One platform team often runs all three patterns in parallel. Keep the models separate in design even when one product touches more than one area.

IAM Benefits and Limitations

IAM can make account and access management easier by:

• Reducing repeated sign-ins through centralized authentication and SSO
• Speeding onboarding when provisioning is automated from HR or group templates
• Improving offboarding when leaver steps disable accounts across systems together
• Applying consistent authentication policies, such as MFA requirements, while password policy is managed by whichever system owns the credentials
• Collecting central identity and administrative audit events, such as sign-ins, failed authentication attempts, and role changes

IAM also has limits:

• Tokens and roles from an IAM server do not replace application-level authorization policy.
• SSO does not remove the need to deprovision every downstream account on exit.
• Federation introduces dependencies on external identity systems; if the upstream provider or trust configuration fails, users may be unable to sign in.
• Access certifications and segregation-of-duties reporting need IGA tooling beyond a basic IAM server.

How Keycloak Fits into IAM

Keycloak is an open-source IAM server that provides login, SSO, user federation, identity brokering, and support for protocols such as OpenID Connect and SAML. It maps to several component rows:

• Identity provider for applications that send users to Keycloak for login
• Local users and directory federation — Keycloak can manage users inside a realm or connect to LDAP and Active Directory
• SSO and protocol support — manages sessions and issues OIDC/OAuth tokens or SAML assertions
• Role and group source — roles and other claims can be included in tokens and used in authorization decisions

Keycloak covers Priya's sign-in experience:

• Login page and MFA
• SSO session
• Tokens containing information about the signed-in user and their assigned access

Keycloak does not replace:

• HR as the hire and termination source of truth
• A full IGA platform for access certification or segregation-of-duties analytics (unless you add separate tooling)

Keycloak usually works alongside other systems:

For a product-level view of realms, clients, sessions, and brokering, read What is Keycloak?. When you are ready to run a lab, Install Keycloak with Podman walks through a local container you can use to see IAM concepts in a live realm.

Summary

IAM manages digital identities and controls access to applications, data, and services. It covers the full access lifecycle: creating accounts, authenticating identities, granting appropriate permissions, changing access as responsibilities change, and removing access when it is no longer needed.

Authentication answers "Can you prove you are the account you claim to be?" while authorization answers "What are you allowed to do?" SSO, MFA, provisioning, federation, and governance solve different parts of that broader IAM problem. Keycloak provides several of these capabilities, particularly login, SSO, federation, identity brokering, and token or assertion issuance.

References

• NIST SP 800-63 Digital Identity Guidelines — authentication assurance levels and identity proofing vocabulary
• NIST Computer Security Resource Center — Access Control — authorization and access control definitions
• Keycloak documentation — upstream IAM server referenced in this course