What It Takes to Operate the Model

Cloudflare OS’s capability model does not end when a Gadget’s code is sandboxed or a Gatekeeper’s policy is written. This chapter focuses on the operating choices around the system: how users are identified, how OAuth authority is handed off, how a private installation differs from a public service, and what an operator must validate when the repository still labels parts of deployment early access. The practical goal is to distinguish controls provided by the runtime from responsibilities that remain outside it.

Secure onboarding is part of capability security

A runtime can enforce narrow bindings perfectly and still fail if the account-connection flow lets an attacker redirect someone else’s credentials into the wrong Workshop account. Cloudflare OS treats connect and sign-in URLs as bearer capabilities: whoever opens such a URL may be able to complete the provider flow. That means the browser that starts the flow must be bound to the browser that finishes it before the resulting account becomes usable.

The handoff design stages the account rather than activating it immediately. When a provider flow completes, the Gatekeeper returns a short-lived, single-use ticket. The Workshop stores only a hash of that ticket and activates the staged account only after the ticket is redeemed through the initiating user’s authenticated session. A second nonce is written into the popup’s own session storage before navigation. A pasted URL or a link opened in an unrelated tab lacks that nonce and cannot complete the same handoff.

This matters because a user can be phished without the OAuth provider itself being compromised. An attacker may start a connection in the attacker’s Workshop and persuade a victim to open the authorization URL. If the provider’s completion were enough to activate the grant, the victim’s credentials could land in the attacker’s account. Staging and nonce binding make the completion page insufficient on its own: the result must return to the Workshop session that initiated the flow.

Reconnects use the same logic. Replacement credentials are staged instead of being written directly into a live account. This prevents a phished or overlapping flow from overwriting credentials that existing Gadgets are already using. The ticket identifies the staged result that it is allowed to activate, rather than authorizing whatever credentials happen to be waiting when the ticket is redeemed.

Public sign-in is also separated from full service access. Authentication-capable Gatekeepers return a provider-verified email, and the Workshop uses that verified identity as the primary account key. The sign-in flow requests only the minimal scopes needed to verify the email and discards the transient grant. The user connects the fuller service capability later if they want a Gadget or agent to use that service. Login proves who the user is; it does not silently become a broad data connection.

These details belong in the same story as Gadget bindings because both flows decide when authority becomes live.