OAuth, Identity & Access Control Interview Questions

Ten seconds of definition, then the part that scores: why most access bugs happen to users who logged in perfectly.

Drawing the arrows is half the answer. The other half is pinning an attack to every parameter: state, redirect URI, code, verifier, audience.

Every candidate knows OIDC is 'OAuth plus identity'. Fewer can say which token goes where, and what breaks when they swap.

'JWTs are stateless and scale' is half an answer. The other half is what happens the day you need to log someone out right now.

Documents are shared with people, folders, teams and links. Roles alone collapse under that, and the interviewer wants to see you notice when.

The token tells you which algorithm to use and where to find the key. Believing it is how signature checks become no checks.

Both are 'something you have'. One can be typed into a fake page in real time; the other checks which page is asking.

A service account is the easy answer and the wrong one. The interviewer wants both identities visible in every call, scoped to the task, and revocable by the user.

A 1988 bug report that describes most agent incidents. The answer that scores turns it into a design rule: authority travels with the request.

Static API keys in environment variables are the most common credential leak there is. The answer is platform-issued, short-lived, attested identity.

A valid token is not valid everywhere. The scored answer explains audience binding, why forwarding a caller's token downstream breaks it, and what MCP's authorisation rules require instead.

Most OAuth breaches come from a few well-known mistakes. The scored answer explains each attack and the specific rule that stops it, as consolidated in the 2025 OAuth security best current practice.

Two enterprise workhorses with very different designs. The scored answer explains each flow, where the trust lives, and the attacks that follow from it.

Escalation rarely needs an admin permission, just a permission that leads to one. The scored answer names the common paths, finds them as a graph, and removes the edges that matter.

A bearer token works for whoever holds it. The scored answer explains how binding a token to a key changes that, the two standard ways to do it, and the cost.

An MCP server is an API that a model drives. The scored answer treats it as an OAuth resource server, authorises every tool call against the user, and keeps upstream credentials out of the client's hands.

Machine identities outnumber people in most organisations and are reviewed far less. The scored answer finds them, gives each an owner, shrinks their power and lifetime, and watches how they are used.

Zero trust is a set of engineering decisions, not a product. The scored answer names them, shows how they replace network location as a trust signal, and admits where they are hard.

Scattered permission checks drift apart until one is wrong. The scored answer weighs a central decision service against latency, availability and consistency, and keeps enforcement close to the data.

The attacker never needs the password: the victim grants their app access. The scored answer explains why MFA does not help, then controls consent at the tenant and watches the grants.

A confirmation click proves someone was present; step-up proves it was the user, recently. The scored answer decides which actions need it and wires it through tokens so the agent cannot fake it.

Stolen session tokens skip MFA entirely, which is why infostealers sell them. The scored answer looks for the same session appearing in two places, binds what it can, and makes revocation fast.

API keys identify a caller; OAuth delegates a user's authority. The scored answer picks by who is acting and on whose behalf, and makes API keys as safe as they can be when used.

Validate tenant selection, enforce resource permissions, and test the boundaries that signed context and row-level security do not cover automatically. Follow one request through retrieval, caches and a queued job.

Trace a withdrawn grant through cached decisions, exchanged tokens and queued work. Define when new actions are denied and account for effects already dispatched.

The signature verifies, and the application reads a different element than the one that was signed. Most SAML bugs are some version of that sentence.

Each token verifies against some trusted key. The bug is that the key belonged to a different issuer than the one the token claims, or the user ID means something different there.

The user never types anything an attacker could replay, and the browser, not the user, decides which site is asking. Those two facts are the whole phishing story; the ceremony is how they are enforced.

Moving passwords from config files into a secret manager helps only if the application's way of logging in to the secret manager is not itself a password in a config file.

Deleting the commit feels like fixing the leak. It isn't: the secret was public the moment it was pushed, and only revoking it ends the exposure.

Liveness checks were built to catch a photo held up to a camera. Deepfakes often never go near the camera at all.

Phishing-resistant MFA is only as strong as the process that replaces it when someone loses their phone. Attackers have noticed, and so do interviewers.

A user agent string is a claim anyone can type. A signature over the request is a claim only the key holder can make. The interesting part is what that signature still does not tell the site.

The victim types a code on the real Microsoft sign-in page, passes MFA, and hands the attacker their tokens. The scored answer explains why nothing looks wrong and which policy actually stops it.

Nobody broke into the CRM. An integration that customers had approved years ago simply asked for the data, with valid tokens. The scored answer treats third-party grants as identities you own.

A seasonal exporter and an overprivileged service share an unused-access finding. Decide what evidence supports removal without preserving every broad grant indefinitely.