Identity & Access interview questions
Identity & Access questions a Cybersecurity can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What is the difference between authentication and authorization?
The strongest answer: Authentication is who you are; authorization is what you may do — a valid login can still be forbidden on a path
Why it works: Exactly. Who versus what. Mixing them is how IDOR and “but I logged in” bugs ship.
- Authn = who.
- Authz = what.
- Login is not permission.
- MFA does not skip authz.
A user says MFA is “annoying” for email. What do you say?
The strongest answer: MFA is for when the password leaks — annoyance is real, so we pick a usable factor, we do not turn it off for convenience on a mailbox that resets everything else
Why it works: Exactly. Usability is a design problem. Off is how one leak becomes every account.
- Keep MFA on high-value mail.
- Design for usable factors.
- SMS is phishable.
- MFA ≠ password reuse is fine.
A service account can drop every table “in case we need it.” What do you do?
The strongest answer: Cut it to the verbs it needs today — break-glass is a separate, audited path, not a default god role
Why it works: Exactly. Default is least. Break-glass is a ritual with a log, not a connection string.
- Least privilege by default.
- Break-glass is separate and logged.
- Do not give god roles to clients.
- Wide roles enlarge incidents.
Why do security teams push every application onto single sign-on, beyond “one password is convenient”?
The strongest answer: One identity to enforce MFA and policy on, one place that shows who has access, and one switch at offboarding — local application accounts are the ones nobody remembers to disable
Why it works: Right — joiner, mover and leaver in one place, and one point where stronger authentication actually lands.
- SSO centralises enforcement.
- MFA and policy in one place.
- One list of who has access.
- One switch on the leaving day.
An engineer leaves. What do you rotate besides their SSO?
The strongest answer: Personal access tokens, cloud keys, laptop wipe, and shared vaults they could see — SSO off is necessary and not sufficient
Why it works: Exactly. Identity is a graph. Trusted is not a revocation plan. Keeping keys is a red flag.
- Revoke SSO and tokens.
- Rotate shared secrets they saw.
- Wipe the laptop.
- Do not keep their keys “just in case.”
A user lost their authenticator. What is a safe recovery?
The strongest answer: A path as strong as the account — identity proof, one-time codes you issued, or a break-glass you log — not “tell support your birthday”
Why it works: Exactly. Recovery is the second lock. Weak recovery deletes MFA.
- Recovery as strong as MFA.
- Issued one-time codes, stored hashed.
- Log break-glass.
- Do not trust a birthday or a vibe.
In an OIDC login, what is the difference between the ID token and the access token, and which does your API check?
The strongest answer: The ID token tells the client who signed in; the access token is what the client presents to an API. The API validates the access token — signature, issuer, audience and expiry — and does not accept an ID token as authorisation
Why it works: Exactly — audience and issuer are the checks people skip, and skipping them is how a token minted for another application gets accepted.
- ID token: who signed in.
- Access token: what the API takes.
- Verify signature, issuer, audience, expiry.
- Never trust an unverified claim.
Five services each invent “is admin.” What do you do?
The strongest answer: One identity and one authorization language — roles or relations you can audit — I do not add a sixth dialect
Why it works: Exactly. Authorization is a product. Dialects are how one service forgets. JWTs still need a server check and a life.
- One authz language.
- Audit who is admin.
- Still check on the server.
- No sixth dialect.
When do you push passkeys / FIDO over SMS OTP?
The strongest answer: On admins, finance, and anyone a phish would pay for — SMS stays a fallback you watch, not the only factor for a god role
Why it works: Exactly. Phishing-resistant where the blast radius is large. Recovery still matters. SMS is a known downgrade.
- FIDO for high-blast roles.
- SMS is a watched fallback.
- Plan recovery.
- Do not leave admins on SMS only.
What does honest break-glass look like?
The strongest answer: A separate path, MFA, a ticket or page, a time limit, and a review — not a shared root we pretend we will not use
Why it works: Exactly. You will need it. Design it. Sticky notes and permanent gods are the failure modes.
- Separate, MFA, time-boxed.
- Ticket and review.
- No sticky-note root.
- A path beats a shadow.
An integration asks for mail.readwrite to “show a name.” What do you do?
The strongest answer: Refuse the extra scope, or split the app — least privilege on OAuth is the same as on a service account
Why it works: Exactly. Scope is authorization. Hiding consent and repo tokens are red flags.
- Least scope for the job.
- Split apps if you must.
- Do not hide consent.
- Do not store refresh tokens in git.
The network perimeter dissolved. What do you put in the first sentence of the identity strategy?
The strongest answer: Every request names a person or a workload, with least privilege and a life — the VPN is not the remaining plan
Why it works: Exactly. Identity is the perimeter you can still name. Thicker VPNs and IP trust are nostalgia.
- Person or workload on every request.
- Least privilege and expiry.
- VPN is not the plan.
- Do not disable SSO.
Access rules across the platform now read “this role, unless the record is in their region, outside the freeze window, and they are not the approver”.
How do you decide between keeping roles and moving to attribute-based rules?
The strongest answer: When the exceptions are about who the user is and what the record is, roles are being encoded into names — I move the decision into a policy over attributes, keep the role as one attribute, and require that every decision be explainable and testable
Why it works: Right — explainable and testable is the part that stops a policy engine from becoming a new black box.
- Roles name people; attributes name context.
- Watch for role explosion.
- Make every decision explainable.
- Test policies like code.
MFA coverage is 70% and the last 30% are “exceptions.” What do you do?
The strongest answer: Name the exception classes, time-box them, and move admins first — 70% with god-role holes is not coverage
Why it works: Exactly. Coverage without the god roles is a story you should not tell. Hiding the 30% is a red flag.
- Admins first.
- Time-box the rest.
- Do not call 70% done.
- Do not hide the hole.