How can a device-code lure put a working token on an operator's device when the user's FIDO2 key was presented correctly?

## Why this lure is interesting Most credential phishing dies the moment an origin-bound authenticator is in play. A FIDO2 or WebAuthn credential produces an assertion that is cryptographically scoped to the relying party's origin, so a look-alike site cannot obtain one that the real site will accept, and a proxy in the middle cannot relay it. That is genuine phishing resistance, and it is why estates invest in it. A device-code lure does not attack that property. It leaves it entirely intact and attacks a different decision. ## The three parties The device authorization flow exists so that a device with no keyboard or no browser — a television, a scanner on a warehouse floor, a terminal — can be signed in using a second device that does have one. Three parties are involved: - **The client**, which starts the flow and waits for a token. - **The user's browser**, which visits the genuine verification page and enters a short code. - **The identity provider**, which ties the two together and, once the user approves, hands the token to the client. The critical property is the last one: **the token goes to the party that started the flow, not to the party that authenticated.** In legitimate use those are the same person on two devices. In the lure they are two different people. ## What the operator does The operator starts the flow from their own machine and immediately receives a short user code and the genuine verification address. They now have a few minutes before the code expires — which is why this lure is almost always delivered live, over a phone call, a chat message, or a meeting invite, rather than as a slow email campaign. A support pretext fits the time pressure naturally: *I need you to approve the diagnostic session, go to this page and type this code.* The victim does exactly what they were asked, and every observable thing about it is correct. The address bar shows the real identity provider. The certificate is the real one. The hardware key is presented to the real origin and produces a valid assertion. There is no cloned page anywhere in the story, so none of the classic advice — check the domain, look for the padlock, do not trust the link — has anything to bite on. Then the operator's polling client collects the token. ## Authentication versus authorization, made concrete The honest way to describe the deception is that the victim answered the question they were asked correctly, and the question they were asked was the wrong one. The identity platform asked *are you who you say you are?* The victim answered truthfully. Nobody clearly asked *is this device, which you cannot see, yours?* — and that is the question whose answer the operator needed. This is why "we deployed phishing-resistant authentication, so we cannot be phished" is a wrong answer that competent engineers still give. Origin binding removes credential relay. It does not remove a user's ability to authorize something on purpose. ## What the operator ends up with A token set scoped to whatever the flow requested, held on the operator's device, typically with a refresh token behind it. That is durable in a way a keystroke-logged password is not, and it is why this converts well: the operator holds an access artefact that no further contact with the victim is needed to keep alive. ## Recognising the shape rather than the story The generalisable pattern is worth stating in an interview: **any flow that separates the party that authenticates from the party that receives the result is socially engineerable, regardless of the strength of the authentication.** Approval prompts on a phone, cross-device sign-in, and delegated approvals all share that shape. Strength of factor is orthogonal to whether the human understands what the approval is *for*. ## Controls that actually bite The control class that removes the technique is not a stronger factor — the strongest factor available was already used. It is constraining where the flow may be used at all: permitting the device authorization flow only for the device classes that genuinely need it, and only from expected network positions, so an operator's arbitrary client cannot start one against your tenant. Everything else, including user education, only lowers the hit rate. ## Common wrong answers - "The key must have been cloned or the assertion replayed." Nothing was cloned; the assertion was genuine and single-use. - "They must have proxied the sign-in page." There was no page to proxy — the victim used the real one. - "Shorter code lifetimes fix it." The lure is already live and conversational; minutes are enough. - "Number matching or push-approval hardening solves it." That addresses fatigue-style approval spam, which is a different technique with a different weak point.