Trust & security

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

Every claim below is something the platform does today. Your security reviewer is welcome to ask us for the detail behind any of them.

Tokens that don't survive theft

  • Access tokens are sender-constrained (DPoP). A token carries a confirmation claim bound to the client's public key; presented without a matching proof signature, it's refused.
  • Refresh-token reuse revokes the family. If a refresh token is ever replayed, we end the whole token family rather than assume the best.
  • Authorization codes are single-use. Codes are consumed atomically, so a replayed code fails closed — and PKCE (S256) is required on every authorization request, not merely supported.
  • Revocation is immediate. Revoking a session or deprovisioning a user through SCIM ends access on the next request, not when a token happens to expire.

Per-tenant key isolation

  • Every tenant gets its own Ed25519 signing key, generated the first time it's needed. One customer's key never signs another customer's tokens.
  • Private keys are envelope-encrypted at rest under a separate master key, and decrypted only for the moment a signature needs them.
  • Only public material is ever published — the tenant's JWKS and DID document. Nothing secret leaves the vault.

Sign-ins that are verified, not trusted

  • SAML assertions are checked signature by signature, with the audience, recipient, and conditions bound to our service provider. Tampered or re-wrapped assertions are rejected outright.
  • WebAuthn registrations are fully verified — the attestation signature and the relying-party ID are checked, not taken on trust.
  • Our XML signature verification is cross-checked against an independent implementation, so "it passes our own tests" isn't the whole argument.

Accountability

  • Every privileged action lands in a tamper-evident 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.

Reporting a vulnerability

Found something? Email security@oauth.work. We'll acknowledge within two business days. Please don't open a public issue for security reports.