IAM Chapter 1: Identity & Authentication

Part of the IAM study series.

Every app, at some point, has to answer two questions: who is this? and is it really them? The first is identity. The second is authentication. They sound close enough to use interchangeably, and that's exactly where confusion starts.

Skyline Manufacturing — a fictional aerospace supplier with 8,000 people and 200 apps — gives every one of those apps the same two questions to answer. Without a shared answer, you get 200 user lists, 200 passwords per person, forgotten leavers, and breaches.

Attribute, Identity, Account

An attribute is one fact about a person — department, manager, employee ID.

An identity is the set of attributes that uniquely describes one person in an organization. NIST SP 800-63-4 puts it formally: "an attribute or set of attributes that uniquely describes a subject within a given context."

For John Wick, that's: employee ID 1001, department Engineering, manager Winston, start date 1 Nov 2026 — sourced from Workday, the system of record. HR knows it first: join, move, leave. A good test for whether something is an identity attribute: would HR know it, and is it true everywhere? Manager — yes. Password — no, a password doesn't belong to the person, it belongs to an account.

An account is one system's record of John: his username, the authenticators registered to it, and his permissions. John has one identity but three accounts — jwick in Active Directory, JWICK01 in the PLM system, JW1001 in SAP — each with its own password. One identity, many accounts.

Correlation is linking every account back to its one identity. A correlated account is tied to employee ID 1001, so when John leaves, every linked account gets found and disabled. An orphan account — one never linked, like a PLM account created outside the normal provisioning flow — stays active after John leaves. That's a common way attackers get in: nobody remembers it exists.

Authenticators and MFA

An authenticator is what John presents to prove he controls his account — the everyday word is "credential," but NIST reserves that term for something narrower: the record issued by a credential service provider that binds an identity to an authenticator. Not the password itself.

A factor is a type of evidence, and there are three:

MFA requires two or more different factor types — it counts types, not steps. Password + phone approval is MFA (know + have). Password + PIN is not MFA, even though it's two pieces of evidence — both are "know," and a single fake login page can steal both at once.

Authentication (AuthN)

Authentication is the process of verifying a user is who they claim to be, by checking the proof they present. NIST's definition: "the process by which a claimant proves possession and control of one or more authenticators bound to a subscriber account to demonstrate that they are the subscriber associated with that account."

Four parts, in order:

Claim → Proof → Check → Session

John types jwick (the claim). He gives a password and taps Approve on his phone (the proof — his to supply). The system verifies both (the check — the system's job). He's logged in (the session — the remembered login, until logout, app close, or timeout).

One trap worth naming: the phone approval is proof, something John gives, not the check itself. And none of this is authorization yet — that's what John is allowed to do, covered in the next chapter.

🔴 CHECKPOINT: Study Notes

Back to the series start · Next: Authorization, IdP & Directories →