Identity & Access Deep Dive

Every IT technical screen reaches the same moment: "a user can't log into app X via SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. - walk me through it." The candidates who pass don't recite the spec, they read a decoded assertion out loud and name the field that's wrong.

SAMLAn enterprise standard that powers single sign-on. is a browser-redirect protocol that lets a user authenticate once at the IdP (Okta, Entra) and ride that login into a SP (the app - Slack, Zoom, an internal tool). The IdP packages identity into a signed XML assertion and the SP trusts it because of a shared certificate. Nothing in the flow is secret; the trust comes entirely from the signature.

SP-initiated vs IdP-initiatedwhere the flow starts

The difference is just where the user begins. SP-initiated is the common, safer path; IdP-initiated skips the SP's request and is a frequent source of the dreaded "unsolicited response" error.

1. 1SP-initiated. User hits the app, the SP redirects to the IdP with an AuthnRequest, the IdP authenticates them, then POSTs a signed assertion back to the SP's ACS URL.
2. 2IdP-initiated. User clicks a tile in the Okta dashboard, the IdP POSTs an assertion to the SP cold - no prior AuthnRequest. Apps that require a matching request will reject it as unsolicited.

Inside the assertionthe fields you'll be asked to read

Signing vs encryption

Signing proves the assertion came from the IdP and wasn't altered; it's mandatory. Encryption hides the assertion contents from the browser that relays it and is optional, used when attributes are sensitive. Most break-fix work is signature-related, because certificates expire and rotate.

The troubleshooting treesay this structure out loud

1. 1Isolate scope. One user or everyone? One user points at attributes or account state; everyone points at config or a rotated cert.
2. 2Capture the SAMLAn enterprise standard that powers single sign-on. trace. Use the browser SAML-tracer extension or Okta's System Log to grab the raw response, then base64-decode the assertion.
3. 3Check the signature and cert. Did the IdP signing certificate rotate without updating the SP? This is the single most common total outage.
4. 4Check Audience and ACS URL. The Audience must equal the SP's entity ID and the response must land on the registered ACS URL.
5. 5Check timestamps. NotBefore/NotOnOrAfter plus server clock skew - a few minutes of drift kills assertions.
6. 6Check the NameID and attributes. Right format? Right value? Are group claims arriving with the names the SP expects?

The fastest way to lose credibility in an identity screen is to say "we'll use OAuth to log the user in." OAuth doesn't log anyone in. Naming that boundary cleanly is the first thing a sharp interviewer listens for.

OAuth 2.0 is an authorization framework - it answers "can this client call this API on the user's behalf" and hands back an access token. OIDCOpenID Connect. A modern standard that powers single sign-on, built on OAuth. is a thin identity layer on top that adds an ID token, a signed JWT stating who the user is. You ask OAuth for permission to act; you ask OIDC who just authenticated.

The grants worth memorizingpick by who holds the secret

Why PKCE and why not implicit

A public client (a desktop app, a SPA) can't keep a secret - anything shipped to a user's machine can be extracted. PKCE solves this without a secret: the client generates a random code_verifier, sends its SHA-256 hash up front, then proves possession when it redeems the code. An intercepted authorization code is worthless without the verifier.

code_verifier  = random(64)                  // kept in memory on the client
code_challenge = base64url(sha256(code_verifier))

// 1. authorize: ?code_challenge=...&code_challenge_method=S256
// 2. user logs in -> redirect back with ?code=...
// 3. token:     POST { code, code_verifier }   // server recomputes the hash

Implicit returned tokens directly in the redirect URL fragment, where they leaked into history, referrer headers and logs. It's deprecated and PKCE replaced it for browser clients. Naming that when asked "why not implicit" signals you track the current spec.

Three token types, three jobsknow where each is validated

The pattern you'll actually buildautomating the SaaS stack

Most of your OAuth work as an IT engineer is service-to-service: a script that provisions a Slack user, pulls Okta logs or manages Google Workspace groups. That's client credentials (or a Google service account with domain-wide delegation), not interactive login.

Security gotchas to name unprompted

• Exact-match redirect URIs. Wildcards turn PKCE into theater - the code gets delivered to the attacker's URL.
• Least-privilege scopes. A token that reads one group is a smaller breach than one that admins the tenant. Scope is your blast-radius dial.
• Secret rotation. Client secrets and API tokens live in a secrets manager, rotate on a schedule and never sit in a repo or a Slack message.
• Token storage. Refresh tokens are bearer credentials - anyone who has one is the user until it's revoked.

SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. is the difference between offboarding that happens in seconds and offboarding that sits in a ticket queue for three days while a departed employee still has live access. The deprovisioning half is where IT security actually lives.

SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. 2.0 is a standardized REST schema for synchronizing users and groups between an IdP and downstream apps. The IdP is the source; it pushes create, update and deactivate events to each app's SCIM endpoint as identities change. It's the engine behind "auto-provisioning" in Okta and Entra.

Attribute and group mappingwhere it silently goes wrong

SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. only works if the IdP attributes map cleanly onto the app's expected schema. A mismatch doesn't always error loudly - it provisions a user with a blank department or no role and you find out when someone can't see the channel they need.

1. 1Map core attributes. userName, emails, name.givenName/familyName and any app-specific custom attributes the SP requires.
2. 2Decide group strategy. Either push IdP groups as SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. groups or map IdP groups to app roles. Pick one model per app and document it.
3. 3Test with one user. Provision a test identity, verify it lands with the right role and attributes, then move it to a different group and confirm the change propagates.
4. 4Confirm deactivation. The single most important test: deactivate the test user in the IdP and verify access is actually gone in the app, not just hidden.

Drift and reconciliationthe reality of distributed state

Apps drift. An admin grants access directly in Slack, a SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. webhook silently fails or an app was provisioned before SCIM existed. Now the app's state diverges from the IdP, which is exactly the gap an auditor or attacker finds.

When SCIM isn't availableown the gap with code

Plenty of apps in a real stack have no SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. support or only support it on a tier the company doesn't pay for. This is where the engineer-not-help-desk mindset shows: you don't shrug and offboard by hand, you write the provisioning yourself.

def deprovision(email: str) -> None:
    for app in NO_SCIM_APPS:
        user = app.find_user(email)
        if user is None:          # already gone -> safe to re-run
            log.info("%s absent in %s", email, app.name)
            continue
        app.deactivate(user.id)   # disable, don't delete
        log.info("deactivated %s in %s", email, app.name)

"Design an automated JML pipeline" is the canonical systems-design prompt for this role. The strong answer starts from one principle: the HRIS is the source of truth and identity flows downhill from it without a human in the loop.

JML - Joiner, Mover, Leaver - is the identity lifecycle. The HRIS (Workday, Rippling, BambooHR) records the human-resources fact; everything else reacts. Identity events flow HRIS → IdP → SaaS apps over SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. and API, so onboarding and offboarding are instant, consistent and audited.

Joinerinstant day-one experience

1. 1Trigger. HRIS marks a new hire active on the start date (or a few days ahead for pre-provisioning).
2. 2Create identity. IdP creates the account, sets the username convention and enrolls MFA.
3. 3Assign group-based access. Role + department drive group membership; groups auto-grant the right SaaS apps via SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. - no manual app-by-app grants.
4. 4Provision the device. MDM zero-touch enrollment ships a configured laptop tied to the new identity.
5. 5Day-one experience. Welcome flow, accounts ready, no "file a ticket to get Slack" friction.

Moverthe case people forget

A role or department change should recalculate access automatically - add what the new role needs, remove what the old one granted. The failure mode is access accretion: people collect permissions as they move and never lose the old ones, which is how you end up with a marketing manager who can still touch the finance system.

Leaversame-second, fully audited

1. 1Trigger. HRIS marks termination; for involuntary exits, support an immediate manual override that fires now.
2. 2Deactivate identity. Disable the IdP account, which cascades SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. deactivation to every connected app.
3. 3Catch the non-SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. apps. Script-based deprovision for anything without SCIM, so there's no manual gap.
4. 4Handle the device. MDM lock or remote wipe and reclaim the hardware.
5. 5Write the audit record. Log what was revoked, when and by what trigger - this is your offboarding evidence for SOC 2.

Engineering the pipeline wellwhat makes it production-grade

• Idempotent. Re-running a leaver event on an already-offboarded user is a no-op, never an error - events get redelivered.
• Retried with backoff. A downstream API being down can't drop a deprovision; queue it, retry and alert if it stays stuck.
• Audited end-to-end. Every action emits a record: who, what, when, triggered by which HRIS event.
• Alerted on failure. A silent deprovision failure is the worst outcome - page on it.
• Version-controlled. The mappings and workflow logic live in Git, reviewed like any other code.

The goal isn't to lock everything down - it's to make the right access automatic and the wrong access impossible to keep. Standing privilege is debt; you design so it pays itself off.

Three models do the heavy lifting and a real environment combines them. The interview test is whether you can say when each fits rather than reciting definitions.

These combine: a dynamic group built from an ABAC-style query ("department = Engineering AND employment = full-time") becomes the RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. unit that grants a bundle of apps. Attributes feed groups, groups grant roles.

Group-based access is the unit of provisioningno manual one-offs

Access should derive from role and attributes, never from a manual "add Jordan to this app" request. When access is a property of who you are, JML automation can grant and revoke it deterministically. One-off grants are exactly the entries that survive offboarding and show up in an audit.

Least privilege and just-in-time elevationshrink standing access

For sensitive systems - production, the IdP admin console, finance - the right pattern is request-and-expire rather than a permanent grant. The person asks for elevation, it's approved (or auto-approved by policy) and it evaporates on a timer. The audit log then shows exactly who had power and for how long.

Access reviews and recertificationthe SOC 2 tie-in

• Recurring, not annual-panic. Quarterly recertification where owners attest that each person still needs each grant.
• Partly automated. Generate the review from live IdP/app state; the human only judges the deltas, not the whole list by hand.
• Evidence-producing. Each review leaves a timestamped record auditors accept as proof of the control operating.
• Closed-loop. Revocations from the review flow back through the same group mechanism that grants access.

The IdP is the single most security-critical system you'll run - own it and you own access to everything. Interviewers want to hear that you treat it with the operational discipline that blast radiusHow much breaks if a change goes wrong; the scope of potential damage. deserves.

App integration patternscatalog vs custom

Most integrations come from the IdP's app catalog (OIN in Okta, the gallery in Entra), which ships pre-built SAMLAn enterprise standard that powers single sign-on./OIDCOpenID Connect. A modern standard that powers single sign-on, built on OAuth. and SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. config for known apps. For homegrown or unlisted apps, you create a custom SAML or OIDC app and wire metadata, ACS URL, attribute statements and provisioning by hand.

MFA and passwordlessphishing-resistant by default

Not all factors are equal. SMS and TOTP are phishable; FIDO2/passkeys are phishing-resistant because the credential is bound to the origin and never leaves the device. For a security-forward company, the target is phishing-resistant MFA as the baseline, with weaker factors phased out.

Risk-based & conditional accesscontext gates the login

Conditional access lets you require more (or block) based on signals: is the device managed and compliant, is the network expected, is the sign-in behavior anomalous. This is the IdP side of zero-trust - access is granted on posture, not just a correct password.

Admin hygieneprotect the thing that protects everything

• Scoped admin roles. No one carries super-admin for daily work; delegate the narrowest role that does the job.
• API tokens as service apps. Prefer scoped OAuth service apps over long-lived super-admin API tokens and rotate them.
• Break-glass accounts. A small number of emergency accounts, MFA-exempt only by deliberate design, vaulted, alerted on every use.
• Logging everywhere. Stream the System Log to the SIEM; admin actions and sign-in events are your forensic record and SOC 2 evidence.

Okta vs Entrahave a view, hold it lightly