Trust & security

Built so a breach elsewhere
isn't a breach here.

Every claim on this page is a property of the running system rather than a statement of intent, and each one is something your security reviewer can hold us to.

Checking platform status… Status

The guarantees

What holds, and why.

TokensAccess tokens are sender-constrained with DPoP. A token carries a confirmation claim bound to the client's public key; presented without a matching proof signature, it is refused — so a copied token is inert.
RefreshRefresh tokens rotate on every use, and replaying an already-rotated token revokes the entire family. Theft is detected, not merely blocked.
CodesAuthorization codes are consumed atomically and are single-use, so a replayed code fails closed. PKCE (S256) is required on every authorization request, not merely supported.
RevocationRevoking a session or deprovisioning a user through SCIM ends access on the next request, not whenever a token happens to expire.
Tenant keysEvery tenant gets its own Ed25519 signing key, generated on first use. The private key is envelope-encrypted at rest under a separate master key and decrypted only for the moment a signature needs it.
AssertionsSAML assertions are checked signature by signature, with audience, recipient, and conditions bound to our service provider, and assertion IDs are single-use so a captured assertion cannot be replayed.
PasskeysWebAuthn registrations are verified end to end — the attestation signature and the relying-party ID are checked, not taken on trust.
SecretsClient secrets, API keys, and SCIM tokens are stored only as SHA-256 hashes. Raw values are shown once, at creation, and never again.

One tenant cannot reach another

Every customer is a self-contained issuer at their own subdomain, with its own discovery document, JWKS, and DID.
Tokens issued on a tenant host are signed by that tenant's key, so an issuer mix-up fails verification rather than passing quietly.
Only public material is ever published — the tenant's JWKS and DID document. Nothing secret leaves the vault.
Tenant keys are rotatable, and retired keys stay resolvable so credentials issued under them keep verifying.

Everything privileged is on the record

Every privileged action lands in a tenant-scoped audit log you can query, export, and stream to Datadog, Splunk HEC, or any HTTPS collector.
When an agent acts for a person, the record carries the actor chain — who was acting for whom, at every hop.
Rate limits apply to the authorization, token, registration, credential, management, SCIM, and WebAuthn endpoints, with RateLimit-* headers and 429s on excess.

Verified, not trusted

Our XML signature verification is cross-checked against an independent implementation, so “it passes our own tests” is not the whole argument.
Federated sign-in verifies the identity provider's token against its published keys, checking issuer, audience, and nonce.
Session cookies are HttpOnly and, on HTTPS issuers, carry the __Host- prefix — Secure, path-scoped, and not shareable across subdomains.

Where we are

What we can hand a reviewer today.

We do not hold SOC 2 Type II or ISO 27001 today, and we would rather say so here than let you find out in a questionnaire. What we can give you now:

This page, as a written description of the controls, each one testable against the live system.
A Data Processing Agreement covering our role as processor, sub-processors, and international transfers.
A live health endpoint and status page, rather than a hand-maintained uptime figure.
Full export of your data and tenant configuration through the management API, at any time and without asking us.

If your review needs something not listed here, ask — hello@oauth.work. We will tell you plainly whether we have it.