Migrating from `device_code` workflows

Caution

Using a device code in CLIs is deprecated. Do not use it for new apps.

The preferred way to authenticate CLIs and other input-constrained apps used to be via a device code.

Your app prints a short code and a URL to the terminal, and the user opens that URL and types the code in (or follows a link with the code already filled in) to authorize the app. This flow is now deprecated.

The recommended approach now is to send the user to their browser to sign in, then have your app pick up the result automatically. To catch that result, your app briefly runs a small local web server. This is what the OAuth 2.1 spec now recommends.

What to do instead

1. Generate a PKCE code verifier and code challenge.
2. Start a temporary local HTTP server on the loopback interface.
3. Open the Yoto authorization URL in the user’s browser.
4. Receive the authorization code on your local callback.
5. Exchange the code and PKCE verifier for tokens.
6. Store the refresh token and reuse it on later runs.

Callback URL

Your need to register the localhost callback URL in the developer dashboard, i.e,

http://127.0.0.1:8787/callback

If you’re using a different port, make sure to register the matching URL.

---

For a full walkthrough with example code, follow the Headless / CLI Authentication guide.