The IAM Career Playbook

Core Technical Foundations

If you are going to work in IAM, you need to understand the protocols. Not just at a "I know SAML is for SSO" level - at a level where you can debug a broken federation trust at 2 AM, explain to a developer why their OAuth implementation is insecure, and architect a multi-tenant authorization model that scales.

This chapter is dense. That is intentional. These are the foundations that every IAM role requires, and the depth of your understanding here is what separates an IAM administrator from an IAM architect.

Authentication - Proving "Who Are You?"

Authentication is the act of proving identity. It answers: "Are you who you claim to be?" There are three factors, and everything in authentication is built on combinations of them.

Factor What It Means Examples
Knowledge Something you know Password, PIN, security question
Possession Something you have Phone, hardware key, smart card
Inherence Something you are Fingerprint, face scan, voice print

Single-factor authentication (SFA) uses one factor - typically a password. This is the baseline, and it is inadequate for anything sensitive. Passwords are phished, stuffed, sprayed, and leaked.

Multi-factor authentication (MFA) combines two or more factors. The most common combination is password + phone-based OTP, though this is being replaced by stronger methods.

Passwordless authentication removes the knowledge factor entirely, relying on possession and/or inherence. This is where the industry is heading.

The Authentication Spectrum

AUTHENTICATION STRENGTH SPECTRUM
=================================

Weakest                                              Strongest
  |                                                      |
  ▼                                                      ▼
Password  Password   Password   Passwordless  Passkey
only      + SMS OTP  + TOTP     + Biometric   (FIDO2)
  |          |          |           |             |
  |     Phishable   Phishable   Phish-       Phish-
  |     MFA         but better  resistant    resistant
  |                                          + Hardware
  ▼                                          bound

Risk: ████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░ Low
      High

Passkeys and FIDO2

Passkeys are the biggest shift in authentication since passwords themselves. Based on the FIDO2/WebAuthn standard, passkeys use public-key cryptography to authenticate users without transmitting any shared secret.

Here is how passkey authentication works:

PASSKEY AUTHENTICATION FLOW
============================

    User                    Browser/OS              Relying Party
     |                         |                        |
     |  1. Click "Sign In"     |                        |
     |------------------------>|                        |
     |                         |  2. Request challenge   |
     |                         |----------------------->|
     |                         |                        |
     |                         |  3. Challenge + options |
     |                         |<-----------------------|
     |                         |                        |
     |  4. Biometric prompt    |                        |
     |<------------------------|                        |
     |                         |                        |
     |  5. Approve (face/touch)|                        |
     |------------------------>|                        |
     |                         |                        |
     |                         |  6. Signed assertion   |
     |                         |  (private key signs    |
     |                         |   the challenge)       |
     |                         |----------------------->|
     |                         |                        |
     |                         |  7. Verify signature   |
     |                         |  with stored public key|
     |                         |                        |
     |                         |  8. Authentication OK  |
     |                         |<-----------------------|
     |                         |                        |
     |  9. Logged in           |                        |
     |<------------------------|                        |

The critical difference from passwords: nothing secret is ever transmitted. The private key never leaves the user's device. There is nothing to phish, nothing to stuff, nothing to leak from a server breach.

Tip

If you are entering IAM in 2026, passkey expertise is a strong differentiator. Most enterprises are in the early stages of passkey adoption, and they need people who understand both the FIDO2 standard and the practical challenges of deploying passkeys alongside legacy password systems. Learn WebAuthn deeply.

Authorization - Deciding "What Can You Do?"

Authentication tells you who someone is. Authorization tells you what they can do. These are fundamentally different problems, and confusing them is a common source of security vulnerabilities.

There are four primary authorization models, each suited to different scenarios:

RBAC - Role-Based Access Control

The most widely deployed model. Users are assigned roles, and roles are assigned permissions.

RBAC MODEL
==========

  User "Alice"
       |
       ▼
  Role: "Finance Analyst"
       |
       ├──> Permission: Read financial reports
       ├──> Permission: Submit expense reports
       └──> Permission: View budget dashboards

  Role: "Project Manager"
       |
       ├──> Permission: Create projects
       ├──> Permission: Assign team members
       └──> Permission: View project budgets

Strengths: Simple to understand, easy to audit, well-supported by every IAM platform. Weaknesses: Role explosion in large organizations (thousands of roles), difficult to express fine-grained or contextual access.

ABAC - Attribute-Based Access Control

Access decisions based on attributes of the user, resource, action, and environment.

ABAC POLICY EXAMPLE
====================

IF:
  user.department = "Engineering"
  AND user.clearance_level >= "Confidential"
  AND resource.classification <= "Confidential"
  AND environment.time BETWEEN "08:00" AND "18:00"
  AND environment.location IN ("office", "vpn")
THEN:
  ALLOW action.read

Strengths: Extremely flexible, handles contextual access well, scales without role explosion. Weaknesses: Complex to implement and audit, harder for non-technical stakeholders to understand.

ReBAC - Relationship-Based Access Control

Access determined by the relationship between the user and the resource. Think Google Docs: you can access a document because you are its owner, or because someone shared it with you, or because you belong to a group that has access.

ReBAC MODEL (Google Docs example)
==================================

Document: "Q4 Budget.xlsx"
     |
     ├── owner ──> Alice (full control)
     ├── editor ──> Bob (read + write)
     ├── viewer ──> Finance Team (read only)
     └── viewer ──> Charlie (read only)

Access check: Can Charlie edit "Q4 Budget.xlsx"?
Traverse relationships: Charlie -> viewer -> read only
Result: DENY (viewer cannot edit)

Strengths: Intuitive for document/resource sharing, handles hierarchical permissions naturally. Weaknesses: Relationship graph can become complex, requires specialized infrastructure (Google Zanzibar, OpenFGA, SpiceDB).

PBAC - Policy-Based Access Control

A superset that uses policy engines (like OPA/Rego or Cedar) to express complex authorization logic.

Model Best For Complexity Audit Ease Example Use Case
RBAC Enterprise apps, compliance Low High Employee access to internal tools
ABAC Dynamic, contextual access High Medium Healthcare record access by context
ReBAC Collaborative platforms Medium Medium Document sharing, org hierarchies
PBAC Complex, multi-factor decisions Very High Low Cross-domain access in government
Note

In practice, most enterprises use RBAC as their primary model and layer ABAC or policy-based controls on top for specific use cases. Do not assume you need to pick one model - hybrid approaches are the norm in mature IAM implementations.

Federation and SSO - The Protocols That Connect Everything

Federation is the mechanism that allows identity information to flow between organizations or systems. Single sign-on (SSO) is the user experience that federation enables - log in once, access many applications.

There are three protocols you must understand deeply: SAML 2.0, OAuth 2.0, and OpenID Connect (OIDC).

SAML 2.0

SAML (Security Assertion Markup Language) is the workhorse of enterprise SSO. It is XML-based, mature, and supported by virtually every enterprise application. Despite being "old," SAML is not going away - thousands of enterprise applications only support SAML.

SAML 2.0 SP-INITIATED SSO FLOW
================================

  User          Service Provider (SP)       Identity Provider (IdP)
   |                   |                            |
   | 1. Access app     |                            |
   |------------------>|                            |
   |                   |                            |
   |                   | 2. No session - generate   |
   |                   |    AuthnRequest            |
   |                   |                            |
   | 3. Redirect to IdP with AuthnRequest           |
   |<------------------|                            |
   |----------------------------------------------->|
   |                                                |
   |                   4. User authenticates        |
   |                      (login page)              |
   |<-----------------------------------------------|
   |----------------------------------------------->|
   |                                                |
   |                   5. IdP generates SAML        |
   |                      Assertion (XML, signed)   |
   |                                                |
   | 6. Redirect back to SP with SAML Response      |
   |<-----------------------------------------------|
   |------------------>|                            |
   |                   |                            |
   |                   | 7. Validate signature,     |
   |                   |    extract attributes,     |
   |                   |    create session           |
   |                   |                            |
   | 8. Access granted |                            |
   |<------------------|                            |

Key SAML concepts to know:

  • Assertions - XML documents containing authentication statements, attribute statements, and authorization statements
  • Bindings - How SAML messages are transported (HTTP Redirect, HTTP POST, SOAP)
  • Metadata - XML files describing the SP and IdP endpoints, certificates, and capabilities
  • Relay State - Preserves the user's original destination URL through the SSO flow

OAuth 2.0

OAuth 2.0 is an authorization framework - not an authentication protocol. This distinction matters. OAuth answers "what can this application access on my behalf?" not "who is this user?"

OAUTH 2.0 AUTHORIZATION CODE FLOW
===================================

  User        Client App       Auth Server      Resource Server
   |              |                 |                  |
   | 1. Click     |                 |                  |
   |  "Login"     |                 |                  |
   |------------->|                 |                  |
   |              |                 |                  |
   |  2. Redirect to auth endpoint  |                  |
   |<-------------|                 |                  |
   |-------------------------------->                  |
   |              |                 |                  |
   |  3. User authenticates + consents                 |
   |<-------------------------------|                  |
   |              |                 |                  |
   |  4. Redirect back with authorization code         |
   |<-------------------------------|                  |
   |------------->|                 |                  |
   |              |                 |                  |
   |              | 5. Exchange code|                  |
   |              |    for tokens   |                  |
   |              |    (+ client    |                  |
   |              |     secret)     |                  |
   |              |---------------->|                  |
   |              |                 |                  |
   |              | 6. Access token |                  |
   |              |    + Refresh    |                  |
   |              |    token        |                  |
   |              |<----------------|                  |
   |              |                 |                  |
   |              | 7. API call with access token      |
   |              |--------------------------------------->
   |              |                 |                  |
   |              | 8. Protected resource              |
   |              |<---------------------------------------|
   |              |                 |                  |
   | 9. Response  |                 |                  |
   |<-------------|                 |                  |

Key OAuth 2.0 grant types:

Grant Type Use Case Security Level
Authorization Code Server-side web apps High
Authorization Code + PKCE Mobile/SPA apps High
Client Credentials Machine-to-machine High (no user context)
Device Code Smart TVs, CLI tools Medium
Implicit (DEPRECATED) Legacy SPAs Low - do not use
Resource Owner Password (DEPRECATED) Legacy migration Low - do not use
Warning

If you encounter an application still using the Implicit grant or Resource Owner Password Credentials grant, flag it immediately. Both are deprecated in the OAuth 2.1 specification and have known security vulnerabilities. The Authorization Code flow with PKCE is the correct replacement for all client-side applications.

OpenID Connect (OIDC)

OIDC is an authentication layer built on top of OAuth 2.0. It adds the identity piece that OAuth deliberately excluded. When someone says "we use OAuth for login," they almost always mean OIDC.

OIDC adds:

  • ID Token - A JWT containing claims about the authenticated user (sub, name, email, etc.)
  • UserInfo Endpoint - An API to retrieve additional user profile information
  • Discovery Document - A well-known URL (/.well-known/openid-configuration) that describes the provider's capabilities
  • Standard Scopes - openid, profile, email, address, phone
OIDC vs OAuth 2.0 vs SAML
===========================

                SAML 2.0          OAuth 2.0         OIDC
                --------          ---------         ----
Purpose:      Authentication    Authorization    Authentication
              + Attributes      (delegated)      (on OAuth 2.0)

Token format: XML Assertion     Opaque or JWT    JWT (ID Token)
                                (Access Token)    + Access Token

Transport:    HTTP Redirect,    HTTP             HTTP
              HTTP POST, SOAP

Best for:     Enterprise SSO    API access       Modern SSO,
              (legacy apps)     delegation       mobile, SPA

Year created: 2005              2012             2014

Directory Services and Identity Stores

Every IAM system needs a source of truth for identity data. Understanding directory services is foundational.

Active Directory (AD) - Microsoft's on-premise directory. Still the backbone of most enterprise identity. Uses LDAP protocol. Understanding AD - OUs, group policies, trusts, replication - is essential for any workforce IAM role.

Microsoft Entra ID (formerly Azure AD) - Cloud directory. Not just "AD in the cloud" - architecturally different. Uses REST APIs, not LDAP. Supports SAML, OIDC, and SCIM natively.

LDAP (Lightweight Directory Access Protocol) - The protocol for querying directories. Think of it as SQL for identity data. You query for users, groups, and attributes using search filters like (&(objectClass=user)(department=Engineering)).

SCIM (System for Cross-domain Identity Management) - A REST API standard for provisioning and deprovisioning users across systems. When HR creates a new employee in Workday, SCIM is how that identity gets pushed to Okta, then to Salesforce, then to Slack.

Token Types

Tokens are the currency of IAM. Every authentication and authorization decision results in a token that carries identity and permission information.

JWT (JSON Web Token)

The dominant token format in modern IAM. A JWT has three parts: header, payload, and signature, separated by dots.

JWT STRUCTURE
=============

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkFsaWNlIn0.signature
|___________________|.|__________________________________________|.|________|
      Header                        Payload                       Signature

Header (decoded):
{
  "alg": "RS256",
  "typ": "JWT"
}

Payload (decoded):
{
  "sub": "1234",           // Subject (user ID)
  "name": "Alice",         // User's name
  "email": "alice@co.com", // Email
  "iat": 1700000000,       // Issued at
  "exp": 1700003600,       // Expiration (1 hour)
  "iss": "https://idp.co", // Issuer
  "aud": "app-client-id"   // Audience
}
Warning

JWTs are not encrypted by default - they are only signed. Anyone can decode and read the payload. Never put sensitive data (SSNs, passwords, medical records) in a JWT payload. Use JWE (JSON Web Encryption) if you need confidentiality, but prefer keeping sensitive data server-side and using the JWT only as a reference.

SAML Assertions

XML-based tokens used in SAML flows. More verbose than JWTs but carry rich attribute information and support complex signing and encryption. You will encounter these in every enterprise SSO implementation.

Opaque Tokens

Random strings that reference server-side session data. More secure in some ways (no client-side data exposure) but require server-side storage and lookup. Used by some OAuth implementations for access tokens.

Putting It All Together

Here is a mental model for how these pieces fit together in a real enterprise:

ENTERPRISE AUTHENTICATION ARCHITECTURE
========================================

Employee logs in:
  Browser -> Okta (IdP) -> SAML assertion -> Salesforce (SP)
                        -> OIDC ID token  -> Custom web app
                        -> OAuth token    -> API gateway

Customer logs in:
  Mobile app -> Auth0 (CIAM) -> OIDC flow with PKCE
                              -> JWT access token -> API
                              -> Refresh token -> Token renewal

Service authenticates:
  Microservice A -> OAuth client_credentials -> Access token
                 -> API call to Service B with Bearer token

The technical foundations covered in this chapter are not optional knowledge - they are the vocabulary of IAM. Every interview, every architecture discussion, every troubleshooting session will use these concepts. Master them, and you have the base on which to build any IAM specialization.