How AuthPI is built
Identity infrastructure is a trust product. This page describes how AuthPI isolates tenants, handles credentials, places data, and responds when something goes wrong — precisely, including the parts that are best-effort or still on the roadmap.
Found a vulnerability? Read our disclosure policy or email security@authpi.com.
Tenant isolation
Isolation by architecture, not by query filter
Most multi-tenant systems keep every customer's users in one shared database and rely on
WHERE tenant_id = ? being present on every query. AuthPI
does not work that way. Each issuer — the tenant unit — is provisioned with its own set of
isolated identity stores. Your users' profiles, credentials, and sessions live in storage
objects that belong to your issuer and no one else's. There is no shared user table where a
missing filter could expose another tenant's data.
The same boundary applies to access. API keys are scoped to an account and carry explicit read, write, manage, and delete scopes per resource. Session cookies are signed with the issuer's own key. Cross-tenant access prevention and scope enforcement are covered by a standing end-to-end security test suite that runs against our staging environment before changes ship.
Encryption & credentials
Credential handling
All traffic is TLS in transit, and stored data is encrypted at rest by the underlying platform. Beyond that baseline, these are the practices enforced in code:
Password hashing
Passwords are hashed with Argon2. We never store or log a plaintext password, and hashes never leave the user's regional identity store.
Per-issuer signing keys
Each issuer has its own 32-byte HMAC key for session cookies. A signed session from one tenant is meaningless to every other tenant, and rotating one issuer's key affects no one else.
Timing-safe verification
Secrets, codes, and session signatures are compared with constant-time equality, and sensitive verification paths enforce a minimum response time so failures don't leak information through latency.
Cryptographic randomness
Every token, code, and secret is generated from the platform's cryptographically secure random number generator. Non-cryptographic randomness is never used for anything security-sensitive.
One-time means one-time
Magic-link codes, TOTP codes, and backup codes are tracked after use and rejected on replay.
Sessions that defend themselves
Refresh tokens rotate on every use. A rotated token presented twice marks the session compromised: it is revoked, its tokens are invalidated, and a session.compromised event goes to your webhooks. The user's other sessions are unaffected.
Regional storage
Where identity data lives
Every issuer gets eight regional identity stores. A user is placed in the store nearest to where they signed up, their personal data — profile, credentials, verifiers, devices, consent, sessions — stays in that region for the lifetime of the account, and the assigned region is visible per user through the API.
The guarantees are not uniform, and we state the difference plainly. The two European regions are created under the platform's EU jurisdiction restriction — a hard, infrastructure-enforced pin on where the data may ever live. The other six regions are best-effort placement: honored in practice, not contractually pinned. Routing metadata, account configuration, and audit events are global, not regional.
The full placement model — what is hard, what is best-effort, what is regional versus global, and the exceptions — is documented in the Global Identity Mesh architecture page.
Lifecycle & incidents
Deletion, durability, and incident response
Deletion is a workflow, not a flag. Deleting a user runs a durable, retried cascade: sessions are revoked, personal tokens are revoked, organization memberships are removed, and the user's data and index entries are cleaned up. Each step retries until it succeeds, and a partial failure is surfaced — never silently swallowed. This is the mechanism behind GDPR erasure requests; retention windows are set out in the privacy policy.
Durability. Identity data lives on Cloudflare's durable storage, which replicates writes before acknowledging them. Supporting indexes run on managed databases with point-in-time recovery.
Incident response. Service health is published on the status page. If an incident affects your data, we notify you without undue delay with what we know, what we did, and what you should do — the contractual terms are in the Data Processing Agreement on our legal page. Security reports from researchers follow the disclosure policy: acknowledged within 48 hours, triaged within 5 business days.
Where our claims stop
What we don't claim
AuthPI places personal data in regional storage and gives you the evidence to show where it lives. That helps you meet residency requirements — it does not make your application compliant on its own, and we won't pretend otherwise. Your lawful basis for processing, your own application data, and the regulatory analysis for your situation remain yours.
We do not currently hold SOC 2 or ISO 27001 certification. When we do, it will be stated here with the report available on request — not before.