dashboard radar bug_report school newspaper sensors

Learning Hub › Foundational Security › IAM Fundamentals

Foundations 01 · Interactive guide

IAM Fundamentals

Identity and Access Management decides who you are, what you may do, and keeps a record of it. Most breaches start with a stolen or misused identity, so IAM is the first line of defence. This guide goes from the basics to passkeys, RBAC vs ABAC, access reviews and single sign-on, with something to try in every section.

01

Identify, authenticate, authorise, account

Every access decision walks the same four steps. Click each step to compare a familiar office building with what happens when you sign in to a company app.

02

Authentication factors and MFA

A factor is something you know, have or are. Multi-factor authentication (MFA) means factors from different categories: a password plus a PIN is still one category. Build a sign-in and see how strong it is.

Pick the factors your sign-in uses

Password check, NIST SP 800-63B-4 style

Runs in your browser

The 2025 NIST rules flipped old advice: length beats complexity, no forced symbol rules, no expiry every 90 days, but block passwords that are common or known to be breached. Nothing you type leaves this page.

    03

    Authorisation: RBAC vs ABAC

    Role-Based Access Control gives permissions to roles, then people to roles: simple and auditable. Attribute-Based Access Control decides each request from attributes of the user, resource and context: flexible, but harder to audit. Most companies use RBAC with a few ABAC rules on top. The hospital below is fictional.

    RBAC: change someone's role

    Teaching model

    Pick a role in the first column. The permissions follow the role, never the person.

    ABAC: one request, many attributes

    Teaching model
    ALLOW read on PatientRecord WHEN
  user.role IN [Nurse, Doctor]
  AND user.ward == record.ward
  AND device.managed == true
  AND (time IN shift OR user.role == Doctor)
    04

    Least privilege and the access review

    Give each identity only the access it needs, for only as long as it needs it. Access piles up when people change jobs ("privilege creep"), so teams manage the joiner-mover-leaver lifecycle and run periodic access reviews. Try one.

    Joiner

    New starter gets a birthright role on day one: email, HR portal, team apps. Nothing more.

    Mover

    Changes team: new role added and old access removed. The removal is the step most often missed.

    Leaver

    Disable the account and revoke sessions and tokens on the last day, ideally driven automatically by HR.

    Scenario · Priya moved from Finance to Marketing three months ago. You are her new manager. Keep or revoke each entitlement. (Fictional.)
    05

    Single sign-on: SAML, OAuth 2.0 and OpenID Connect

    With SSO, one trusted identity provider (IdP) signs you in and vouches for you to many apps. Apps never see your password, and IT can switch off access in one place.

    SAML 2.0

    Authentication · 2005

    XML "assertions" passed through the browser. Still the workhorse for enterprise web apps.

    OAuth 2.0

    Authorisation · 2012

    Lets an app act on your behalf with a limited access token ("read my calendar"). On its own it doesn't say who you are.

    OpenID Connect

    Authentication · 2014

    An identity layer on OAuth 2.0. Adds a signed ID token (a JWT) that says who signed in. The modern default for web and mobile.

    Walk through an OIDC sign-in (authorization code flow with PKCE)

    This is what happens behind "Sign in with your company account". PKCE stops a stolen authorization code from being useful.

      06

      Myth or fact?

      Five common beliefs about identity security.

      07

      Sources & further reading

      Next: the Zero Trust deep dive puts identity at the centre of every access decision, and Cryptography Basics explains the signatures behind passkeys and ID tokens.