oauth

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.

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 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.

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.

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.

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.

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 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.

URL validation is where string checks fail most visibly. The scored answer parses, resolves and allowlists, then tests the classic bypasses.

Any app can claim myapp://. That single fact breaks OAuth redirects, password-reset links and payment flows that trust a custom scheme. The fix is a link the operating system verifies against your domain.

Anything in the app binary belongs to whoever downloads it. The strong answer stops trying to hide a client secret and builds on user tokens, PKCE, device-bound keys and server-side limits.

A vendor breach becomes yours through the access you gave them. The scored answer inventories that access, rotates and revokes it, looks for misuse, and works out what data was exposed.

Review an integration by tracing model input, process access and credential recipients. Then name the component that refuses each unauthorized action.

A2A standardises how agents find and talk to each other. It does not decide who to trust, what to share or what to believe, and those three decisions are the answer.