Security and data

MicroAuth is a control plane, not a proxy. Your customers call your API directly, and MicroAuth only sees account data, configuration and the usage counts your integration reports. It never sees your request bodies, headers, query parameters or responses.

What MicroAuth receives

From your API, through the SDK or the HTTP API:

• SHA-256 hashes of the keys your customers send, never the keys themselves.
• Usage items: the key ID, the status code, a count, the hour it happened, the usage policy and an idempotency key.
• The SDK's User-Agent, so the dashboard can show which version you run.

From people: names, email addresses and the settings they choose. Card details go to Stripe and never reach MicroAuth.

Credentials

Credential	How it is stored
Customer API keys (map_)	SHA-256 hash and a short prefix for display. Shown once
Workspace API keys (mak_)	SHA-256 hash and a short prefix. Shown once
SDK secret keys (mas_)	Encrypted at rest, so editors can reveal them on the Connect tab
Passwords	bcrypt hashes
Two step secrets	Encrypted at rest. Each code is accepted once
Recovery codes	Hashes. Each code works once
Stripe	Only your connected account's ID. MicroAuth never holds your Stripe keys

Rotating the SDK secret. Admins rotate it under Settings, SDK secret key, and choose how long the old one keeps working, from 0 to 168 hours, 24 by default. Deploy the new secret within that window. A leaked secret can read your customers' key hashes and limits and report usage, so rotate it with a grace of 0 if you think it was exposed.

Where checks happen

The SDK runs inside your API, so its checks are exactly as strong as your deployment. That is the point: there is no hop to MicroAuth on the request path. It also means MicroAuth trusts the usage your server reports. Keep the SDK secret on the server, never in a browser or mobile app.

Customers can't get around the checks without getting around your own code. Rate limits are exact per process, and exact across processes once you add Redis.

Isolation

• Everyone in the dashboard acts inside a workspace with a role, and every request is checked against it.
• Each portal has its own sessions, so signing in to one API's portal means nothing on another.
• On a portal, keys, usage, billing and teammates belong to one customer team, and each member's role decides what they can see and change.
• Requests that change data are checked against the site they came from, which blocks cross site request forgery.
• All traffic uses TLS, including portals on custom domains.

Billing integrity

• Every balance change is a ledger entry with a unique reference, so retried webhooks and repeated API calls never credit or charge twice.
• Usage reports are idempotent, and each request is charged at the prices that applied when it was served.
• Stripe webhooks are verified against their signature and stored before they are processed. Subscriptions and payments are read back from Stripe before they are applied, so events that arrive out of order can't roll anything back.
• Every night, each customer's balance is checked against the sum of their ledger, and any difference is flagged to the MicroAuth team.

When MicroAuth is unreachable

Known keys keep working from the cached snapshot, and usage waits in the SDK's queue until MicroAuth is back. With the default settings, the SDK serves known keys from a stale snapshot for up to 15 minutes before it answers 503. New keys can't be checked until MicroAuth is reachable again. See the FastAPI SDK guide for the settings.

Retention

Data	Kept for
Processed Stripe events	90 days
Usage receipts, used to spot duplicate reports	About 45 days
Hourly usage and the activity log	13 months
Expired sessions, sign in codes and invites	Deleted shortly after they expire
Ledger entries and payment records	As long as the account exists
Database backups	14 days, taken daily and checked after each run

The privacy policy explains what we collect and how to ask for deletion.

Reporting a vulnerability

Email security@microauth.com. Please leave working credentials, your customers' data and unrelated personal data out of the first message. Security reports are read first.