IAM 101: Authentication, Authorization, and Why They're Not the Same Thing

Identity & Access · 7 min read

Why this matters?

Identity is the most boring, invisible, load-bearing part of modern software. It's the plumbing behind every SaaS login, every corporate VPN, every hospital dashboard, every AWS console. When it works, nobody notices. When it breaks, everything breaks --- payroll stops, patient records lock, deploys fail, and someone gets paged at 3 a.m.

This is Part 1 of a two-part series. Here we cover the framework: what IAM actually is, how identity and access are two genuinely different problems, and the security and authorization layers that sit on top. Part 2 covers the protocols — SAML, OAuth, OIDC, and SCIM — the plumbing that ties it all together.

IAM - "The bouncer at the door"

Identity & Access Management is a framework that answers two questions: who are you, and what are you allowed to do. That's it. Everything else in this blog is a specific answer to one of those two questions.

MENTAL MODEL

Think of IAM as a bouncer with a clipboard. First they check your ID (identity — authentication). Then they check the list (access — authorization) to see which rooms you're allowed into. Identity is who. Access is what.

The two halves of IAM

These are genuinely different problems and they're often handled by different systems:

  • Identity --- handles login, provisioning, and verifies you are who you claim to be. Uses passwords, OTPs, biometrics, MFA. Systems: Okta, Azure AD, Google Workspace, Auth0.

  • Access Management --- decides what you can touch once you're in. Uses roles, policies, permissions. Systems: AWS IAM, internal RBAC engines, policy tools like OPA.

The two halves of IAM
The two halves of IAM

The Identity Provider - Source of Truth

At the center of every IAM system sits the Identity Provider (IdP). It stores who you are, verifies it when you log in, and vouches for you to every other application. Your username, password, biometric hash, MFA enrollment --- it all lives here. Examples: Okta, Azure AD, Google Workspace, Auth0.

The flip side is the Service Provider (SP) --- the application or resource you actually want to use. Jira, Salesforce, Slack, an internal dashboard. The SP doesn't want to store your password. The IdP already has it. The rest of this blog is largely about how these two talk.

Federation - Why your Global Entry card matters?**

One more foundational concept before the protocols. Federation is a framework that lets different systems trust each other's identities. Without federation, every app would need its own user database. With federation, one system vouches for you and everyone else accepts it.

REAL-WORLD PARALLEL

Federation is like a Global Entry pass. You enrolled once with US Customs. Now any airport — anywhere in the world — accepts that pre-vetted identity and lets you skip the regular line. You didn't re-enroll at LHR, NRT, or DEL. They all trust the issuer. That's federation.

AWS IAM vs Okta**

This trips people up constantly. AWS IAM only manages access to AWS resources --- S3, EC2, Lambda. It does not manage access to Zoom, GitHub, or Google Workspace.

For enterprise-wide identity, companies use Okta or Azure AD as the IdP, then connect to AWS using federation role mapping. The developer authenticates once with Okta; Okta tells AWS IAM who they are; AWS IAM decides what they can access. Clean separation.

Enterprise Federation Pattern
Enterprise Federation Pattern

SECURITY LAYER - Multi-factor Authentication

Passwords are terrible. People reuse them, write them down, and they leak in breaches. MFA is the quiet fix.

Multi-factor authentication requires two or more pieces of evidence to prove your identity. The "multi" part only counts if the factors come from different categories. A password plus a security question is not MFA --- both are things you know. Password plus a code from your phone is MFA, because the phone is a different category.

The three factor categories:

  • Something you know --- password, PIN, passphrase.

  • Something you have --- phone with TOTP app, hardware key (YubiKey), SMS device.

  • Something you are --- fingerprint, face ID, voice, iris scan.

Any two of these = MFA. All three = strong MFA.

NOT ALL MFA IS CREATED EQUAL

SMS codes are MFA, but the weakest form — SIM-swapping is real. TOTP apps (Google Authenticator, Authy) are better. Hardware keys (FIDO2 / WebAuthn) are the gold standard because they're phishing-resistant. For serious accounts, use a hardware key.

What an MFA login actually looks like?

MFA Flow
MFA Flow

MFA is typically enforced by the IdP during the authentication step of SAML, OAuth/OIDC, or any other login flow. It's not a separate protocol so much as an additional check layered into the existing ones. This is why most of the protocols we'll cover later just assume MFA is already happening somewhere in the stack.

Authorization models you'll meet**

Once authentication is done, authorization gets interesting. Three common approaches, usually mixed in real systems:

  • RBAC (Role-Based) --- access by job title. "Admins can delete. Viewers cannot." Simple, well-understood, brittle at scale.

  • ABAC (Attribute-Based) --- decisions based on time, location, device, seniority. Example: accounting can see payroll only on office Wi-Fi, 9 a.m.--5 p.m.

  • Policy-Based --- a decision engine (like OPA) evaluates policies and returns yes/no. Most flexible.

REAL EXAMPLE — A HOSPITAL

A nurse logs in. That's authentication. But whether she can view patient records, edit prescriptions, or see billing depends on her role, department, and policy rules. That's authorization. Two different layers. Two different failure modes.

Putting it together — one day, all the layers

You are a hardware engineer on your first day.

  • MFA — you boot your laptop. Okta's policy requires password and fingerprint. Two factors, different categories. Authenticated.
  • IAM + RBAC — inside AWS, you can edit dev-environment settings because your role says so. You cannot delete production; RBAC blocks it.
  • IAM + ABAC — you try logging in from a coffee shop. ABAC policy blocks you: non-corporate IP, access denied. Come back when you're on the VPN.

All of this happened before you wrote a single line of code. That's IAM doing its job.

Quick reference

  • IAM — the framework: who can access what.
  • MFA — adding extra factor categories on top of passwords.
  • IdP / SP — identity provider / service provider.
  • Federation — different systems trusting each other's identities.
  • RBAC / ABAC — role-based vs attribute-based access control.

Good identity is invisible. You only notice it when it's broken — and at that point, everything is broken.