#Part 13. ClosedBit ID

#Part 13 Section 1. Identity Model

ClosedBit ID is the verified account layer for ClosedBit apps. It combines verified email, password hardening, optional passkeys, mandatory second-factor policy where configured, device authorization, app-specific scopes, short-lived bearer access, rotating refresh tokens, account recovery, and auditability.

One identity does not mean one universal permission. Every app has a client ID and an allowed scope set. The browser client is closedbit-browser and requests only profile email.

#Part 13 Section 2. Browser Device Flow

ClosedBit Browser starts authorization with POST /api/id/device/authorize. The service returns a private device code, a short user code, an approval URL, an expiry, and a polling interval. The browser opens the HTTPS approval page in the system browser. The user signs in and completes 2FA there. ClosedBit Browser polls POST /api/id/token until approval, denial, or expiry.

This design keeps passwords, passkeys, and 2FA secrets out of the native browser. The user sees the code being approved, and the device code expires after a short window. The browser respects authorization_pending and slow_down responses instead of hammering the identity service.

#Part 13 Section 3. Token Storage

The access token stays in process memory. The rotating refresh token is encrypted with Windows DPAPI in the current desktop build and stored under the current user's application-data folder. Refresh rotation replaces the stored value after every successful refresh. Signing out overwrites the local protected value and clears memory.

Applications must never place identity tokens in URLs, history, search queries, logs, crash messages, page JavaScript, or crawl requests. Bearer tokens go only in the Authorization header to the exact HTTPS ClosedBit identity origin.

#Part 13 Section 4. ClosedBitOS Credential Vault

DPAPI is a Windows host facility. Native ClosedBitOS needs its own credential vault backed by hardware-protected keys when available, authenticated encryption, per-app isolation, lock-screen binding, rotation, rollback defense, and recovery semantics. The phone target additionally needs secure-enclave/TPM-class integration, biometric policy, remote revocation, and protected reset flows before it can hold a production ClosedBit ID.

#Part 13 Section 5. App Integration Rules

- Register a distinct client ID per product and environment. - Request the smallest scope set needed. - Verify redirect/device approval origins exactly. - Rate-limit authorization, verification, token, and recovery endpoints. - Hash server-side session and token material; do not store raw bearer values. - Rotate refresh tokens and revoke the family on reuse. - Require recent MFA for security-sensitive account changes. - Provide a visible device/session list and remote revocation before public release.