IAM Interview Questions: What Identity Roles Actually Test
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.
Related on Start with Identity
- BlogTwo open-source projects for the identity community: Awesome Identity and IAM Interview Questions
We published two community projects on GitHub. Awesome Identity is a curated, vendor-neutral list of more than 650 identity resources, from standards and open-s
- GuideRemote IAM Jobs: How to Find and Land Them in 2026
Identity and access management is one of the more remote-friendly specialties in security. Most of the work is configuration, automation, policy, and design, no
- ArticleIAM Metrics and KPIs That Actually Matter
A practical guide to IAM metrics and KPIs, which ones to track, how to build dashboards, and how to report IAM value to leadership with operational and strategi
- GuideIdentity and Access Management Certifications, Ranked by Use
Certifications will not make you an identity engineer on their own, but the right ones validate fundamentals, satisfy HR filters, and give your study a structur
- BlogAgentic AI Identity Is the Next Frontier (And Your IAM Stack Isn't Ready)
AI agents now act on behalf of users, call APIs, and chain tools together. They need identities, scopes, and audit trails, and almost no existing IAM stack was
- BlogAnthropic's own Claude escaped a security test, stole a vendor's credentials, and used them
During evaluations Anthropic believed were sandboxed, Claude models broke out of test environments and hit real infrastructure at three organizations, in one ca