Skip to content
Start with Identity
Career · Intermediate

IAM Interview Questions: What Identity Roles Actually Test

By SWI Community Team · Updated 2026-11-05 · 14 min

Identity interviews probe whether you understand protocols as mechanisms, can reason about trade-offs, and know how identity fails in practice. This page gives real technical questions with model answers: the level of detail a strong mid-level or senior candidate gives. Answer in your own words; interviewers follow up on whatever you say, so only claim what you can defend.

Practice with the full question bank. For hundreds more questions with model-answer notes, organized by topic and tagged Junior, Mid, or Senior, use our free, open-source IAM Interview Questions repository on GitHub. Contributions welcome, and every contributor is credited.

Protocols and tokens

Q: What is the difference between authentication and authorization, and why is an OAuth access token not proof of login? Authentication establishes who the user is; authorization decides what a caller may do. An OAuth access token is issued to a client for an API (its audience is the resource server), and it says nothing reliable about whether or when the user authenticated to your application. To log a user in, use OpenID Connect and validate the ID token, whose audience is your client. See authentication vs authorization.

Q: Walk me through the authorization code flow with PKCE. The client generates a random code_verifier, hashes it with SHA-256 into a code_challenge, and redirects the browser to the authorization endpoint with the challenge, state, and requested scopes. The user authenticates; the server redirects back with a short-lived code. The client exchanges the code at the token endpoint and includes the original verifier. The server hashes the verifier and compares it with the stored challenge, so an attacker who intercepted the code cannot redeem it. RFC 9700 makes PKCE mandatory for public clients and recommended for confidential ones. See PKCE.

Q: Why is the implicit flow discouraged? It returns access tokens in the redirect URL fragment, where they can leak through browser history, referrer headers, and injected scripts, and there is no way to bind the token to the client that started the flow. RFC 9700 says clients should not use it and should use the authorization code flow instead. The OAuth 2.1 draft drops it entirely. See OAuth 2.1.

Q: How do you validate a JWT? Parse the header, but do not trust its alg: verify against an allow-list you configure, as RFC 8725 requires, which defeats none and the RS256-to-HS256 key confusion attack. Fetch the issuer's signing key from its JWKS by kid, caching and refreshing on unknown kid to survive rotation. Verify the signature. Then check iss is the expected issuer, aud contains your identifier, exp and nbf are within tolerance, and any nonce matches the one you sent. Only then read claims. Practice with the validate a JWT recipe.

Q: A stolen refresh token is being replayed. What controls exist? Short refresh token lifetimes, rotation (each use returns a new refresh token and invalidates the old one, so replay of an old token is detectable), and sender-constraining with DPoP (RFC 9449) or mTLS so the token is useless without the client's private key. RFC 9700 requires one of rotation or sender-constraining for public clients. See the refresh token abuse technique.

Q: What does a service provider check on a SAML response? That the assertion (not just the outer response) is signed by the IdP's expected certificate; that the signature covers the element you are actually reading, which defends against XML signature wrapping; that AudienceRestriction names your entity ID; that Recipient matches your assertion consumer service URL; that NotOnOrAfter has not passed; and, for SP-initiated flows, that InResponseTo matches a request you sent, which blocks replay of unsolicited assertions. See SAML 2.0 and federation trust abuse.

Q: SAML or OIDC for a new enterprise SaaS app? Support both. Enterprise customers bring SAML IdPs and will not change for you; OIDC is simpler to implement, mobile-friendly, and the base for newer standards. If you can only ship one first, ask what your first ten customers run. See SAML vs OIDC.

Lifecycle and governance

Q: An employee is terminated. Walk through deprovisioning. HR marks the termination in the system of record, the IdP disables the account and revokes sessions and refresh tokens, and SCIM sends active: false to connected applications. Then handle what SCIM does not reach: local accounts, shared credentials, API keys the person created, and owned service accounts, which need a new owner. A strong answer mentions that disabling the IdP account does not end sessions already issued by downstream apps.

Q: How do you stop a re-hire from getting a duplicate account? Match on a stable identifier, typically the HR employee ID sent as externalId, not on email. Reactivate the existing record with a PATCH setting active: true, and do not restore old entitlements automatically; grant them fresh from the new role.

Q: Access reviews are rubber-stamped. How do you fix that? Shrink what reviewers see: remove birthright access from campaigns, highlight only changes and high-risk entitlements, provide usage data, and revoke on non-response rather than approve. Pair reviews with event-driven mover checks, because most excess access comes from mover accumulation. See access certification.

Authentication and attacks

Q: How do attackers get past MFA? Push fatigue (MFA fatigue), adversary-in-the-middle proxies that relay the password and code and steal the session cookie (AiTM phishing), help desk social engineering to reset the factor, and session cookie theft by infostealers after login. Phishing-resistant authenticators (FIDO2 and passkeys) bind the signature to the real origin, which defeats relay; recovery and help desk processes need equally strong verification.

Q: Are synced passkeys good enough? For most workforce and consumer use, yes: they are phishing resistant and much better than passwords plus SMS. NIST SP 800-63B-4 does not allow exportable keys at AAL3, so the highest-assurance cases need device-bound authenticators such as hardware security keys. See synced passkey.

Q: What is Kerberoasting and how do you reduce it? Any domain user can request a service ticket for an account with a service principal name; part of the ticket is encrypted with that account's password hash, so it can be cracked offline. Reduce it with long random passwords or group managed service accounts, AES-only encryption, removing unneeded SPNs, and alerting on unusual ticket request volume. See Kerberoasting.

Design questions

Q: Design SSO and lifecycle for a 5,000-person company. Structure the answer: (1) sources of truth, HR as authoritative for people; (2) one workforce IdP; (3) OIDC or SAML for every app, with an inventory of apps that support neither; (4) SCIM for provisioning, with a plan for non-SCIM apps; (5) MFA policy, phishing-resistant for admins first; (6) conditional access on device and risk; (7) joiner-mover-leaver automation; (8) break-glass accounts; (9) logging into the SIEM; (10) how you measure success. Name the trade-offs you are making as you go.

Q: How would you replace long-lived cloud keys in CI pipelines? Use workload identity federation: the CI platform issues a short-lived OIDC token per job, the cloud provider trusts that issuer with conditions on repository and branch, and the job exchanges it for temporary credentials. No stored secret remains to leak. See secrets in repositories and CI.

Behavioral questions

Expect "tell me about an outage you caused," "a time you said no to a stakeholder," and "a migration that went badly." Pick stories with a specific technical decision, what you measured, and what you changed afterward. For incident stories, walk through a real case from the breach teardowns, such as the Okta 2023 support system breach, and name the control that would have stopped it.

How to prepare

Build something, read the standards, study the techniques, and practice explaining trade-offs out loud. Record yourself answering three questions from this page and listen for definitions where there should be mechanisms. Then drill with the IAM Interview Questions repository, which tags every question by level.

Your next step

Move to how to get an IAM job for the resume and portfolio, and the IAM salary guide to benchmark offers. For the bigger picture, see IAM career paths and how to become an identity engineer.

Frequently asked questions

What questions are asked in an IAM interview?
Expect protocol fundamentals (authentication vs authorization, OAuth vs OIDC, SAML vs OIDC, how to validate a JWT), design and trade-off questions (design SSO and lifecycle for a company, choose an access model, roll out MFA), and security reasoning (how attackers defeat MFA, walk through a real breach). Senior interviews add architecture and system-design scenarios.
How do I prepare for an identity and access management interview?
Build a working demo so you can speak from experience, learn the core protocols cold, study how identity breaches happen, and practice explaining trade-offs out loud. Then drill with a structured question bank. Our free open-source IAM interview questions repository has hundreds of questions with model-answer notes, organized by topic and difficulty.
What is the best way to answer an IAM system design question?
Clarify requirements first, identify the actors and identities, choose protocols (OIDC or SAML for SSO, SCIM for provisioning), design the joiner-mover-leaver lifecycle, plan authorization, then address security, failure modes, scale, and operations. Interviewers care about structured reasoning more than a single correct answer.
How technical are IAM interviews?
Engineering roles are quite technical: expect to trace an OAuth flow, validate tokens, and debug federation. Governance and analyst roles lean more on lifecycle, access reviews, and compliance. All levels test whether you understand the why behind identity decisions, not just terminology.
What is the most common mistake candidates make?
Answering with definitions instead of mechanisms. Saying PKCE is a security extension is a definition; explaining that the client sends a hash of a secret at the start and the secret itself at the token step, so a stolen authorization code is useless, is a mechanism. Interviewers probe until they find which one you have.
Last reviewed By SWI Community TeamSuggest a correctionHow we research