IAM Interview Questions in 2026: OAuth, OIDC, SAML and the Identity Control Plane

Identity became the control plane. Once the perimeter dissolved into SaaS, cloud accounts and contractor laptops, what actually decides whether an attacker gets in is a token, a session and a policy. So IAM interviews have shifted: less about which vendor console you have clicked through, more about whether you can design an access model, reason about token lifetimes, and say out loud why the logout button in most applications does not really log anyone out. This guide covers what comes up for IAM engineer seats, what the interviewer is listening for, and what to ask back.

The design scenarios (the core of the interview)

• "Design SSO for a new internal application. Walk me through it." They want a sequence, not a product name: pick the protocol and justify it (OIDC for anything modern, SAML if the app only speaks SAML), separate what the identity provider asserts from what the app decides locally, define the claims and who owns them, then handle the unglamorous half - group and role mapping, deprovisioning, and what happens when the IdP is down. Stopping at "configure the connection" tells them you have never run one in production.
• "A user is terminated at 4pm. What has to happen, and what usually doesn't?" This is the joiner-mover-leaver question and it separates people fast. Directory disable is the easy part. The strong answer covers session and refresh-token revocation, SCIM deprovisioning to downstream SaaS, personal access tokens and API keys the user created, OAuth grants they consented to, shared credentials they knew, and the apps outside SCIM that only a human can turn off. "Leaver is where most orgs bleed" is a sentence worth being able to defend with specifics.
• "How would you give engineers production access without giving them standing production access?" Just-in-time access: request with a reason, approval or automatic policy grant, scoped role, short expiry, full audit trail. The follow-up is always about break-glass - one documented emergency path, credentials in a vault, alerting on every use, and a review afterwards. If you have measured standing privilege before and after, say so.
• "Our access model has 400 roles for 900 people. What do you do?" Role explosion. Mine actual entitlement usage rather than redesigning from an org chart, collapse to a few birthright roles plus attribute-based rules for the variable part, and treat exceptions as data to review rather than roles to create. Naming the trade-off honestly - RBAC is auditable but rigid, ABAC is expressive but hard to reason about and test - is the senior signal.
• "How would you inventory and secure non-human identities?" The fastest-growing part of the job: service accounts, CI runners, workload identities, bot users and the secrets behind them. Strong answers move toward short-lived federated workload identity (OIDC trust between the workload and the cloud) instead of long-lived static keys, plus discovery, ownership, rotation and revocation. Anyone who has cleaned up secrets sprawl has a story here - tell it. Live cloud-side work like this shows up on our cloud security jobs board →.

Knowledge questions

• "What is the difference between OAuth 2.0, OIDC and SAML?" The single most common screening question, and the one candidates most often fumble. OAuth 2.0 is an authorization framework - it delegates access to a resource, it does not tell you who the user is. OIDC is the thin identity layer on top of OAuth that adds authentication and an ID token. SAML is the older XML-based federation standard that does authentication and attribute exchange, still everywhere in enterprise apps. Saying "we use OAuth to log users in" without qualifying it is the trapdoor.
• "Talk to me about token types and lifetimes." ID token (identity, for the client), access token (short-lived, presented to the API), refresh token (longer-lived, exchanged for new access tokens, rotated on use). Why a long-lived access token is a liability: it is a bearer credential, it usually cannot be checked against a revocation list on every call, and a stolen one is valid until it expires. Mention refresh-token rotation with reuse detection and you have answered the follow-up before it is asked.
• "What actually happens when a user logs out?" Usually less than people think. Clearing a local session does not invalidate an issued access token, and federated sign-out has to propagate to every relying party. Real revocation means short access-token lifetimes, refresh-token revocation, a session-invalidation call to the IdP, and back-channel logout wherever the apps support it.
• "Which MFA factors would you deploy and why?" Phishing-resistant first - FIDO2 security keys and passkeys, because the credential is bound to the origin and cannot be relayed. Push notifications are better than nothing but vulnerable to fatigue attacks, so pair them with number matching. SMS is the weakest common factor (SIM swap, interception) and should be a fallback you are actively retiring, not a default.
• "How do you design an access review that is not a rubber stamp?" Review by exception, give reviewers usage data ("has not used this entitlement in 120 days"), make revoke the low-friction default, and measure the revocation rate. A campaign where everything is approved is a campaign nobody read.
• "How do attackers go after identity today?" Session and token theft via infostealers, adversary-in-the-middle phishing that defeats non-bound MFA, consent phishing and malicious OAuth grants, help-desk social engineering to reset MFA, and abuse of over-privileged service accounts. Naming a detection for each - impossible travel is not enough - is what pushes you past the mid-level band.

The judgment questions

• "An executive demands an MFA exemption. What do you do?" Not "no." Find the friction they are actually complaining about and remove it - a passkey on their phone is usually faster than the password they are already typing. If an exemption is genuinely unavoidable, make it narrow, time-boxed, conditional (managed device, known network), logged, monitored and owned by a named risk-accepting executive. They are testing whether you can hold a line without becoming the department of no.
• "A critical legacy application only speaks LDAP and cannot do modern auth. Now what?" Every real environment has one. Options: an authentication proxy or gateway that fronts it with SSO, network and access restriction so only a small population can reach it, strong compensating controls (privileged access management for the accounts it uses, heavier logging), and a dated plan to retire or replace it. The wrong answer is pretending it can be fixed this quarter, and the other wrong answer is shrugging.
• "You have to roll conditional access out to 8,000 people without breaking the company." Report-only mode first, measure who would have been blocked, stage by population starting with IT, exclude a tested break-glass account so a policy cannot lock you out of your own tenant, communicate before enforcing, and watch the help-desk queue as your real telemetry.
• "Tell me about an access decision you got wrong." Have one. Over-permissive group, a deprovisioning gap you found late, a policy that blocked a business-critical workflow. The point is whether the fix became a control - a check in the pipeline, a review, an alert - rather than a one-off correction.

Questions you should ask them

• "Who owns identity here - security, IT, or platform engineering?" (This one answer predicts your budget, your authority and half your frustrations.)
• "What percentage of your applications are behind SSO today, and what is the long tail?" (The gap between the slide and reality lives in that tail.)
• "Do you have an inventory of non-human identities, and who owns them?" (If the answer is a pause, you know what your first year is.)
• "Is IAM run as a service with a roadmap, or as a ticket queue?" (Ticket queues do not produce senior engineers.)
• "How are access reviews handled, and what is the typical revocation rate?" (A number means someone is measuring; no number means it is theater.)

Before you interview

Be able to draw an authentication flow on a whiteboard without notes, and be honest about which parts you have operated versus read about - IAM interviewers ask second-level follow-ups precisely because that is where the difference shows. If you are coming from a platform or infrastructure background the overlap is large, so prepare both sides: our security engineer interview questions → cover the design and code-review half of the loop, and CISSP → is the credential that most often shows up on IAM job descriptions if you are weighing one. When you are ready, the live openings are on our identity and access jobs board → and the adjacent security engineer jobs board → - updated hourly, every listing applying direct to the employer.