Consent and Device Code

## Two objects that get called the same thing When people say "the account was compromised", they usually mean one of two very different things. **A credential** is something the user proves themselves with: a password, a one-time code, a hardware authenticator. It is consumed at sign-in. Change it and the old one stops working. **A consent grant** is a record in the directory saying that a *registered application* may act on a user's behalf, limited to a named set of scopes such as reading mail. The user creates it by pressing Accept on a consent request. Nothing about it belongs to the user afterwards; it belongs to the application. The entire question turns on that second sentence. The attacker who ran a consent lure never obtained a credential, so there is no credential to invalidate. ## What the application actually holds A grant that includes offline access lets the application hold a **refresh token**. A refresh token is not a session and not a password: it is a bearer artefact the application presents directly to the token endpoint to obtain a fresh, short-lived access token. That exchange is machine-to-machine. There is no sign-in page, no password prompt, no second-factor challenge, and no interactive session for anyone to look at. So the loop the operator runs is: 1. Present the refresh token bound to the grant. 2. Receive a new access token, typically valid for an hour or so. 3. Call the mail API with it. 4. Repeat before the access token expires. Nothing in that loop reads the user's password, so nothing in that loop notices that the password changed. The same reasoning covers the second factor: a factor is presented at authentication, and no authentication is happening. ## How the grant got there The usual route is a lure that does not look like a phishing page at all, because it isn't one. The user receives a link to the *genuine* identity provider's consent screen, for an application the operator registered — often with a plausible name suggesting a document viewer, a scanner, or an internal tool. The user authenticates correctly, to the correct site, with the correct factor, and then approves the request. Every step of the authentication was legitimate. The deception is in the authorization, not the login. That is why the classification matters so much in practice: the story contains no stolen password, so the reflex response of "reset it" removes nothing. ## What actually ends it The grant is its own object, so the remedy is aimed at the grant and at the application identity behind it — the tokens issued against it stop being redeemable only when the authorization itself is gone. The important part for an interview is knowing *which* object you must act on and why the credential is the wrong one; the operational procedure for doing so sits with whoever owns access removal in your organisation. ## Getting the direction of the claim right A grant record proves that an authorization was recorded for a principal. It does not prove the user understood the request, and it does not prove a human was even at the keyboard when the underlying access token was last used. Conversely, a successful password rotation proves the credential changed; it proves nothing whatsoever about outstanding authorizations. ## Framework vocabulary In MITRE ATT&CK the theft of the token or grant is **Steal Application Access Token (`T1528`)** and reusing it in place of a normal logon is **Use Alternate Authentication Material: Application Access Token (`T1550.001`)**. Naming them this way is useful because it forces the distinction the question is about: the technique is described as *alternate* authentication material precisely because it substitutes for the credential path rather than travelling down it. ## The common wrong answers - "They must still have the password, or they couldn't read the mail." They never needed one. - "MFA would have stopped this." The factor is presented correctly, by the right person, at the right site, in most versions of this lure. - "The token will expire soon anyway." The *access* token will; the refresh token keeps producing new ones for as long as the grant stands. - "It is a session hijack." A session belongs to a browser and a user; this belongs to an application identity and outlives every browser involved.