Wocha Docs

Security

How Wocha protects customer data, credentials, and authentication infrastructure.

Wocha is an authentication and authorisation platform built for multi-tenant SaaS and enterprise workloads. This page describes our security architecture, operational controls, and how to report vulnerabilities.

We started a formal security and compliance programme (ISO/IEC 27001 and SOC 2) in September 2026. This page describes what is in place today; see Compliance for certification status.

Security architecture overview

Wocha Cloud runs on a layered architecture:

LayerTechnologyPurpose
IdentityOry KratosRegistration, login, MFA, passkeys, recovery flows
AuthorisationOry HydraOAuth 2.0 / OIDC token issuance and signing keys
PermissionsSpiceDBRelationship-based access control (ReBAC)
Data storePostgreSQLRelational storage for platform and tenant data
Control planePlatform APITenant provisioning, Customer API, webhooks, audit events

Platform metadata (tenant registry, branding, audit events) lives in a shared greet_platform schema.

Data encryption

Encryption in transit

Customer-facing endpoints are served over TLS:

  • Hosted login: https://{tenant}.auth.wocha.ai
  • Customer API: https://{tenant}.api.wocha.ai or https://api.wocha.ai
  • Console: https://console.wocha.ai

Management API keys and OAuth client secrets must only be transmitted over HTTPS.

Credentials we store

API keys are stored as hashes; the full key is shown only once, at creation. Secrets you give us for actions and DNS providers are encrypted before they are stored.

Key management

OAuth access tokens and ID tokens are signed with keys managed by Ory Hydra. The public keys are published at the JWKS endpoint, so relying parties can verify tokens and pick up new keys when they change.

Network security and isolation

  • Tenant separation — identities, OAuth clients and permissions belong to a tenant, and requests are scoped to a tenant before data access. Strengthening tenant isolation is part of our current security programme.
  • Rate limiting — Customer and Account API requests are rate limited, with standard X-RateLimit-* response headers
  • Webhook egress controls — outbound webhook delivery uses DNS pinning to prevent server-side request forgery (see below)

Authentication security

  • Password policies — minimum length, breach detection via Have I Been Pwned (where enabled)
  • MFA — TOTP, WebAuthn/passkeys and recovery codes are supported
  • Session hardening — secure, HTTP-only cookies; session revocation via Customer API

Hosted login pages send Content Security Policy headers.

OAuth and PKCE

ControlDescription
PKCESupported for the authorisation code flow; our SDKs use it by default
Refresh token rotationRefresh tokens are rotated on use where configured
Short-lived access tokensDefault TTLs minimise exposure window

SDK packages (@wocha/nextjs, @wocha/react, etc.) enable PKCE by default.

SSRF protection for webhooks

Outbound webhook delivery resolves the target hostname to IP addresses before connecting and pins the connection to those addresses. This prevents attackers from registering webhook URLs that redirect to internal services (metadata endpoints, localhost, private RFC 1918 ranges).

Additional webhook safeguards:

  • HMAC-SHA256 payload signing with per-subscriber secrets
  • Exponential backoff retry (up to 10 attempts)
  • Delivery logging and manual replay from the Console
  • Optional event filtering per subscriber

Audit logging

Administrative actions such as API key creation and revocation, SSO connection changes, SCIM provisioning, and permission updates are recorded as audit events in the greet_platform.audit_events table, with the actor, target, action, outcome and time. Enterprise plans include audit log export via the Customer API (GET /logs?type=audit).

Authentication events (login success/failure, MFA challenges) are available separately via GET /logs?type=auth.

Vulnerability management

  1. Dependency monitoring — automated dependency alerts and security updates, and a dependency audit in CI
  2. Remediation targets — critical issues with a known exploit, or internet-facing remote code execution or authentication bypass, within 72 hours; other critical issues within 7 days; high within 30 days
  3. Penetration testing — an independent penetration test is planned; we will list it on the Compliance page when it has taken place

Security patches are deployed through our standard release pipeline with changelog entries for customer-visible changes.

Responsible disclosure

If you discover a security vulnerability in Wocha Cloud or our open-source SDKs, please report it responsibly:

Email: security@wocha.ai (also listed in security.txt)

Please include:

  • A description of the vulnerability and its impact
  • Steps to reproduce (proof of concept if available)
  • Affected URLs, tenant slugs, or SDK versions
  • Your preferred contact for follow-up

We aim to acknowledge reports within 2 business days, and to confirm severity and a remediation target within a further 2 business days. We do not pursue legal action against researchers who follow responsible disclosure practices and do not access customer data beyond what is necessary to demonstrate the issue.

We currently do not operate a paid bug bounty programme; recognition in our security advisories is offered with your consent.

Incident response

We handle security and availability incidents in five stages:

PhaseActions
DetectionHealth checks, logs, and customer reports
TriageSeverity classification and an incident owner
CommunicationStatus page updates and direct notice to affected customers
RecoveryRollback or fix, then verification
Post-incidentRoot-cause analysis and tracked follow-up actions

Monitor active incidents on the Wocha status page.

HIPAA

Wocha Cloud is not currently offered for HIPAA-regulated workloads, and we are not signing Business Associate Agreements at present. Contact sales@wocha.ai if you have healthcare requirements.

Previous

Pricing

Next

Compliance

On this page