Identity and Access Management (IAM)

Definition: The framework of policies, processes, and technologies that ensure the right identities, human or machine, have exactly the access they need to systems and data, and no more.

How It Works

IAM splits into two distinct questions that are often conflated but solved by different mechanisms:

Authentication (AuthN): “Who are you?” Verifying an identity via something you know (password), something you have (a hardware key, an authenticator app), or something you are (biometrics). Multi-Factor Authentication (MFA) combines two or more of these categories so a single stolen factor isn’t enough. Federated protocols like SAML and OAuth2/OIDC let one identity provider authenticate a user once and vouch for them across multiple applications, instead of every app maintaining its own password database.
Authorization (AuthZ): “What are you allowed to do?” Decided after authentication succeeds, using a policy model:
- RBAC (Role-Based Access Control): permissions are attached to roles, and users are assigned roles. Simple to reason about and audit, but roles multiply quickly in large organizations (“role explosion”) as edge cases accumulate.
- ABAC (Attribute-Based Access Control): access decisions evaluate attributes of the user, resource, and environment at request time (department, data classification, time of day, device posture), enabling fine-grained, context-aware policy without a role for every combination.
- PBAC/ReBAC: policy-based and relationship-based models generalize further, evaluating arbitrary logic or graph relationships (e.g. “can edit if owner of the parent folder”).
Principle of Least Privilege (PoLP): every identity, human or service, gets the minimum permissions required for its task, nothing granted “just in case.”

Under the Hood

Password authentication never stores the password itself; it stores a salted, slow hash (Argon2id, bcrypt) and compares hashes at login time, so a database breach doesn’t directly expose usable credentials.
SAML exchanges signed XML assertions between an Identity Provider (IdP) and a Service Provider (SP): after a user authenticates at the IdP, it POSTs a signed assertion to the SP asserting the user’s identity and attributes, which the SP validates against the IdP’s known signing certificate before establishing a session.
OAuth2 is an authorization delegation protocol, not authentication by itself: a client obtains a scoped access token from an authorization server, which it presents to a resource server that trusts that authorization server. OpenID Connect (OIDC) layers an identity token (a signed JWT) on top of OAuth2 specifically to add authentication.
JWTs (JSON Web Tokens) used as access or ID tokens are self-contained, signed claims: a resource server can verify a token’s signature and expiry without a network round-trip to the issuer, at the cost of being unable to instantly revoke a token before it naturally expires.
Policy evaluation in cloud IAM (AWS, Azure, GCP) is typically deny-by-default: an identity has no permissions until an explicit allow policy is attached, and an explicit deny anywhere in the evaluated policies overrides any allow, a detail that trips up engineers debugging “why can’t this role do X” issues.

OAuth2 Authorization Code Flow with PKCE, Step by Step

This is the standard flow for a client application obtaining access on a user’s behalf, and the recommended flow for both public clients (mobile, SPA) and confidential clients today:

The client generates a random code_verifier and derives a code_challenge from it (a SHA-256 hash, base64url-encoded), then redirects the user’s browser to the authorization server’s /authorize endpoint with client_id, redirect_uri, scope, state, and code_challenge.
The user authenticates at the authorization server (if not already) and approves the requested scopes.
The authorization server redirects the browser back to the client’s redirect_uri with a short-lived authorization_code and the original state value, which the client checks matches to prevent CSRF.
The client’s backend calls the authorization server’s /token endpoint directly (not via the browser), sending the authorization_code plus the original code_verifier.
The authorization server re-derives the challenge from the received code_verifier and checks it against the code_challenge from step 1. A match proves the token request came from the same client that started the flow, not an attacker who intercepted the authorization code in transit.
The authorization server issues an access_token (and, for OIDC, an id_token), which the client then presents as a Bearer token in the Authorization header on API calls to the resource server.

PKCE specifically closes the gap where a malicious app on the same device could intercept the redirect containing the authorization code and exchange it itself; without a matching code_verifier, the intercepted code is useless.

Authentication and Authorization Flow

Once a token exists, every downstream request repeats the same two-step check, verify who’s asking, then verify what they’re allowed to do, rather than trusting a single login event indefinitely:

Token validation (is this signature real, is it expired) and authorization (is this identity allowed to do this specific thing) are separate checks performed in sequence; a perfectly valid, unexpired token still gets a 403 if the attached identity lacks the required permission.

RBAC vs. ABAC Decision Logic

The two models answer the same question, “can this request proceed,” with structurally different logic:

Why It Matters

IAM is the central control point for cloud and enterprise security; a misconfigured IAM policy is one of the most common root causes of cloud data breaches, more often than a novel exploit.
Federation and SSO reduce password sprawl, which reduces credential reuse and phishing surface, since users manage one strong credential instead of dozens of weak ones.
Fine-grained, least-privilege authorization limits blast radius: a compromised identity with narrow permissions can only do narrow damage.

Common Pitfalls

Granting broad wildcard permissions (s3:*, *:*, or an “admin” role) to application service accounts because it’s faster than scoping permissions precisely
Letting IAM roles and group memberships accumulate indefinitely without periodic access reviews, so former employees or decommissioned services retain live credentials
Treating MFA as optional for service accounts or automation, when compromised long-lived API keys without MFA are a common breach vector
Confusing authentication with authorization: successfully logging in is not the same as being permitted to perform a specific action
Hardcoding long-lived credentials in code or CI pipelines instead of using short-lived, automatically rotated tokens

Comparison

	RBAC	ABAC	Federated SSO (SAML/OIDC)
Access decided by	Assigned role	Evaluated attributes at request time	Identity provider assertion
Granularity	Coarse, role-based	Fine-grained, contextual	N/A, handles authentication not authorization
Complexity to manage	Simple at small scale, role explosion at large scale	More complex policy logic, but scales better	Centralizes login, offloads per-app password management
Best fit	Stable, well-defined job functions	Dynamic, context-sensitive access needs	Any org with multiple apps needing one identity
Audit difficulty	Easy, roles are enumerable	Harder, decisions depend on runtime context	N/A, delegates authentication, not authorization
Failure mode when misconfigured	Role granted too broadly	Policy logic gap or contradictory rules	Over-trusting a compromised identity provider

Example

An AWS IAM role attached to a Lambda function scoped to s3:GetObject on arn:aws:s3:::my-bucket/data/* only, so even if the function’s code is compromised, the attacker can read objects under that one prefix and nothing else in the account. A company using Okta as an IdP lets employees log into Slack, Salesforce, and internal tools with one set of credentials via SAML, while each app enforces its own authorization rules for what that authenticated user can do.

Real-World Case Study

The 2019 Capital One breach traced back to an IAM role attached to a misconfigured web application firewall (WAF) that was granted far more S3 access than the WAF itself needed to function. An attacker exploited a server-side request forgery (SSRF) flaw in the WAF to make it query the cloud instance metadata service, which returned temporary credentials for that over-privileged IAM role. Those credentials were then usable directly against S3, letting the attacker list and read data from buckets well outside anything the WAF should ever have needed to touch. The breach exposed over 100 million customer records and is one of the most cited examples of why least-privilege scoping on service roles matters as much as, or more than, perimeter defenses like a WAF: the WAF itself became the attack’s pivot point precisely because its IAM role wasn’t scoped down.

Standards and Protocols

LDAP: a protocol for querying and maintaining hierarchical directory information, the backbone of on-premises identity stores like Active Directory, often paired with Kerberos, a ticket-based authentication protocol where a trusted ticket-granting service issues time-limited tickets instead of repeatedly transmitting credentials.
SAML 2.0: XML-based federation standard, still common in large enterprise SSO deployments, particularly for legacy applications.
OAuth 2.0: authorization delegation framework, the basis for “log in with” and third-party API access flows.
OpenID Connect (OIDC): identity layer on top of OAuth 2.0, the modern standard for web and mobile SSO.
SCIM: a standard for automating user provisioning and deprovisioning across systems, so an offboarded employee’s access is revoked consistently everywhere, not just in one system.

History

1990s–2000s: enterprise IAM began as directory services (LDAP, Microsoft Active Directory), centralizing authentication for on-premises networks.
2001: SAML 1.0 was published, enabling federated single sign-on across organizational boundaries for the first time at scale.
2005–2010: OAuth emerged from the need to let third-party apps access a user’s data (photos, contacts) without handing over the actual password, formalized as OAuth 1.0 in 2010.
2012: OAuth 2.0 was published, trading some of OAuth 1.0’s cryptographic complexity for simplicity, relying on TLS for transport security instead.
2014: OpenID Connect layered a standardized identity token on top of OAuth 2.0, closing the gap that OAuth alone (an authorization protocol) never fully addressed for authentication.
2010s–present: the shift to cloud infrastructure moved IAM from a network-perimeter concern to the primary control plane, since cloud resources have no meaningful network perimeter of their own.

FAQ

Is OAuth2 an authentication protocol? No, on its own it’s authorization delegation, granting a client scoped access to a resource. OpenID Connect adds the identity layer on top that makes authentication possible.

Why does least privilege matter if an identity is already authenticated? Authentication only proves who’s asking. Without least-privilege authorization, a legitimate but compromised identity, a phished employee or a leaked API key, can access far more than its actual job requires.

What’s the practical difference between RBAC and ABAC in a real system? RBAC answers “does this role include this permission,” a static lookup. ABAC answers “given this user’s department, this resource’s classification, and the current time, is this allowed,” a dynamic policy evaluation, more flexible but harder to audit at a glance.

Can a JWT be revoked before it expires? Not inherently, since it’s self-contained and verified by signature alone. Systems that need early revocation maintain a separate denylist or keep token lifetimes short and rely on refresh tokens instead.

Referenced by

Dig deeper

Spot an error in this note?