IAM - The Identity Puzzle

How IAM, MFA, SCIM, SAML, and OAuth quietly hold the internet together --- and why that matters when you log in with Google at 2 a.m.

Identity & Access · 14 min read · Deep dive

Why this matters?

Every time you click "Sign in with Google," five different protocols fire off in under a second. Most of the time, you never think about it. Until you're the one building it.

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 guide walks through the five acronyms that run the show: IAM, MFA, SCIM, SAML, and OAuth 2.0. They're often explained in isolation, which is why they feel confusing. The truth is they're a team --- each one solves a piece the others can't. We'll build them up in order: the framework first, then the security layer, then the automation, then the protocols that tie everything 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.

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 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.

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.

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.

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.

What an MFA login actually looks like?

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.

SCIM - System for Cross-domain Identity Management

When a company hires 200 people on Monday, who creates their Gmail, Slack, Jira, and 30 other apps? And when someone quits, who remembers to delete all of them?

If the answer is "IT tickets," you have a problem. People get missed. Accounts linger for months after someone leaves, which is a security nightmare. Access creeps. Reviews slip.

SCIM --- System for Cross-domain Identity Management --- is the boring, beautiful protocol that fixes this. It's a REST API specification for creating, updating, and deleting user accounts across systems automatically. It defines a standard schema for users and groups, and a standard set of REST endpoints exposing POST, GET, PATCH, and DELETE operations on them.

How SCIM actually works?

1. An event happens in a source of truth. Usually the HR system: someone joined, someone was promoted, someone left.

2. The HR system fires that event at the identity provider (Okta, Azure AD) via SCIM.

3. The IdP creates or updates the user in its identity repository.

4. The IdP pushes the change via SCIM REST calls to every connected downstream app --- Gmail, Slack, Jira, Zoom, GitHub --- that has a SCIM endpoint.

5. All accounts get created, updated, or deactivated automatically. No tickets.

SCIM Centralization

A subtle point that only hits you once you've built this yourself. If every internal app implemented SCIM directly, you'd have a massive problem: every codebase maintains its own SCIM compliance. Every spec change triggers redundant work across dozens of services. Logs are scattered. Behavior is inconsistent.

That's where a centralized SCIM service earns its keep. Instead of every internal system listening to SCIM directly, companies build a central service between the IdP and the apps.

A centralized SCIM service plays two roles:

• Passive role --- exposes SCIM-compliant endpoints (/Users, /Groups) so the IdP can push user and group updates using the standard spec.

• Active role --- becomes the source of truth for internal systems. Once user data is stored there, it actively syncs out to other apps using internal APIs rather than SCIM.

SCIM compliance lives in one place. Spec changes happen once. Logs are centralized. Internal apps get a simpler, stable interface and don't each have to speak REST-compliant SCIM.

"MFA proves you are still you. SCIM makes sure you exist --- or don't --- in the right places. The protocols come next."

SAML PROTOCOL

SAML is what happens when a big serious company with compliance officers decides to do single sign-on. It's verbose, it's XML, and it's been running enterprise logins since 2005.

Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between two parties: an Identity Provider (IdP) and a Service Provider (SP). It was designed to solve one specific problem --- single sign-on across different organizations --- without exposing passwords.

The three actors

• User --- the human who wants to use a service.

• Identity Provider (IdP) --- knows who you are and verifies it. Examples: Google Workspace, Okta, Microsoft Entra ID, ADFS.

• Service Provider (SP) --- the application you're trying to use. Examples: Salesforce, Microsoft 365, Workday, Jira.

The SAML Assertion

At the heart of SAML is the assertion --- an XML document signed by the IdP that says, essentially: "yes, this is a real user, here's their name, email, and role, and I'm vouching for them at this exact time."

The assertion contains:

• User info --- name, email

• Authorization levels --- roles, permissions

• Timestamps --- when issued, when it expires

• A digital signature from the IdP so the SP can verify authenticity

SAML in practice

SCENARIO / SAML WORKED EXAMPLE

Priya is a sales rep at Acme Corp. Acme uses Okta as their identity provider. Priya opens her laptop in the morning, types acme.my.salesforce.com in her browser, and just... ends up logged in. Here's every single thing that happened behind the scenes:

Notice what Priya never did: create a Salesforce password. Notice what Salesforce never saw: Priya's password or her YubiKey touch. The only thing it got was a signed XML statement from a system it already trusts. That's the whole magic.

OAUTH2.0 PROTOCOL

OAuth 2.0 solves a completely different problem. Imagine a scheduling app wants to read your Google Calendar so it can suggest meeting times. The bad solution: give the app your Google password. You've now handed over permission to do anything --- read all your email, delete photos, change your account recovery, lock you out.

OAuth's core idea is delegated, limited authorization. Instead of sharing a password, you get a token. The token says: "this app can read this user's calendar, for the next hour, and nothing else."

The four actors

• Resource Owner --- you, the user who owns the data.

• Client --- the third-party app that wants access (e.g., the scheduling app).

• Authorization Server --- issues the token after you consent (e.g., Google's OAuth endpoints).

• Resource Server --- holds the data and accepts the token (e.g., Google Calendar API).

The access token --- what's actually passed around

The access token is the core of OAuth. It's issued by the authorization server, handed to the client, and presented to the resource server when the client wants to do something. Key properties:

• It is not your password.

• It is scoped --- it lists exactly which permissions were granted.

• It is short-lived --- expires, often in minutes or hours.

• It can be revoked at any time by the user.

The same pattern runs behind "Sign in with Google," "Log in with Facebook," "Connect your Dropbox" --- any time a third-party app gets scoped, revocable access to your data without ever seeing your password.

OAUTH 2.0 WORKED EXAMPLE

Priya wants to order prints of her vacation photos from PrintMyPics, a third-party photo-printing service. Her photos live in Google Photos. PrintMyPics needs read access --- but has no business knowing her Google password. Here's the OAuth 2.0 flow step by step:

Two weeks later, Priya visits her Google account settings, finds PrintMyPics in "Third-party apps with account access," and clicks "Remove access." The token dies. Future API calls return 401 Unauthorized. She never changed her password. She never exposed her Google account. That's the whole point.

OpenID Connect PROTOCOL

OpenID Connect --- OAuth's identity twin

Here's the historical mess: OAuth 2.0 was never designed to tell you who a user is. It was only ever designed to say what an app is allowed to do. But developers kept abusing OAuth for login anyway --- basically asking "hey Google, give me a token for this user's profile, and if I can get that token, I'll assume they're logged in."

This kind of worked. It also kind of didn't. There was no standard way to describe who the user was, and every implementation handled it slightly differently. So in 2014, a new standard emerged: OpenID Connect (OIDC).

What's actually different?

Two things change when you add OIDC on top of OAuth:

• You request the openid scope --- tells the auth server "also give me identity info, not just permission tokens."

• You get back an ID token alongside the access token. The ID token is a signed JWT (JSON Web Token) containing claims: user ID, name, email, issued-at, expires-at, issuer.

The access token is still for making API calls. The ID token is purely for proving identity --- it's cryptographically signed, your backend can verify it locally, and you don't have to trust the access token to figure out who's logged in.

OIDC WORKED EXAMPLE

Priya wants to use Notion for her personal notes. Notion's login page shows three buttons: Email, Google, Apple. She clicks "Continue with Google." Here's what happens:

The three-way comparison

Now that all three protocols are on the table, here's the side-by-side. This comparison gets muddled constantly --- people call SAML and OAuth "competitors" when they're not, or confuse OAuth and OIDC when one is built on the other. The honest answer: each was built for a different problem, and they all survived because they each win in their own territory.

Summary

After all this, there's one sentence that captures the whole thing: SAML and OIDC both answer "who is this user?" --- just in different eras and formats. OAuth answers a completely different question: "what is this app allowed to do?"

Rule of thumb: enterprise laptop + legacy apps → SAML. Modern app + external login button → OIDC. Third-party app needs to touch your data → OAuth.

The whole picture in one story, stitched together from everything above. You are a hardware engineer on your first day. Follow the acronyms.

1. SCIM --- HR marks you "started." The event fires via SCIM to Okta, which creates your identity record. Okta fans out via SCIM to every connected app --- AWS, Slack, GitHub, Jira, email --- creating your accounts automatically.

2. MFA --- you boot your laptop. Okta's policy requires password and fingerprint. Two factors, different categories. Authenticated.

3. SAML --- through federation, Okta vouches for you via a signed SAML assertion to AWS and Slack. You log in once. No second password anywhere.

4. IAM + RBAC --- inside AWS, you can edit dev-environment settings because your role says so. You cannot delete production; RBAC blocks it.

5. 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.

6. OAuth 2.0 --- a scheduling app asks for your Google Calendar. You grant it a scoped, short-lived token. The app never sees your password. You revoke it two weeks later with one click.

7. SCIM --- two years later, you leave. HR flips one bit. SCIM propagates the deactivation to all 50 apps instantly. No lingering access.

All mechanisms worked together. You, as the engineer, barely noticed any of them. That's the goal.

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

The quick reference

• IAM --- the framework: who can access what.

• MFA --- adding extra factor categories on top of passwords.

• SCIM --- automated user provisioning and de-provisioning across systems.

• SAML --- XML-based SSO protocol for enterprise apps.

• OAuth 2.0 --- delegated authorization via short-lived tokens.

• OIDC --- OAuth 2.0 plus identity. What "Sign in with Google" uses.

• Federation --- different systems trusting each other's identities.

• IdP / SP --- identity provider / service provider.

• RBAC / ABAC --- role-based vs attribute-based access control.

Build something boring and bulletproof. Your future self --- and your security team --- will thank you.

FROM THE ARCHIVES

My Nutanix RBAC Talks

A lot of what I wrote above is theory. Here's the theory colliding with a real product. Back at Nutanix, I recorded a three-part series on Fine-Grained RBAC in Prism Central 2024.1 --- the management plane for Nutanix clusters. If RBAC and IAM feel abstract after reading this, these videos are the concrete version.

Prism Central is a great case study because it implements almost every concept above. It speaks SAML to external IdPs like ADFS or Okta. It supports LDAP and local users. It has a full RBAC system with roles, permissions, and entity-level scoping. In 2024.1, it added fine-grained permissions --- the kind of granular, least-privilege control enterprise security teams actually want.

Watch them in order and the arc maps almost exactly to the IAM chapter of this blog --- identity comes in via SAML or LDAP, roles decide what users can do, and fine-grained permissions let admins get surgical about entity-level access. Same concepts, specific product.