Account model
One Account identity, Organizations, memberships, entitlements, and API keys.
0Bit uses one human Account across one or more Organizations. The Account authenticates the person; the selected Organization owns product access, verification state, and API keys.
Core concepts
| Concept | Description |
|---|---|
| Account | A human identity with an opaque session, MFA, security history, and Organization memberships |
| Organization | A company or workspace that owns entitlements, verification state, and API keys |
| Membership | The Account's role in an Organization, such as owner, administrator, member, or read only |
| Entitlement | Access to a reviewed product or capability for the Organization |
| API key | A hash-only pk_* or sk_* credential scoped to one Organization, mode, and set of permissions |
There is no separate liquidity-provider login, Gate partner login, or product key authority. One Organization can both provide liquidity and consume product APIs.
Public Account surface
The institutional Account API is the public owner of Accounts, Organizations, memberships, invitations, sessions, and API keys:
/account/auth/*
/account/me
/account/organizations/*
/account/invitations/*
/account/verification/*
GET /account/me returns the signed-in Account and selected Organization
context. Product portals use that one response instead of reconstructing
identity from separate profile, token, or product tables.
Browser authentication
Successful authentication creates an opaque, database-backed HttpOnly session cookie and a double-submit CSRF cookie. Browser code stores no bearer token and there is no refresh-token endpoint.
The Institutional portal may receive a short-lived, audience-bound Gate assertion in the
Account response. The assertion is held in memory, sent only to Gate dashboard
routes, and renewed by rereading /account/me through the opaque session.
Product API authentication
Human sessions do not authenticate server-to-server product requests. An Organization creates scoped publishable or secret keys through the Account surface, and each product verifies the key plus entitlement before serving the request. See Organization API keys.
Verification and staff ownership
Applicants use /account/verification/* from the public institutional flow.
The verification service and review state are owned by Operations; the public
path does not expose staff actions. Staff create Organizations, issue
invitations, and review applications only through /operations/* with staff
RBAC and audit.
Enabling a capability
- An Organization exists and the Account has a valid membership.
- Operations grants the reviewed product or capability entitlement.
- Required Organization verification and product setup complete.
- An owner or administrator creates a key with the minimum required scopes.
A valid key does not bypass a missing entitlement or incomplete verification.