Did you know? An agent running on a television, terminal or other device without a convenient browser can ask a person to approve a limited account connection on a different device. The OAuth 2.0 Device Authorization Grant lets a device show a verification address and short user code while it polls for an authorisation decision. The code displayed on the device is not a password and the agent must not treat the first successful network response as proof that the correct person approved the correct scopes.
The practical answer is to use the standards-defined device flow only for the restricted-input clients it was designed to serve, bind the resulting tokens to the intended client and account, respect polling delays and expiry, and verify current authority again before any consequential tool action. Do not let an AI assistant instruct users to approve unfamiliar codes or silently convert an account connection into permission to send emails, change files or make purchases.
This tutorial is about currently implementable authorisation for AI agents and ordinary software clients, not proof that artificial superintelligence exists. It explains the protocol from first principles, checks a numerical polling example, diagnoses code-phishing and wrong-account failures, and works through a changed-context recovery exercise. The standards references are the IETF’s August 2019 RFC 8628 and January 2025 OAuth Security Best Current Practice.
Contents
- The reader problem: granting limited access on a device that cannot handle sign-in well
- Four actors and the boundary between display code and access token
- Initiating the request without inventing scopes or destinations
- Polling is a state machine, not a rapid retry loop
- Worked example: a three-minute authorisation window and a slow-down instruction
- Device-code phishing: when a valid code is still the wrong request
- Scopes, audience and identity after approval
- What to do when a device reboots, a request expires or an account changes
- Auditing the difference between initiated, approved and usable grants
- A reviewable implementation sequence
- Common broken designs and their repairs
- Transfer problem: a school printer and a shared staff terminal
- What device flow does not solve
- Frequently asked questions about device authorisation
- Practical reading routes and primary technical sources
The reader problem: granting limited access on a device that cannot handle sign-in well
A home display may have a remote control with only a few buttons. A command-line agent may run in a remote shell where opening a browser is impractical. A printer might need access to a user’s cloud storage without asking the user to type a long password into its panel. Such devices still need a legitimate, limited route to the account owner’s authorisation. Asking the device to store the person’s password is neither necessary nor a good security default.
The device authorisation flow separates the place where the client runs from the place where the person signs in. The client requests a device-authorisation session from a trusted authorisation server. It obtains a long device code, a human-enterable user code, a verification URI, an expiry and typically a recommended polling interval. It shows instructions while the user visits the official verification page on a more capable phone or computer.
The user authenticates directly to that trusted authorisation service, examines which client and permissions are requested, and either accepts or rejects. The waiting device asks the token endpoint for a result at a bounded interval. Approval may yield access credentials; rejection or expiry must stop the attempt. The person should not have to send their account password, one-time login code or session cookie to the agent.
RFC 8628 explicitly targets clients with limited input or no suitable browser and says it is not a general replacement for browser-based authorisation in capable native smartphone applications. An engineering team should select the right flow for the actual platform. A headless automation service that possesses its own credentials is not automatically a good device-flow candidate. Nor does an LLM deciding that device flow is convenient make it eligible.
Treat this as two distinct trust relationships. The person authorises a particular client for particular access under the authorisation server’s rules. The separate resource service later evaluates whether an issued credential authorises a particular action. A friendly description on the client’s screen does not substitute for either check.
Four actors and the boundary between display code and access token
The resource owner is the human who controls the account or is otherwise entitled to grant access. The OAuth client is the software running on the limited-input device, perhaps an AI assistant controlling an approved integration. The authorisation server authenticates the person and decides whether to grant requested access. The resource server is the API that later accepts properly scoped credentials for real operations.
The device code and user code have different jobs. The device code is a higher-entropy value held by the waiting client and used in polling. The user code is a shorter value designed for the person to type into a trusted verification page. Displaying the user code openly does not make it the same as a password; nevertheless, the verification process must defend against guessing, confusion and phishing. The two codes must not be logged casually or pasted into unrelated chat interfaces.
A verification URI must be the correct endpoint for the user’s actual authorisation provider. Some services also provide a verification URI that includes the code for convenience, but a one-click route still needs to show the actual client and scopes before approval. The person must know which device they are connecting. A code cannot establish ownership of a device by itself if someone else can persuade the user to approve it.
The access token returned after approval is a bearer credential unless another supported binding mechanism applies. Whoever possesses a bearer token may be able to use its granted authority. The agent must store such tokens securely, restrict where they are sent and avoid printing them in model context, browser logs or notification previews. User-code verification and safe token storage solve different problems.
A refresh token, when issued, introduces longer-lived authority and additional revocation responsibilities. Some providers may not issue one. Do not assume its presence, lifetime or semantics from the protocol example. Read the provider’s documentation and apply current least-privilege, expiry and revocation controls. The agent identity and delegation guide examines those boundaries beyond login.
Initiating the request without inventing scopes or destinations
Before starting, the client must know its configured authorisation server and client identifier. It should use properly discovered or configured HTTPS endpoints and the scopes actually required for the user’s chosen job. An agent that needs to read a file list should not automatically request mailbox-send or account-management privileges. If a provider’s policy requires additional consent, display that as a clear separate request rather than hiding it in a generic ‘connect’ button.
The RFC 8628 device-authorisation request is made to a device-authorisation endpoint and includes a client identifier and optional scope information. The response contains parameters including device_code, user_code, verification_uri, expires_in and optionally interval or verification_uri_complete. These are protocol fields with defined roles, not arbitrary labels that a conversational model may rename or reinterpret.
Validate the response before showing the user instructions. The endpoint must be the intended trusted service. Time values should be positive and handled on a reliable monotonic elapsed-time basis. Store the session identity and expiry in a protected client-side or backend state record; never mix two concurrent device-flow attempts just because both are visible in the same interface. If the server omits interval, RFC 8628 specifies a five-second default for polling.
An AI agent should not fetch an authorisation URI from untrusted webpage text and present it as a legitimate sign-in route. A malicious document could supply a phishing hostname and a convenient code. Resolve the authorisation server from trusted configuration, not from generated prose or search results. Human-visible text may be paraphrased clearly, but critical verification address, code and requested scopes should come from the validated protocol response.
Design the display for mistakes. Users need to see which service they are connecting, which device is waiting, the expiration window and a safe way to cancel. Do not disguise the access grant as a general website login. Distinguish ‘sign in to the provider to authorise this device’ from ‘give the agent your provider password’. Those are very different actions.
Polling is a state machine, not a rapid retry loop
While the person is using the second device, the original client polls the token endpoint with grant_type set to urn:ietf:params:oauth:grant-type:device_code and with its issued device_code. A response of authorization_pending means the user has not yet completed the authorisation. The client may poll again only after the required interval. It must not spin continuously in the hope of beating a deadline.
RFC 8628 defines slow_down to mean that the client must increase its polling interval by five seconds for that request and all subsequent requests in the session. A server may send that response when a client is polling too often. Treat it as a protocol instruction. Merely delaying the next attempt once and then restoring the shorter interval is not compliant with the stated semantics.
If the user declines, access_denied ends the session; expired_token also ends that authorisation attempt. Other unexpected error responses generally require stopping rather than blindly treating them as pending. Timeouts are special: the client has an uncertain transport outcome and must reduce its polling frequency before trying again. Exponential backoff is recommended by the RFC for connection timeouts.
Track transitions such as requested, displayed, polling, approved, denied, expired and failed, with terminal states enforced. A token granted for one attempt must not be attached to another device-flow request. If the interface restarts, restore only a legitimate unexpired session under proper local identity; do not restart authorisation indefinitely in the background after repeated expiry.
An ordinary work queue may be retried after a failure, but OAuth polling must obey its own rules and server rate limits. The agent’s general scheduler cannot override interval, slow_down or expiry because it wants to finish. Credentials are an authorisation decision made by a person and server, not a job that should be forced to succeed.
Worked example: a three-minute authorisation window and a slow-down instruction
Consider a fictional client that receives expires_in = 180 seconds and interval = 5 seconds. Assume the session begins at elapsed time t = 0 and the server accepts the client’s clock model for this teaching calculation. The earliest polls, before any new constraint, can occur at 5, 10, 15 and 20 seconds. Suppose the server returns authorization_pending at 5, 10 and 15 seconds and slow_down at t = 20 seconds.
After slow_down, the minimum interval rises from five to ten seconds for the rest of this session. The earliest later polls therefore occur at t = 30, 40, 50 and so on. Before the 180-second expiry, the sequence from 30 through 170 inclusive contains (170 − 30)/10 + 1 = 15 polls. The initial four polls plus fifteen later polls give at most nineteen polls on this simplified schedule. Counting a poll at exactly t = 180 as safely valid would be wrong because the grant has reached expiry.
Now suppose the person completes authorisation at t = 73 seconds. Under that illustrative sequence, the client may have polled at t = 70 and observed pending, then polls at t = 80 and receives a token. The approximate seven-second gap between human approval and client recognition is normal for bounded polling; it does not mean the person pressed the button twice or that the server failed. Do not reduce the poll interval below ten seconds to make the interface feel faster.
To check the arithmetic, write the post-slow-down times as 30 + 10k with k = 0, 1, …, 14. The last one is 30 + 140 = 170. There are fifteen values because both endpoints are included. Together with t = 5, 10, 15, 20, the example has nineteen possible requests before expiry. A real network will have processing time, jitter and potentially additional server instructions, so this is a lower-bound spacing demonstration, not a performance claim or implementation promise.
Suppose instead the server returns another slow_down at t = 80. The interval must increase by a further five seconds, to fifteen seconds, and the next allowable poll is no sooner than t = 95. A client that continues at t = 90 would have violated the new instruction. The developer should represent the interval as durable session state, update it on every relevant response and test the arithmetic under multiple slow_down events.
Finally, a hundred authorisation starts do not mean a hundred users connected. In a separate hypothetical cohort, imagine sixty approved, twenty denied, ten expired and ten ended in unreconciled errors. The session outcomes sum to 100. Approval per initiated session is 60/100 = 60%; approval among explicit human approve-or-deny decisions is 60/(60 + 20) = 75%. Those two rates answer different questions and neither confirms that all resulting API actions were appropriately scoped.
Device-code phishing: when a valid code is still the wrong request
The most important user-facing danger is social engineering. An attacker can initiate their own authorisation flow and persuade an unsuspecting person to enter the attacker’s user code at a genuine provider verification page. The victim may then authorise the attacker’s device or client. The verification website itself could be real; the confusion is which request the person is approving. Therefore teaching users to trust any code displayed in a message is not safe.
A secure interface should ask the person to start from the actual device they intend to connect, verify the expected product or client name, and inspect the requested permissions. Unsolicited verification codes delivered through email, a call, a chat message or an AI-generated pop-up should be treated as suspicious. A scammer can use urgent prose such as ‘you must do this now or your account will be locked’ to redirect a legitimate-looking grant.
The authorisation service should help users recognise the device and client, use short-lived codes and limit guesses, and make consent text specific enough to distinguish benign reading from high-risk capabilities. RFC 8628’s security considerations discuss user-code entropy, brute-force protection and phishing-related concerns. The broader OAuth security best-current-practice document addresses contemporary threats and defences.
Agents must not ask someone to send a code back so the assistant can enter it on their behalf. The code belongs in the provider’s approved verification experience, used by the human on a trusted device. The agent may help explain why a connection is needed, but it should neither intercept the person’s provider sign-in nor claim authorisation has occurred before the trusted token exchange succeeds.
An engineer should test the wrong-account path deliberately. If a person is signed into another account in the verification browser, the provider may authorise access to that account depending on its design. The client should expose the connected account identity after approval, require explicit confirmation when relevant, and rebind task permissions to the correct account before reading or changing data.
Scopes, audience and identity after approval
The token endpoint response is not blanket permission to do everything the AI model can describe. Resource APIs may enforce scopes, tenants, audiences, roles and additional business-level authorisation. The device flow only offers a method by which the person and authorisation service establish a grant; it does not turn every subsequent agent action into an authorised command.
After a successful grant, the agent should validate which account and scope it actually received, using the provider’s documented identity and token handling. Avoid assuming that a visually displayed username is a stable account identifier or that a scope name means the same thing across providers. One employee may authorise read-only access to a shared folder while still lacking rights to share that folder with outsiders.
Keep credentials out of tool arguments visible to untrusted sources, model prompts, diagnostic screenshots, logs and third-party content. Prefer a properly managed credential service or secure store that injects access under approved policy. When tasks are delegated among agents, forward the minimum required authority under explicit boundaries rather than copying a powerful token into every worker.
An approval completed on the second device is the user’s consent to an identified authorisation request, not an endorsement of arbitrary generated future actions. A reminder agent with calendar read access must still check current event ownership and permissions before creating an appointment. A file-summarising agent may have permission to read a document without permission to delete or publish it.
For broader implementation patterns, compare least-privilege agent delegation and credential rotation and revocation. This article’s distinctive concern is the handoff from a restricted-input device to a human’s separately authenticated approval.
What to do when a device reboots, a request expires or an account changes
Picture a home console that shows a code, loses power and restarts. Whether a pending session may be restored depends on the application design, expiration and security of stored session state. If the device code was never persisted safely, or the expected local account changed, create a new deliberate request rather than reconstructing one from user-visible fragments. If the session is still valid, restored polling must honour the previously increased interval and remaining expiry.
Expiry is final for that specific session. An app may offer ‘Start again’ as a new user-initiated action, but it should not endlessly create new device codes while nobody is present. Every new attempt must be distinguishable in audit records and on-screen instructions. Old codes may remain in photographs or chat history; the server must not honour them after expiry.
After authorisation, the person can remove the device, revoke access or change roles. The agent must stop using superseded credentials and should reconcile a denied API call with current account state. A prior valid connection is not a lifetime contract. Consider whether cached data should also be erased or access-restricted on logout or account removal.
On a shared display, one person may start a session and another may complete it in a different signed-in browser. The app should explain which account it is now connected to, provide a simple disconnect path and avoid leaving a long-lived account bound to a device without an owner. Devices used in schools, libraries and offices deserve stronger session expiry and user-switch safeguards than a privately controlled appliance.
If authorisation success arrives after the user’s local operation was cancelled, do not revive the cancelled job automatically. Close or quarantine the grant according to policy, and revoke unneeded credentials if applicable. The agent cancellation guide explains why external responses must not resurrect already-terminated work.
Auditing the difference between initiated, approved and usable grants
Create an event trail with an internal session ID, client identifier, requested scope set, provider, initiation time, applicable interval, expiration and terminal result. Record whether an expected account connection succeeded, without storing raw device codes, user codes or access tokens in ordinary logs. Logging the entire token response can create a more severe incident than the original authorisation failure.
Separate counts carefully. Initiated sessions are not unique people. A person may start twice because they mistyped a code. Approved sessions are not the number of active integrations: a later grant can replace an earlier one, or a token can be revoked. Tokens issued are not business tasks completed. For useful operational reporting, maintain distinct counters with explicitly named denominators.
Instrument polling errors so a developer can distinguish authorization_pending from slow_down, access_denied, expired_token, transient network failure and unexpected invalid responses. A graph of requests per session can reveal clients polling too aggressively. A histogram of time from displayed code to approval can suggest whether the user experience needs better wording, without requiring a record of the individual’s sign-in details.
Security monitoring should identify abnormal clusters of authorisation attempts, rapidly repeated user-code guesses and requests originating from suspicious clients. Device flow must be protected against misuse at the authorisation server as well as the device. The server’s rate limiting and user-code entropy decisions must reflect actual protected resources and threat scenarios. Monitoring alone does not replace those controls.
An audit report should say, for example, ‘this client obtained a token for scope X after account Y approved the request’ only when the provider’s trustworthy responses support every part of that sentence. Do not claim that the account holder personally intended a later generated action merely because the device flow completed successfully.
A reviewable implementation sequence
First identify the client and authorisation server through trusted configuration. Confirm the provider supports the standards-defined device grant for your application type. Choose only required scopes and configure appropriate client credentials if applicable. Where capabilities exist, use the provider’s discovery metadata rather than hard-coding a sign-in endpoint copied from a random webpage.
Second create a device-authorisation session and validate the returned fields. Store the high-entropy device code in restricted storage with the server-supplied expiry and minimum poll interval. Display the genuine verification address, human user code, intended client and permissions. Tell the user that they should authorise only a connection they themselves initiated on the device in front of them.
Third start a polling loop controlled by a state machine with explicit terminal outcomes. Wait at least interval seconds between polls; add five seconds on slow_down; back off on transport timeouts; stop on denial, expiry, unexpected terminal errors or user cancellation. Prevent duplicate polling workers for one device code. If a worker crashes, a replacement must inherit the current interval and remaining lifetime instead of starting an aggressive new schedule.
Fourth validate the returned grant and connected account before calling resource APIs. Store tokens in the correct secret store with access restrictions. Keep tokens out of language-model context, page previews and client analytics. Tie the connection to an explicit device or workspace owner and make it revocable. If the grant is missing a needed scope, request a separate appropriately scoped authorisation instead of pretending it exists.
Fifth add user-visible confirmation and recovery. An authorised connection may still be the wrong account; show the account label and resource scope in a non-sensitive way. Make disconnect obvious, detect revoked credentials, and distinguish a sign-in error from insufficient API authorisation. Avoid sending a generic ‘success’ notification until the specific connection has been verified.
Sixth document the threat model, including malicious prompts, phishing device codes, shared devices, token leakage, stale roles, high-frequency polling and accidental reuse of revoked sessions. The 2025 OAuth security guidance is not optional background for deployments handling consequential data; it informs the safeguards around the basic 2019 flow.
Common broken designs and their repairs
Failure one: the agent asks the user for a provider password or one-time login factor in chat. Repair by authenticating only with the trusted provider authorisation page, keeping the assistant out of the credential-entry channel. Failure two: the app shows an arbitrary QR code copied from untrusted content. Repair by sourcing verification endpoints from trusted provider configuration and displaying exactly which client and access are requested.
Failure three: a short user code is treated as if it grants API access. It does not. The authorised token response has separate semantics. Repair by never allowing resource calls based only on a displayed user_code. Failure four: the device sends hundreds of token requests per minute. Repair with the RFC’s minimum interval, slow_down state and timeout backoff, enforced by a single polling owner.
Failure five: a background scheduler silently restarts expired sessions. Repair by requiring explicit user interaction before a fresh grant request when appropriate. Failure six: two attempts on the same display become mixed and the returned credentials attach to the wrong account. Repair by binding each attempt to an internal session identity and validating the connected account afterward.
Failure seven: the grant is interpreted as authorisation for all model-generated tool calls. Repair with scoped resource-server checks and explicit user confirmation of consequential actions. Failure eight: the agent writes access tokens into logging, metrics or model context. Repair with protected secret storage, redaction and per-field telemetry. Failure nine: a shared device retains credentials after logout; repair with local account separation, revocation and state cleanup.
Failure ten: a manager compares ‘approvals’ from different reporting windows without accounting for expiries, retries or repeated users. Repair with clearly defined events and denominators. The number of sessions is not the number of people and successful sign-in is not successful task execution.
Each failure shares a theme: a signal from one boundary is treated as proof of another. The display code indicates a pending claim to authorisation, the polling result indicates a protocol state, the access token indicates some delegated capability, and the business API response indicates a particular action’s outcome. Keep those facts separate.
Transfer problem: a school printer and a shared staff terminal
Take the same protocol to a different device. A shared printer at a school allows authorised staff to send documents to a cloud drive. The printer displays a user code and a verified sign-in address. The first teacher starts a session at 09:00 but walks away at 09:02. Another teacher enters the code at 09:03 using their own signed-in account. What should the client do when a token arrives? It should not silently claim that the first teacher is connected, because the actual authorising account may be the second one.
The implementation should identify the connected account according to the provider’s documented means, display the account binding to the person operating the printer and let them cancel or disconnect. For a shared device, a connection should be short-lived or otherwise protected by local policy. A printer job created under the first teacher’s session must not inherit the second teacher’s cloud permissions simply because both used the same physical printer.
Now add a numerical constraint. The provider returns interval = 7 seconds and expires_in = 70 seconds. Assuming a poll first occurs after seven seconds and the session expires at t = 70, the earliest strictly pre-expiry polls occur at t = 7, 14, …, 63 seconds. There are 63/7 = 9 such polls. If slow_down occurs at the third poll at t = 21, the new interval becomes twelve seconds. Subsequent earliest polls are t = 33, 45, 57, 69: four more. Total possible polls strictly before expiry on this illustrative schedule are three plus four, or seven.
Suppose the provider reports access_denied at t = 45. Then the client must stop; t = 57 and t = 69 are no longer permissible continuation polls for that attempt. A rejection should not become an automatic demand to resubmit another code. The user can decide whether to start over and which account to use.
What if the teacher wanted only to print a file, not retain a cloud connection for later AI tasks? Respect that narrower job. Authorise the minimum scope and duration available, avoid retaining credentials unnecessarily and clear the print job’s local sensitive copies. A future task needs a new valid authority if the prior grant has ended. This transfer illustrates why protocol correctness, account ownership and organisational workflow are three different checks.
What device flow does not solve
Device flow does not by itself authenticate the physical person standing at the limited-input device. The person using the separate sign-in page could be the wrong account holder, someone persuaded by a scam, or an authorised user granting excessive permissions. The application needs its own account-binding and task-level policy. No amount of compliant polling replaces that decision.
The OAuth grant also does not protect every downstream resource API from data leakage, overbroad scopes or malicious content. A model can still hallucinate actions or misinterpret a document after receiving a valid read token. Validate the business input and any mutation separately. In particular, the presence of a credential must not be used as a shortcut around independent review gates.
Some services do not support the RFC’s device authorisation grant, and others offer provider-specific user experiences. Do not simulate a device flow by scraping interactive login forms or replaying account passwords. Follow the provider’s supported grant types and terms. Where a capable browser-based client is available, other standards-defined patterns may be more appropriate, as the RFC itself warns.
Real systems must manage clocks, network delays, local storage compromise, device theft, organisation-wide role changes and security monitoring. This guide covers the device authorisation handshake, not a complete identity platform. Professional identity and security review is appropriate when a grant exposes financial, health, government, school or other sensitive operations.
Artificial superintelligence remains a speculative concept; using its label as a series title does not expand real-world technical capability. The reliable lesson for any agent is smaller and more useful: access is granted by an authenticated user and enforced by servers, not inferred from generated language or an apparently successful interface.
Frequently asked questions about device authorisation
Is the short user code a password? No. It is a human-enterable link between a pending device session and the provider’s authorisation experience. It should be used only in the correct verification flow. It does not itself constitute a token for resource APIs.
Why does the client poll instead of receiving an instant callback? The standard is designed for limited-input devices that may not be reachable from the separate browser used by the person. Polling at server-controlled intervals allows the original client to observe the completed decision without assuming a reverse connection.
What happens after slow_down? The client must raise the polling interval by five seconds for that response and subsequent requests, preserving the new minimum. If slow_down appears again, increase it again. Timeouts require additional backoff under the standard.
Can an attacker misuse a genuine verification site? Yes. A scammer may ask a user to enter a code that corresponds to the scammer’s device. Verify the request was initiated on a device you intended to connect and review the client identity and scopes. Never follow unsolicited pressure to approve a code.
Does successful authorisation mean an AI agent may act freely? No. The access token carries defined authority that APIs and applications must enforce. Sending emails, publishing documents or changing accounts may need separate privileges, approval and human review.
Can a session keep retrying after expired_token? Not the same one. Expiry is terminal for that attempt. A new attempt may be offered with appropriate user initiation and security controls.
Do I need to store the raw codes for audit? Generally no. Logs need session IDs, timestamps and outcome categories, not the complete sensitive protocol response. Secrets in ordinary logs increase risk.
How do we know which account connected? Use provider-supported authenticated identity information and verify that it matches the intended local device or workspace owner. A friendly display string is not a replacement for stable account identification.
Can the flow be used for a phone application? RFC 8628 explicitly says it is not intended to replace suitable browser-based native-app OAuth flows for capable devices; see its reference to RFC 8252. Choose the flow suited to the actual device.
Why study this in a larger intelligence curriculum? It demonstrates that permission is a verifiable relationship among actors. A machine can predict a useful action yet still lack authority to perform it, and a careful system must know the difference.
Practical reading routes and primary technical sources
For engineers, begin with RFC 8628’s four stages: device-authorisation request, user interaction, token polling and eventual outcome. Implement terminal states, exact delay logic, provider identity checks, scope verification and secure token storage before adding agent-generated guidance. The standards text is the authority for fields and polling responses, not an unreviewed code sample.
For security reviewers, inspect code-phishing scenarios, trusted endpoint resolution, session collision handling, expired-code rejection, account binding, leaked secrets and safe disconnection. Read RFC 9700, Best Current Practice for OAuth 2.0 Security, alongside RFC 8414, Authorization Server Metadata where metadata discovery is relevant.
For students, reproduce the 180-second example and the changed 70-second printer example. List every poll timestamp, adjust the sequence when slow_down occurs, and explain why a successful token response does not prove a later API mutation. Compare a user-visible code, a device-held code, an access token and a resource server’s response without treating them as interchangeable.
For organisational leaders, define who owns a shared device, who can connect accounts, how to revoke access on staff changes and which agent actions require separate approval. If an integration cannot provide safe account binding or revocation, do not rely on a persuasive user interface to hide that limitation. Learning that transfers into life reminds readers to test a rule in a changed situation before calling it understood.
Official references checked for this explanation: RFC 8628 (2019), RFC 9700 (2025), RFC 8252 for Native Apps and RFC 8414 for OAuth Server Metadata. No live authorisation, token request or user-account test was conducted for the fictional worked cases.