Security Practices

Avnology ID is designed with security as a foundational principle. This page describes our security architecture, how to report vulnerabilities, and the controls in place to protect your data.

Security architecture

Authentication security

• Password hashing -- Argon2id with memory-hard parameters (64 MB memory, 3 iterations, 4 parallelism), resistant to GPU/ASIC attacks.
• Breached password detection -- Passwords checked against the HIBP (Have I Been Pwned) database of 900M+ compromised credentials on every set/change operation. Compromised passwords are rejected.
• Password history -- Configurable per organization. Prevents reuse of the last N passwords (default: 5).
• Account lockout -- Configurable threshold (default: 5 failed attempts = 15-minute lockout). Lockout applies per-account to prevent brute-force attacks without affecting other users.
• Rate limiting -- Per-IP and per-account rate limits on all authentication endpoints. Rate limit headers (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset) are included in every response.
• CAPTCHA -- Configurable CAPTCHA integration (hCaptcha or Cloudflare Turnstile) on login, registration, verification, and recovery flows. Triggered adaptively after N failed attempts or by the risk engine.
• Passkeys-first -- FIDO2 WebAuthn passkeys are phishing-resistant by design. Origin-bound credentials cannot be reused on lookalike domains.

Token security

• Short-lived access tokens -- 15-minute default lifetime. Configurable per OAuth client (minimum 5 minutes, maximum 1 hour).
• Refresh token rotation -- One-time use. A new refresh token is issued on each refresh. Old tokens are invalidated immediately.
• Refresh token TTL -- Default 30 days. Configurable per client. Absolute expiry prevents indefinite session extension.
• PKCE required -- All authorization code flows require PKCE (Proof Key for Code Exchange). No exceptions, even for confidential clients (OAuth 2.1 requirement).
• No tokens in URLs -- Tokens are only transmitted in Authorization headers or POST request bodies. Query string tokens are rejected.
• Token binding (DPoP) -- Sender-constrained tokens via Demonstrating Proof of Possession (RFC 9449) prevent token theft and replay. See the API reference for DPoP header requirements.
• Consent-chain revocation -- Revoking a refresh token also revokes all access tokens derived from it.

Encryption

In transit

• TLS 1.3 -- All external traffic is encrypted with TLS 1.3. TLS 1.2 is accepted with strong cipher suites only. TLS 1.0 and 1.1 are rejected.
• HSTS -- Strict Transport Security headers on all responses with max-age=31536000; includeSubDomains; preload.
• Certificate transparency -- All TLS certificates are logged to Certificate Transparency logs.
• mTLS (internal) -- Mutual TLS between all internal services. Service identity verified on every request.

At rest

• Database encryption -- PostgreSQL data-at-rest encryption using AES-256. Managed database services (RDS, Cloud SQL) use provider-managed encryption keys.
• Secret encryption -- Sensitive fields (OAuth client secrets, webhook signing keys, API key hashes) are encrypted at the application layer before storage using AES-256-GCM with per-field nonces.
• Backup encryption -- All database backups are encrypted using AES-256 with keys managed by the infrastructure provider's KMS.
• File storage encryption -- Objects in S3/GCS (avatars, logos, SAML certificates) are encrypted using SSE-S3 or SSE-KMS.

Key management

• Key rotation -- JWKS signing keys are rotated automatically every 30 days. Old keys remain available for verification for 90 days after rotation.
• Secrets management -- All runtime secrets (database credentials, encryption keys, API keys) are stored in HashiCorp Vault and injected into containers at startup via the External Secrets Operator. No secrets in environment variables, config files, or container images.
• OAuth client secret rotation -- Client secrets support dual-key rotation with configurable grace periods. Both old and new secrets are accepted during the grace period.
• Webhook signing key rotation -- Webhook secrets support the same dual-key rotation pattern.

Application security

• Content Security Policy -- Strict CSP with nonce-based script execution. default-src 'self'; script-src 'nonce-{random}'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none'.
• CSRF protection -- Token-based CSRF protection on all state-changing endpoints. CSRF tokens are embedded in auth flow objects and must be submitted with every mutation.
• SQL injection protection -- Parameterized queries only. No raw SQL. ORM with prepared statements.
• XSS protection -- React auto-escaping by default. No dangerouslySetInnerHTML. All user-supplied content is sanitized.
• Clickjacking protection -- X-Frame-Options: DENY and CSP frame-ancestors 'none' on all pages.
• MIME sniffing protection -- X-Content-Type-Options: nosniff on all responses.
• Referrer policy -- Referrer-Policy: strict-origin-when-cross-origin to prevent leaking sensitive URL parameters.

Infrastructure security

• mTLS -- Mutual TLS between all internal services via service mesh. Services cannot communicate without valid mutual certificates.
• Network policies -- Deny-all default network policies. Explicit allow rules for each service-to-service communication path.
• Container hardening -- Non-root containers, read-only root filesystem, no privilege escalation, dropped Linux capabilities.
• Container image signing -- All images are signed using Cosign (Sigstore). Kubernetes admission controllers verify signatures before deployment.
• Container scanning -- Automated vulnerability scanning of all container images on every build. Critical/high CVEs block deployment.
• SBOM -- Software Bill of Materials (CycloneDX format) generated for every release. Published alongside container images for supply chain verification.
• Dependency scanning -- Automated dependency vulnerability scanning (Go, npm) runs on every pull request.

Risk engine

Avnology ID includes a built-in risk engine that scores every sign-in attempt in real time. The risk score determines whether additional security measures are required.

Risk factors

Risk levels and actions

Risk actions are configurable via conditional access policies. You can override the defaults per organization.

Querying risk assessments

// Get risk assessment for a recent login
const assessment = await auth.admin.getRiskAssessment({
  sessionId: "session_abc123",
});

console.log(assessment.score);     // 35
console.log(assessment.level);     // "MEDIUM"
console.log

Vulnerability disclosure

Reporting vulnerabilities

If you discover a security vulnerability in Avnology ID, please report it responsibly:

• Email: [email protected]
• PGP Key: Available at https://api-id.avnology.net/.well-known/security.txt
• Response time: We acknowledge reports within 24 hours, provide a severity assessment within 48 hours, and share a fix timeline within 72 hours.

What to include in a report

• Description of the vulnerability
• Steps to reproduce
• Potential impact assessment
• Any proof-of-concept code (do not exploit against production systems)

What we commit to

• No legal action against researchers who follow responsible disclosure
• Credit in our security advisories (unless you prefer anonymity)
• Updates on remediation progress
• Bounty eligibility for qualifying vulnerabilities (see our bug bounty program page)

Please do not disclose vulnerabilities publicly until we have had a chance to address them. We aim to remediate critical issues within 72 hours and high-severity issues within 7 days.

Penetration testing

Avnology ID undergoes annual penetration testing by independent third-party security firms. Findings are remediated and verified before the next test cycle. Pentest reports are available to enterprise customers under NDA.

If you wish to conduct your own penetration testing against your Avnology ID instance, contact [email protected] to coordinate and receive access to a sandbox environment.

SBOM (Software Bill of Materials)

Every Avnology ID release includes a CycloneDX SBOM listing all dependencies (Go modules, npm packages, container base images). SBOMs are:

• Published alongside container images in the registry
• Available for download from the release page
• Machine-readable for integration with your vulnerability management tools

# Download the SBOM for a specific release (from GitHub Releases)
curl -LO https://github.com/avnology/id/releases/latest/download/sbom.cdx.json

Regulatory compliance

Avnology ID is designed to support compliance with the following standards and regulations:

SMS OTP deprecation timeline

Several regulatory bodies are phasing out SMS-based authentication:

See Passwordless SMS for details on our SMS support and migration guidance.

Security headers reference

Every response from Avnology ID includes the following security headers:

Next steps

• GDPR -- Data protection compliance
• SOC 2 -- SOC 2 alignment
• API versioning -- Backward compatibility guarantees
• Webhook security -- Signature verification