What is an IAM?

Two senses of the word

"IAM" gets used in two overlapping ways. Workforce IAM is what Okta, Microsoft Entra ID, Google Workspace, JumpCloud, and Ping do — the identity provider that manages your employees, their SSO across SaaS apps, their MFA, and their lifecycle (onboarding, role changes, offboarding). Cloud-resource IAM is what AWS IAM, GCP IAM, and Azure RBAC do — the system inside a cloud provider that decides which users, services, and roles can perform which API actions on which resources. They are different systems serving different audiences, but they intersect — your workforce IAM is often what federates into your cloud IAM via SAML SSO.

The four classic capabilities

Identification — knowing who is making a request, usually via a username, email, or service-account ID. Authentication — verifying that the entity is who it claims to be, via a password, passkey, hardware key, or service-to-service credential. Authorization — deciding whether the now-authenticated entity is allowed to do the thing it is trying to do. Auditing — keeping a record of who did what, when, from where, so that a breach can be investigated and a compliance auditor can answer the question. A real IAM system has all four; products that claim "IAM" while only doing authentication are common and worth questioning.

RBAC, ABAC, and policy as code

The authorization sub-problem has its own ecosystem. Role-Based Access Control (RBAC) assigns permissions to named roles (Admin, Editor, Viewer) and assigns users to roles. It scales reasonably well up to mid-size organizations and is the default in most products. Attribute-Based Access Control (ABAC) evaluates each request against rules about the user, the resource, and the context (time, location, device posture). ABAC handles nuance — "only on a corporate device, only between 8am and 7pm, only for resources in their region" — that RBAC cannot. Policy-as-code engines like Open Policy Agent (OPA) and Cedar (the policy language behind AWS) let teams write authorization rules in declarative languages and run them consistently across services.

Where IAM disasters come from

Permission drift is the dominant failure mode. People change roles and old permissions stay. Contractors arrive, are granted temporary access, and the access outlives the contract by years. A service account gets sudo-equivalent permissions during a deploy that nobody remembers to remove. Attackers do not need a zero-day if they can compromise one credential whose permissions have been quietly compounding since 2019. The fix is process: quarterly access reviews, automatic revocation on role change, time-bounded grants for temporary access, and continuous monitoring for unused permissions.

At QUANT LAB

Every cloud infrastructure build we ship starts with a deliberate IAM design — workforce identity federated from the client's existing provider (Okta, Google, Entra), per-service IAM roles for every workload, and an automated review of unused permissions. Our Active Directory pen tests consistently find that the IAM disasters are not at the cloud layer — they are in the legacy directory the cloud federates against.

For SaaS products, our SaaS platform builds include a typed authorization layer from day one — Postgres row-level security plus a policy engine — so the question "is this user allowed to see this resource" has one consistent answer across every endpoint. Read our piece on multi-tenant SaaS with Postgres RLS for the data-layer pattern, or book a call if your IAM has been accreting since the early days.