ByteBind: making the private network part of the login

I wanted to protect the management interface of a public application that can control resources on my tailnet. The interface had to stay on its public origin, while management access had to come through an authorized tailnet device.

I called the result ByteBind. A browser contacts the public application and a private Authority during the same authentication exchange. The Authority identifies the device on the private connection, applies policy, and gives the browser proof material to return to the application.

ByteBind isn’t a nicer login screen. It’s no login screen.

No registration ceremony. No OIDC/OAuth ceremony. No redirects, PINs, keys, or account pickers.

For the developer, it’s an import, an app bind, and route binds. For the operator, it’s a few lines of policy. For the user, it’s seamless, ambient authentication.

The developer declares what’s protected. The operator declares who’s trusted. The user just opens the page.

How the exchange works

The public application asks the Authority to create a short-lived transaction. It passes a challenge to the browser, which uses it to contact the Authority over the private network.

The Authority identifies the connecting device through the overlay and applies the application's authorization policy. If the device is allowed, it returns an encrypted response containing a second secret. The browser uses that secret to produce a redemption proof and sends the proof to the public application.

The application redeems it with the Authority. Successful redemption consumes the transaction and returns the authorization result. The application can then issue a management session or perform the requested operation.

The application keeps serving its public interface. The Authority handles private-network identity and policy. A browser has to reach both during the exchange.

What access depends on

The Authority needs an authenticated connection-to-device mapping and a policy allowing that device to manage the application. A private address by itself says too little.

With Tailscale, the provider uses node identity and policy such as required tags or an allowlist. The Authority can return only the claims the application needs, keeping the rest of the device metadata within the private identity service.

The Authority also checks the origin bound to each transaction. Without that check, a website open on an authorized laptop could borrow the laptop's network access to authenticate to another application. The application performs its own origin checks at its authentication endpoints.

Sessions and individual operations

ByteBind has two profiles.

The session profile issues a short management lease. The draft recommends three minutes, renewed every minute through another private-network exchange. Leaving the network stops successful renewals; access ends when the existing lease expires. This gives a bounded delay between losing network access and losing management access.

The transaction-bound profile covers one operation. The browser and application compute a digest of the request and include it in the proof. The application stores the request and executes it after successful redemption. A service restart or credential rotation can use this profile.

The application still owns execution and recovery. If a response is lost after an operation runs, obtaining fresh authorization must not accidentally repeat the operation.

What the device proves

The exchange establishes participation through an authorized private-network device. It cannot identify the person holding that device. An application that needs human identity or approval has to add that step.

An authorized device is a trust assumption. Compromising it, stealing the ceremony's secrets, or copying a valid session cookie weakens the guarantees. Short leases limit the useful lifetime of a copied session.

The intended experience is to open the management page and let the exchange run in the background. Browser permission rules for public pages accessing private addresses may add a prompt. Real-tailnet browser testing remains on the roadmap.

How ByteBind differs from OIDC, and where tsidp fits

OpenID Connect gives applications a standard way to accept identity from a trusted provider. In the familiar authorization-code flow, the browser visits that provider, the application exchanges a code, and an ID token communicates the authentication result. OIDC itself doesn’t require passwords or a visible login screen. OpenID Connect specification.

ByteBind addresses a narrower requirement: a public application needs fresh participation through an authorized private-network device before granting management access. Its native exchange happens in the background, without an OIDC redirect. The result authorizes a short lease or one specific request. It establishes device participation; identifying the person using that device requires an additional mechanism.

tsidp turns Tailscale identity into standard OIDC/OAuth credentials for applications that already support those protocols. It can eliminate authentication prompts too. Its value is compatibility with existing applications and their identity integrations.

ByteBind’s focus is direct route protection, repeated private-network attestation, and transaction-bound authorization in applications adopting its bindings. Both aim to let users open an application without entering another password, but the integration and authorization model differ.

An application could use tsidp for its user identity and require ByteBind for a privileged operation. The ByteBind draft also describes an optional OIDC bridge, though the reference implementation does not implement it. Neither arrangement implies an existing tsidp–ByteBind integration.

From TailBind to ByteBind

The early drafts were called TailBind because the first provider was Tailscale. The protocol depends on an authenticated private path that can map a connection to a device and apply an authorization policy.

I renamed it ByteBind in draft 0.6. The current specification is draft 0.7.

Its cryptography uses HMAC-SHA256, HKDF-SHA256, and AES-256-GCM. Most of the design work concerns channel binding, authorization scope, and safe transaction consumption.

The reference implementation has unit and integration coverage and has completed browser exchanges in the test setup. Real-tailnet identity and certificate behavior, cross-node control traffic, browser permissions, and independent security review remain outstanding. I am publishing the draft to get those assumptions examined.

Read the technical companion for the endpoint flow and cryptographic transcripts, or the draft 0.7 specification and roadmap snapshot for the details and open questions.

This started with “how do I protect the management page for this server?” I am now considering an Internet-Draft as a way to get useful criticism of the answer. Yet again, a problem created by Bad Decisions may have produced a good one. I may have to rename that project.