Skip to content

v0.24.0

Release Date: 2026-10-27

Command-line tools can now sign people in to SystemAuth and call SystemForge-powered APIs with DPoP-bound tokens. The new identity/publicclient package serves tools a deployment ships to its own users and tools others write against it alike. It adds no breaking changes and no migrations.

Highlights

  • Sign in from a terminal. publicclient.Login runs the authorization code flow with PKCE on a loopback redirect (RFC 8252): the tool listens on a free port, the person signs in in their browser, and SystemAuth redirects back with a code.
  • Tokens bound to a key, nothing to register. The tool generates a P-256 key at login, and SystemAuth binds the tokens it issues to it (RFC 9449). There is no key list to manage, unlike SSH keys: the key matters only while its tokens live, and logging in again makes a new one. A copied token is useless without the key.
  • Calls that keep working. Session.HTTPClient sends Authorization: DPoP with a new proof on every request, refreshes the access token before it expires, and retries once when a server asks for a nonce or refuses an expired token.
  • Safe to share between processes. A tool and the processes it starts, such as an MCP server, can share one login. They refresh under an operating-system lock and adopt each other's refreshed tokens, because SystemAuth revokes the whole login when a redeemed refresh token is presented again.

Added

  • publicclient.Login, Open, and Session with Transport, HTTPClient, AccessToken, Identity and Logout.
  • publicclient.Store and Locker, and FileStore. FileStore keeps the key and tokens in one file readable by its owner only, refuses a file others can read, writes atomically and durably, and locks with flock or, on Windows, LockFileEx.
  • publicclient.RegisteredRedirectURI (http://127.0.0.1/callback), the redirect URI to register for the client.

Dependencies

  • golang.org/x/sys v0.49.0 is now a direct dependency, for the operating-system lock. It was already an indirect one.

Documentation

  • Calling APIs with DPoP: registering the client, logging in, storage, and processes that share credentials
  • ADR-019: Support Requests and Feedback (proposed): the support UI and the requester's list, support tools built for agents first, replies agents send only once a person approves them, and a reply address kept while a conversation continues

Using it

  1. Register the tool once per SystemAuth deployment as a public client with the redirect URI http://127.0.0.1/callback and the authorization_code and refresh_token grants. Mark it first_party if you ship it to your own users, so they see no consent screen. Never give a distributed client allow_bearer_tokens.
  2. Have the APIs the tool calls accept its tokens: relyingparty.Config.AcceptedClientIDs with the tool's client ID, or AccessTokenAudience with an audience its tokens carry.
  3. In the tool, Login once, then Open on later runs and call APIs through Session.HTTPClient.

Nothing changes for existing deployments.

For release history, see the changelog.