The plugin asks, the browser approves, and nobody handles an API key
Connecting the plugin meant visiting the book page, creating an API key and pasting it back; the device authorization grant inverts that, so the plugin prints a short code and collects the credential itself.
The trip to the browser to fetch a credential is the step people do not complete, and it is the step where a bookkeeper has to understand what an API key is. RFC 8628 turns it around: the plugin asks first and prints a short code, the customer approves in a browser they are already signed in to, and the plugin collects the credential. The user never handles one.
What the grant hands back is still the same per-book API key the book page issues, not an access token, and that split is the whole design decision. The plugin sends a key per request so that revocation actually takes effect, so a fleet re-secret does not break every client, and so the metered mint is not hit once per tool call. Issuing access and refresh tokens would reintroduce the cached-credential problem and put “revoke” back to meaning “some time within the hour”. OAuth for enrolment; an API key as the credential.
The two codes have opposite jobs. The device code is a bearer credential: 32 random bytes, never displayed, stored only as a hash. The user code is a pointer a human retypes, and it authorises nothing on its own — approving grants access to the holder of the matching device code, not to whoever typed it. Its alphabet drops the confusable characters and every vowel, so no code can spell a word and therefore none can spell an offensive one. A replayed device code is answered exactly as an unknown one, so a stranger holding a stolen code cannot learn that it was ever real.