Concepts

Compliance

Authio handles authentication and the controls around it. Your app handles your application data and the controls around that. Here is exactly which line is on each side, and how Authio's APIs help you fulfill the ones on yours.

If you sell to enterprises, your customers will ask for a SOC 2 report, a privacy summary, and a DPA. Adopting Authio does not give you those — but it gives you the primitives you need to produce them efficiently. This page is the developer-facing breakdown.

What you inherit from Authio

  • Audit logging. Every consequential identity event lands in audit_events (see Audit log). You can stream it to your SIEM, hand it to an auditor, or surface it inside your own product as “Activity”.
  • Encryption in transit + at rest. TLS 1.2+ enforced at the edge; managed Postgres with full-disk encryption; envelope encryption for sensitive secrets (webhook secrets, audit-stream credentials, SCIM bearer tokens).
  • MFA / phishing-resistant auth. Passkeys (WebAuthn) bound to your domain; magic-link as a fallback; adaptive risk engine for step-up on anomalous attempts. You inherit a state-of-the-art auth path without writing it.
  • Risk signals. Every sign-in produces arisk_decisions row with the firing signals and the score — usable as input to your own fraud / abuse decisions.
  • Key management. Per-project JWT signing keys wrapped by AWS KMS; webhook secrets sealed with ChaCha20-Poly1305 under per-project data keys. Rotation procedures and a record of every rotation live in the key-rotation runbook.
  • Sub-processor disclosure + DPA. Authio publishes its sub-processor list and provides a standard DPA. Your DPA with your customers can chain through ours.
  • Incident response. SEV-classified response times; public status page; customer notification within 4 hours for SEV1 / 72 hours for personal-data breaches; public retrospectives. See incident-response-policy.md.

What stays on your side

  • Your own SOC 2 / ISO 27001 / etc. Adopting a SOC 2 sub-processor does not make you SOC 2. Authio is one of the vendors you list in your own report.
  • Your own privacy policy + DPA. Your customers contract with you. Authio supplies the sub-processor disclosure and a DPA; you incorporate them into yours.
  • DSR (data-subject request) fulfillment for your users. When one of your users emails you to ask for their data or deletion, you reply. Authio gives you the management API to fulfill quickly (see below).
  • Your application data. Authio holds authentication identifiers. The rest of your customer's data lives in your database; encryption, access control, and retention there are your responsibility.
  • Customer-side webhook receivers. Authio signs every webhook with HMAC-SHA256; you verify on receipt with constant-time compare. Our SDKs include the verifier; we cannot enforce it on your endpoint.
  • Endpoint security for your team. MFA, device security, access reviews for your own staff. Authio's dashboard supports passkey login for your operators; the rest is your IT.

Using Authio to fulfill a DSR for your user

When one of your end users (Alice) submits a deletion or portability request to your support team, here is how you fulfill it with Authio:

Deletion

curl -X POST \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"request_type": "deletion", "user_email": "alice@example.com",
       "notes": "submitted via support ticket #1234"}' \
  https://api.authio.com/v1/compliance/dsr

# Response includes the dsr_id; record it in your support ticket.

curl -X POST \
  -H "Authorization: Bearer sk_live_..." \
  https://api.authio.com/v1/compliance/dsr/dsr_<id>/fulfill \
  -d '{}'

The fulfill call hard-deletes Alice's user / identities / sessions / step-up-challenges rows and anonymizes her audit and risk-decision history (user_id NULLed, metadata.user_email replaced with "[deleted]"). You delete the equivalent rows in your own application database.

Export / access / portability

curl -X POST \
  -H "Authorization: Bearer sk_live_..." \
  -d '{"request_type": "export", "user_email": "alice@example.com"}' \
  https://api.authio.com/v1/compliance/dsr

curl -X POST \
  -H "Authorization: Bearer sk_live_..." \
  -d '{"output_artifact_url": "https://your-presigned-url..."}' \
  https://api.authio.com/v1/compliance/dsr/dsr_<id>/fulfill

The export bundle gathers all Authio-held data linked to the user (the users row, identities, memberships, sessions, audit_events, risk_decisions, step_up_challenges) and produces a JSON document. You combine it with your own application data export and deliver to Alice.

The SLA clock starts at the POST /v1/compliance/dsr call. Default due_at is 30 days (GDPR baseline); pass due_days: 45 for CCPA flows.

Sharing Authio's evidence with your auditor

Your auditor will need to know what controls Authio runs and will want to confirm Authio is a SOC 2 vendor for you. Today:

  • Point them at authio.com/compliance for the public posture statement.
  • Point them at controls.md for the TSC control matrix.
  • Email security@authio.com to request the current security & compliance summary one-pager under NDA.
  • When the Type I report ships, it will be available on request under NDA.

See also