Security and data retention
MicroAuth is designed so API traffic stays between an API owner and their customers. The SDK sends control-plane data and usage aggregates to MicroAuth. It does not send request bodies, request headers, query parameters, or response bodies.
Data sent by the SDK
A usage item contains a stable idempotency token, an API key UUID, an immutable usage-policy UUID, the response status code, a count, and an hourly timestamp. MicroAuth uses every reported count for monthly request allowances. It charges the customer balance only when the status code in that policy is billable.
Customer API keys are hashed inside the API process. Snapshot and verification calls use SHA-256 digests, so the raw map_... key is not forwarded to MicroAuth.
Account and tenant isolation
- SaaS users act within a workspace and a role. Workspace API keys are also bound to one workspace.
- A portal host selects the tenant. Every authenticated team-scoped portal request also sends
X-MicroAuth-Workspace-ID; the API verifies tenant ownership and current membership on every request. - Cookie-authenticated mutations require CSRF validation. Session cookies are secure and HTTP-only in production.
- Database constraints reinforce tenant ownership for plans, customers, API keys, usage, private-plan assignments, and Stripe objects.
The workspace header selects a customer team. It is not a substitute for membership, role, or CSRF checks.
Credentials and sensitive fields
- Passwords use Argon2id hashes.
- API keys are shown once and stored as SHA-256 hashes.
- TOTP and connected Stripe secrets are encrypted at rest with the application encryption key. Backup codes are stored as hashes.
- Stripe webhook signatures are checked against the unmodified request body. Accepted events are committed to a durable database inbox before the API acknowledges them.
- The production API binds to loopback and is exposed through the TLS reverse proxy. Custom-domain certificates are issued only after the API confirms a registered, verified domain.
Keep the encryption key, OTP pepper, database credentials, Stripe keys, object storage credentials, and deploy credentials in a secret manager or a root-readable environment file. See Credential rotation.
Implemented retention schedule
The worker runs lifecycle cleanup daily:
| Record | Current retention |
|---|---|
| Processed or ignored raw Stripe webhook events | 90 days |
| Dead Stripe webhook events that still need investigation | 365 days |
| Completed, expired, or failed checkout coordination rows | 90 days |
| Stripe subscription tombstones used for replay safety | 365 days |
| SDK usage idempotency receipts | 60 days |
| Retired SDK usage-policy versions | 120 days after their traffic window |
| Sent transactional email outbox rows | 90 days |
| Dead transactional email outbox rows | 365 days |
| Used or expired password-reset token rows | 7 days after use or expiry |
Expired previous tenant-secret hashes are also cleared after their configured rotation overlap ends.
Credit ledgers, payment records, usage aggregates, and audit records do not currently have an age-based purge. They remain while their owning account data exists because they support billing, disputes, and security review.
Account, workspace, tenant, or customer deletion can be blocked while a live subscription or open checkout exists. Cancel or reconcile those Stripe objects first. After deletion is accepted, relational child records are removed by database ownership rules. Operators must also remove associated object-storage assets and apply the documented backup-retention policy; a database cascade does not erase provider backups or detached files by itself.
Operational safeguards
- Back up PostgreSQL and test restoration on a schedule. Encrypt backups and give them an explicit expiry.
- Restrict production database, Redis, object storage, and host access to the minimum required identities.
- Alert on authentication lockouts, webhook backlog, reconciliation drift, grace-period expiry, usage delivery failures, and unexpected administrative actions.
- Do not put raw API keys, passwords, Stripe secrets, OTP values, or encryption keys in logs or support tickets.
- Record deletion and emergency access in the audit or incident record without copying sensitive values.
For vulnerability reports, contact security@microauth.com. For privacy and deletion requests, contact privacy@microauth.com.