Identity and Access Management

What it is

Identity and Access Management (IAM) is the framework of policies, processes, and technologies that ensures the right entities (users, services, devices) can access the right resources at the right time — and that all others are denied. IAM encompasses three interconnected concerns: Authentication (verifying identity — "who are you?"), Authorisation (determining permissions — "what are you allowed to do?"), and Directory & Lifecycle (managing identity records — creating, updating, and deprovisioning accounts). An Identity Provider (IdP) is the system of record for identities: it manages user accounts, authentication credentials, and group memberships, and issues tokens that applications trust. Leading enterprise IdPs include Okta, Azure Active Directory, Google Workspace, and Ping Identity.

SAML 2.0 (Security Assertion Markup Language) is the XML-based federation standard used for enterprise SSO, particularly for connecting on-premises applications to cloud IdPs. OIDC (OpenID Connect) is the modern JSON/JWT-based identity layer on top of OAuth 2.0, used for web and mobile application authentication and API access. Both enable federation: users authenticate once at the IdP and receive assertions that multiple service providers (applications) accept without each application managing its own user database. SCIM (System for Cross-domain Identity Management) is the standard protocol for automated user provisioning and deprovisioning between the IdP and downstream applications — when an employee is terminated in the HR system, SCIM propagates the deprovisioning to all connected applications within minutes rather than days.

Why it exists

Without a centralised IAM strategy, each application manages its own user database, resulting in credential proliferation (users have different passwords for each system), inconsistent access controls (a terminated employee's access may be revoked from one system but not another), and no unified audit trail of who accessed what. The 2023 Identity Theft Resource Center Annual Data Breach Report found that over 60% of data breaches involved a compromised identity. Federated IAM with SSO reduces the attack surface to a single, well-hardened IdP authentication endpoint, enables rapid deprovisioning across all connected applications, and provides a centralised audit log for compliance requirements. Privileged Access Management (PAM) further reduces the risk of privileged credential compromise by managing and recording all access to privileged accounts (root, domain admin, database admin) through a dedicated just-in-time access system.

When to use

• Any organisation with more than one application — federated SSO immediately reduces credential fatigue and deprovisioning risk.
• Cloud and SaaS environments where workforce identity must span on-premises and cloud systems.
• Environments requiring compliance with SOX, HIPAA, or PCI DSS, all of which mandate access control documentation and regular access reviews.
• Organisations with contractors or partners who need scoped, time-limited access to internal resources.
• Privileged access (production databases, cloud root accounts, infrastructure) — always requires PAM with just-in-time access and session recording.

When not to use

• Simple single-application products: A startup with one application and 5 employees does not need an enterprise IdP; basic username/password with MFA is sufficient initially. Adopt an IdP when the second application is added.
• Customer identity (CIAM) — different concerns: Customer Identity and Access Management for consumer users (millions of users, social login, self-service registration) uses different products (Auth0, Cognito, Firebase Auth) and patterns from workforce IAM.

Typical architecture

FEDERATED IAM ARCHITECTURE:

  HR System (source of truth)
       │ SCIM provisioning
       ▼
  Identity Provider (Okta / AAD)
  - User directory + groups
  - MFA policies
  - Conditional access rules
  - SCIM server
       │
       ├── SAML 2.0 ──→ Legacy SaaS (Salesforce, SAP)
       │
       ├── OIDC/OAuth2 ──→ Internal web apps
       │                   API gateway (JWT validation)
       │
       └── SCIM ──→ Downstream apps (auto-provision/deprovision)

OIDC FLOW (web app):
  1. User visits app, unauthenticated
  2. App redirects to IdP: /authorize?
         client_id=xxx&scope=openid+email
         &redirect_uri=https://app/callback
         &code_challenge=... (PKCE)
  3. User authenticates at IdP (+ MFA)
  4. IdP returns auth_code to app
  5. App exchanges code for tokens:
         id_token (JWT, identity claims)
         access_token (API access)
         refresh_token (long-lived)
  6. App validates id_token signature (JWKS endpoint)
  7. Session established

JIT PROVISIONING:
  User from federated org authenticates via SAML;
  if no local account exists, create on first login
  using attributes from SAML assertion
  (email, name, department, role)

PAM PATTERN:
  Engineer needs DB access →
  Requests access in PAM portal →
  Just-in-time: generates temp credential, TTL 4h →
  Session recorded in PAM vault →
  Credential auto-revoked at TTL
  All commands logged for audit

Pros and cons

Implementation notes

When integrating applications with an OIDC IdP, always validate the ID token on the server side: verify the signature against the IdP's JWKS endpoint, check the iss (issuer) and aud (audience) claims, and verify the token is not expired (exp claim). Never trust an ID token without verification. Use PKCE (Proof Key for Code Exchange) for all public clients (SPAs, mobile apps) to prevent authorisation code interception. For API access, use short-lived access tokens (15–60 minutes) validated by the API gateway using the IdP's JWKS endpoint; do not pass user session cookies to APIs. For service-to-service authentication (machine identity), use client credentials flow with client IDs and secrets stored in a secrets manager, not hardcoded.

Role-Based Access Control (RBAC) should be defined in terms of business roles (editor, viewer, admin) rather than technical permissions, mapped to permissions at authorisation time. Avoid adding users directly to permission groups; always assign roles, and map roles to permissions in the application. Conduct quarterly access reviews: export the current user-role mapping from the IdP and have managers confirm that each user's access reflects their current job function. Automate deprovisioning: SCIM-based auto-deprovisioning is strongly preferred over manual processes, which inevitably lag.

Common failure modes

• No break-glass procedure: If the IdP is unavailable and all admin access requires SSO, there is no way to recover — maintain a break-glass local admin account with MFA and a documented emergency access procedure.
• SAML XML signature wrapping attacks: Misconfigured SAML implementations that do not validate the signature on the entire assertion (only on the outer element) are vulnerable to signature wrapping attacks where an attacker inserts malicious assertions.
• Stale group memberships: Groups in the IdP that are never audited accumulate excessive membership; without regular access reviews, over-privileged access persists indefinitely.
• Service accounts with interactive passwords: Service accounts that use username/password credentials shared among multiple developers are unauditable and cannot be safely rotated — use workload identity (IAM roles, service account tokens) instead.
• Missing offboarding automation: An employee who leaves without triggering SCIM deprovisioning retains access to all applications connected to the IdP; HR-to-IdP integration must be tested and monitored.

Decision checklist

• Is there a centralised IdP for all workforce users with MFA enforced?
• Are all applications connected via SAML or OIDC for SSO rather than managing their own user directories?
• Is SCIM provisioning/deprovisioning configured between the HR system, IdP, and downstream applications?
• Are privileged accounts (production access, cloud admin) managed through a PAM solution with JIT access?
• Are OIDC tokens validated on the server side (signature, issuer, audience, expiry)?
• Is there a break-glass procedure for IdP unavailability?

Example use cases

• Enterprise SSO rollout: 500-person company consolidates 30 separate application logins to Okta SSO with SAML; engineers log in once, access Jira, GitHub, AWS console, and internal tools via SSO with hardware MFA required for cloud console access.
• B2B SaaS multi-tenancy: Customer enterprises bring their own IdP (Azure AD, Okta); the SaaS platform supports SAML federation per customer, using JIT provisioning to create user records on first login without the SaaS provider managing customer passwords.
• Production database access: DBAs use CyberArk PAM to request temporary PostgreSQL credentials scoped to their task; credentials expire after 4 hours; all executed SQL statements are recorded in the PAM vault for audit.

Related patterns

• Zero Trust Architecture — Identity is the control plane for Zero Trust; IAM is the foundational layer.
• Secret Management — Service account credentials managed alongside human identity credentials.
• API Authentication — OIDC tokens used for API access control.

Further reading

• OpenID Connect Specification
• SCIM: System for Cross-domain Identity Management
• OWASP Top 10: Broken Access Control