Security Engineering / Fundamentals / Identity
Fundamental 07

Identity &
authentication When the network stops being a boundary, identity becomes the boundary. Learn SAML and OIDC properly — not the marketing version — and session-token theft, conditional access and phishing-resistant MFA all become one coherent subject.

underpins Netskope, Workspace, AWS4 tiers
Tier 0 · Grounddefinitions

Four words people use interchangeably

Module 0.1

Authentication, authorisation, federation, SSO

Precision here prevents most design confusion
  • Authentication (AuthN) — proving who you are. Passport control.
  • Authorisation (AuthZ) — what you may then do. The boarding pass and seat number.
  • Federation — one system trusting another's assertion about identity, so the app never sees your password.
  • SSO — the user experience produced by federation: authenticate once, access many.

Actors: the IdP (identity provider — Okta, Entra ID, Google) authenticates; the SP or RP (service provider / relying party — Netskope, AWS, SentinelOne) trusts it.

The security consequence of SSO: compromise of one IdP account is compromise of everything behind it. That is a deliberate trade — you concentrate risk in one place so you can defend that place extremely well with MFA, conditional access, logging and rapid revocation. It only pays off if you actually do that.
Tier 1 · Mechanicsprotocols

SAML, OAuth and OIDC

Module 1.1

SAML 2.0

XML, signatures, and the assertion that is the whole security model
1User hits the app (SP). SP redirects the browser to the IdP with a SAML AuthnRequest.
2IdP authenticates the user (password + MFA), then issues a signed SAML assertion.
3Browser POSTs the assertion to the SP's ACS URL.
4SP validates the signature against the IdP certificate, checks Audience, NotOnOrAfter and Recipient — then creates its own session.

Key fields: NameID (the subject), Audience (which SP this is for — checking it prevents assertion replay elsewhere), Conditions/NotOnOrAfter (validity window), and attribute statements carrying group membership used for authorisation.

Failure modes to check in any SAML integration: the SP not validating signatures at all; accepting unsigned assertions; ignoring Audience; certificate expiry causing a Friday outage; and the "golden SAML" attack, where an attacker who steals the IdP's signing key can mint assertions for any user, to any app, bypassing MFA and leaving almost no trace at the IdP. Protect that key like a root CA.
Module 1.2

OAuth 2.0 and OIDC

Delegated authorisation vs identity — the distinction that matters

OAuth 2.0 is not authentication. It is delegated authorisation: "let this app read my Drive files". OIDC is the thin layer on top that adds an id_token — a signed JWT actually asserting who the user is. Using bare OAuth for login is a classic design flaw.

1App redirects to the authorisation server with client_id, scope, redirect_uri, state, and a PKCE challenge.
2User consents to the requested scopes.
3Authorisation code returned to the redirect URI.
4App exchanges code (+ PKCE verifier + client secret) for access token, refresh token and id_token.

Token anatomy — a JWT has three dot-separated base64 parts: header, payload (claims: iss, sub, aud, exp, iat, plus custom claims), and signature. You can decode the payload with base64 alone; anyone can. Never put secrets in a JWT, and always verify the signature and aud server-side.

The OAuth risk that bites organisations

Illicit consent grants. A phishing page asks the user to authorise a plausible-looking app for mail.read and drive.readonly. The user genuinely authenticates — MFA and all — and the attacker walks away with a refresh token that survives password resets. No malware, no network traffic through your proxy. Defences: restrict third-party app access in Workspace, require admin approval for sensitive scopes, review granted apps regularly, and alert on new grants for high-risk scopes.

Module 1.3

MFA, ranked honestly

Not all second factors are equal
FactorResists phishing?Notes
SMS / voiceNoSIM swap, SS7, real-time relay. Better than nothing, barely.
TOTP appNoRelayed through an AiTM proxy in seconds.
Push approvalNoMFA fatigue bombing. Number matching helps a lot.
FIDO2 / WebAuthn / passkeyYesOrigin-bound: the authenticator refuses to sign for the wrong domain.
Device-bound certificateYesStrong, requires managed devices and PKI.

Adversary-in-the-Middle (AiTM) phishing kits proxy the real login page, capture credentials and the resulting session cookie, then replay the cookie. MFA is satisfied because the user really did complete it. This is why "we have MFA" is no longer an adequate answer, and why phishing-resistant factors plus device binding matter for admin and finance roles at minimum.

Module 1.4

Sessions and token theft

The attack that skips authentication entirely

After login, the app issues a session cookie or token. Anyone holding it is the user until it expires. Infostealer malware harvests exactly this from browser profiles, which is why an endpoint infection must be treated as an identity incident.

Response checklist for suspected token theft

  1. Revoke all sessions and refresh tokens for the user (not just a password reset — that alone often leaves sessions alive).
  2. Re-register MFA if there is any doubt; check for attacker-added factors.
  3. Review OAuth grants and app passwords created in the window.
  4. Check mail rules, forwarding and delegation (see the Email path).
  5. Isolate and reimage the endpoint; assume every credential in that browser profile is compromised.

Preventive levers: shorter session lifetimes for sensitive apps, token binding/continuous access evaluation where supported, and conditional access that re-evaluates device compliance rather than trusting a cookie for 30 days.

Drill 1

A user reports a suspicious login alert. Sign-in logs show a successful authentication with MFA satisfied, from a country they have never visited, followed minutes later by a new inbox rule. Most likely?

AiTM. The proxy relayed the real login, so MFA shows as satisfied — the log looks clean apart from the geography. The inbox rule is the tell: attackers create rules to hide replies while running invoice fraud. Response: revoke sessions and refresh tokens, reset credentials, remove the rule, hunt the same source IP and user-agent across other accounts, and treat phishing-resistant MFA as the remediation rather than more user training.
Tier 2 · Engineerdesign

Lifecycle and access decisions

Module 2.1

Conditional access as a policy language

Signals in, decision out
SIGNALS DECISION user / group ─┐ device compliance ─┤ managed vs BYOD ─┼──▶ allow | allow with MFA | location / IP ─┤ block | limited session risk score ─┤ application ─┘

Sensible starting policies: require phishing-resistant MFA for admins; block legacy authentication protocols outright; require a compliant, managed device for anything holding customer data; require MFA on any new device or unusual location; and restrict admin console access to managed devices only.

Where this stack plugs in: device posture comes from MDM/EDR, is consumed by the IdP for conditional access and by Netskope for steering and policy. A single posture signal driving both is the design worth aiming at — otherwise the two disagree and users find the gap.
Module 2.2

Joiners, movers, leavers and privileged access

The unglamorous controls auditors always test
  • SCIM provisioning from the IdP so accounts are created and — critically — deprovisioned automatically. Manual offboarding always drifts.
  • Movers are worse than leavers: people accumulate access across role changes. Periodic access reviews exist for exactly this, and they are a standard control test in SOC 2 and ISO audits.
  • Privileged access: separate admin accounts, just-in-time elevation with approval and expiry, break-glass accounts stored offline with monitored use, and no shared credentials.
  • Service accounts and API keys need owners, expiry and rotation. Unowned service accounts are how old access survives every review.
Referencesearchable

Glossary