Multi-tenancy & Management API

Per-tenant keys, did:web, the /v1 API, RBAC, webhooks, audit.

Multi-tenancy here is real isolation, not a column in a table. Tenant resolution is by host, and each tenant carries its own cryptographic identity.

What each tenant gets

• Its own Ed25519 signing key, generated on first use and envelope-encrypted at rest.
• Its own OIDC discovery document and JWKS at <slug>.oauth.work.
• Its own did:web:<slug>.oauth.work issuer for Verifiable Credentials.

GET https://acme.oauth.work/.well-known/openid-configuration
GET https://globex.oauth.work/.well-known/jwks.json   # a different key entirely

The management API

The /v1 management API administers orgs, users, clients, roles, credentials, webhooks, and audit:

GET /v1/clients          Authorization: Bearer <mgmt-token>
POST /v1/roles           { "name": "deployer", "permissions": ["deploy:write"] }
GET /v1/audit?since=…    # signed, append-only event log

Security posture

• Refresh-token reuse detection (RFC 9700) — a replayed refresh token revokes the whole family.
• RBAC — permissions and default roles are centrally defined; SCIM groups map into them.
• Webhooks — events are signed and retried via a per-org dispatcher with alarms.
• Audit — every privileged action is recorded and queryable.

No lock-in: export everything, bring your own keys, and the standards are portable by design.