[othercodes]

webshare login opens the browser, runs the authorization code flow with PKCE against a loopback redirect (RFC 8252), and stores the token in the OS keychain, falling back to a file only the owner can read. webshare logout revokes the refresh token and then the access token before forgetting them; forgetting alone leaves a token the API still answers. whoami now says which credential it used.

WEBSHARE_API_KEY keeps working and takes precedence, so scripts and CI are untouched.

Notes on the parts worth a second look:

• Endpoints come from /.well-known/oauth-authorization-server, so nothing is hard-coded and --base-url alone points the login at a test environment. The token and revocation endpoints are stored with the credentials, so an ordinary command never fetches metadata just to refresh.
• The callback is only accepted when it carries back the state this command generated and an iss matching the server (RFC 9207). Any local process can reach that port, so this is what keeps it ours.
• Tokens are keyed by API host, so a login against dev never stands in for production.
• The refresh rotates both tokens and the new pair is written back; the server refuses a refresh token twice, so a rotation that is not stored would leave the next command with nothing.
• login asks for the seven scopes the CLI's own commands need and nothing else. --scope overrides.
• golang.org/x/oauth2 is pinned to v0.30.0 rather than v0.37.0: the newer one requires Go 1.26 and CI tests 1.23 and 1.24.

Not in here: the device authorization grant. login needs a browser on the same machine, so over SSH or in a container WEBSHARE_API_KEY is still the way in. The server does not offer that grant today either.