Authentication

Every protected Droplit route uses BRC-103/104 mutual authentication. The client and server prove their identities through an SDK-managed handshake.

Preferred browser model: Sigma

For Droplit UI and app integrations using Sigma:

1. User authenticates with Sigma.
2. The connected Sigma iframe exposes the SDK WalletInterface.
3. Your app gives that wallet to AuthFetch for HTTP or Peer for WebSockets.

Keys remain inside the Sigma domain while the SDK performs mutual authentication.

Existing signer for agents

npx @droplit.dev/cli access --name <known-sponsor> --wallet-url http://127.0.0.1:3321 --json

Use a BRC-100 SDK HTTPWalletJSON signer at the selected URL; 1sat serve wallet is storage RPC. --originator defaults to droplit-cli.local. Reuse the same signer after the sponsor owner approves the copied link. The CLI access check refuses automatic SDK payments. OAuth tokens alone do not provide signing.

Explicit --wif <WIF> remains supported instead of --wallet-url for local signing; the CLI never reads a WIF from environment variables. Applications can also supply their existing WalletInterface directly to AuthFetch.

Security checklist

• Prefer Sigma-hosted wallets for browser flows.
• Never expose private keys in frontend bundles.
• Keep backend wallet keys in a secrets manager.
• Use separate keys for dev, staging, and prod.
• Scope public keys per droplit allowlist.
• Let the SDK own all handshake and session protocol work.

Related references

• API Authentication
• Permission Model
• Agent Playbooks