Security here is mechanism, not marketing. Every claim below maps to a control in the platform,
cited by its RFC where one exists.
Tokens that can't be replayed
- Sender-constrained (DPoP, RFC 9449). Access tokens carry a
cnf.jkt claim binding them to the client's key. A stolen token is inert without the client's private key. - Refresh-token reuse detection (RFC 9700). A replayed refresh token revokes the entire token family — theft is detected, not just prevented.
- Single-use auth codes. Codes live in a Durable Object with an atomic read-then-delete, so a replayed code fails closed.
Keys, per tenant
- The platform holds one Ed25519 issuer key; each tenant gets its own Ed25519 key, generated on first use.
- Private org keys are AES-GCM envelope-encrypted under a master key and stored encrypted at rest — the delivery path never sees a plaintext private key for longer than a verification needs it.
- Tenant credentials resolve via
did:web:<slug>.oauth.work; published material (JWKS, DID docs) is the only thing cached.
Verification done from scratch, on WebCrypto
- All crypto runs through
jose and the WebCrypto SubtleCrypto API — no node:crypto on the request path. - The SAML XML-DSig verifier is implemented from scratch and rejects signature-wrapping and tampering; it's cross-checked in tests against the
xml-crypto library. - WebAuthn packed attestation statements are fully verified, not trusted on faith.
Accountability
- Every privileged action is written to a signed, append-only audit log, queryable via the management API.
- For multi-agent flows, delegated tokens carry an
act actor chain — every call is attributable to who is acting for whom.
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.