Authpipe is the connection layer between your application and third-party APIs. Because we manage integration credentials on behalf of your users — OAuth tokens, API keys, and webhook secrets — security is not a feature we bolt on. It is the foundation of every architectural decision we make.

This page describes how we protect your credentials, what guarantees we provide, and how you can verify our practices.

Encryption

At Rest

All credentials — OAuth tokens, API keys, and webhook secrets — are encrypted using AES-256-GCM before they are written to storage. We use authenticated encryption, which provides both confidentiality and integrity verification — any tampering with encrypted credential data is detected and rejected.

In Transit

All communications between your application, the Authpipe API, and third-party providers use TLS 1.3. We do not support older TLS versions. Certificate pinning is available for Enterprise customers using the self-hosted proxy.

Per-Tenant Key Isolation

Each workspace’s credentials are encrypted with a unique data encryption key (DEK). DEKs are themselves encrypted by a key encryption key (KEK) managed through hardware security modules. This architecture ensures that a compromise of one workspace’s DEK cannot expose credentials belonging to any other workspace.

Key rotation is automatic and transparent. When a KEK is rotated, all associated DEKs are re-encrypted without any service interruption or action required on your part.

Credential Management

Principle of Least Exposure

Authpipe is designed to minimize the surface area where credentials exist in plaintext:

  • Never logged: Credentials are never written to application logs, error reports, crash dumps, or monitoring systems. Log redaction is enforced at the serialization layer, not through post-processing filters.
  • Never displayed in raw form: The Authpipe dashboard shows only masked credential prefixes for identification purposes. Full credential values cannot be retrieved through the dashboard UI.
  • Never used beyond their purpose: Credentials are used exclusively for authorized operations — silent refresh for OAuth tokens, rotation checks for API keys, and health checks to verify connections are alive. We never use your credentials to call Provider APIs for any other reason.

Separation of Secrets

Client secrets (the credentials that identify your OAuth application to a Provider) are stored separately from user credentials (access tokens, refresh tokens, API keys, and webhook secrets). These credential classes use distinct storage backends with independent access controls, encryption keys, and audit trails. A compromise of the user credential store does not expose client secrets, and vice versa.

Credential Lifecycle

When a connection is disconnected, Authpipe immediately revokes the credential with the Provider (when the Provider supports revocation) and deletes the encrypted credential from storage. Credentials for disconnected connections are retained for a maximum of 30 days to allow for reconnection, after which they are permanently purged.

OAuth Security

PKCE (Proof Key for Code Exchange)

Authpipe enforces PKCE on all OAuth flows, even when the Provider does not require it. PKCE prevents authorization code interception attacks by binding the authorization request to the token exchange, ensuring that a stolen authorization code cannot be used by an attacker.

State Validation

Every OAuth flow includes a cryptographically random state parameter that is validated on callback. This prevents cross-site request forgery (CSRF) attacks where an attacker could trick a user into authorizing a connection to the attacker’s account.

Callback URL Allowlisting

Authpipe validates all OAuth callback URLs against a strict allowlist configured per Provider. Wildcard patterns are not permitted. This prevents open redirect attacks where an attacker could intercept authorization codes by manipulating the callback URL.

CSRF Protection

In addition to OAuth state validation, all Authpipe API endpoints that modify state are protected against CSRF through origin validation and token-based protections.

Enterprise Security

Control Plane / Data Plane Separation

Enterprise deployments support a split architecture where the control plane (connection configuration, provider catalog, analytics) runs on Authpipe Cloud while the data plane (token storage, refresh, health checks) runs on your infrastructure. This means your credentials never leave your network, while you still benefit from the managed Authpipe dashboard and configuration experience.

Customer-Managed KMS (BYOK)

Enterprise customers can bring their own KMS keys for token encryption. In this configuration, Authpipe cannot decrypt your tokens without access to your KMS — giving you full control over the encryption lifecycle, including the ability to revoke access and render all stored tokens unreadable.

Open-Source Proxy

The Authpipe token proxy — the component that stores, refreshes, and serves tokens — is fully open source under the MIT License. Enterprise customers who deploy the self-hosted proxy can audit every line of code that handles their credentials. There is no proprietary black box between your tokens and your infrastructure.

Data Residency

Enterprise customers can choose where their token data is stored to meet regulatory and compliance requirements. US and EU regions are available, with additional regions available on request.

Infrastructure

Deployment

Authpipe Cloud runs on Kubernetes with automated deployments, rolling updates, and instant rollback capabilities. Infrastructure is provisioned through infrastructure-as-code with full audit trails. All infrastructure changes require peer review and are logged immutably.

Network Isolation

Token storage is deployed in isolated network segments with no direct internet access. All access to the token store is mediated through the Authpipe API layer, which enforces authentication, authorization, and rate limiting. Database access requires mutual TLS authentication.

Secrets Management

Infrastructure secrets, including database credentials, provider API keys, and internal service tokens, are managed through a dedicated secrets manager with automatic rotation. Secrets are injected at runtime and never stored in source code, configuration files, or container images.

Monitoring and Incident Response

We maintain 24/7 automated monitoring for anomalous token access patterns, unusual refresh rates, and potential credential exposure events. Our incident response process includes immediate token rotation capabilities and customer notification within 24 hours of confirmed incidents.

Penetration Testing

We conduct regular third-party penetration testing of the Authpipe API surface and infrastructure. Findings are remediated according to severity: critical and high findings are addressed within 48 hours; medium findings within 30 days.

Compliance

SOC 2 Type II

We are pursuing SOC 2 Type II certification targeting GA + 12 months. The audit will cover the Security, Availability, and Confidentiality trust service criteria. Once certified, we will make our SOC 2 report available to Enterprise customers under NDA upon request.

GDPR

Authpipe supports GDPR compliance through:

  • Data residency: EU data residency option ensures tokens and connection data remain within the European Union
  • Right to erasure: Tokens and connection data can be deleted through the API or dashboard at any time. Deletion is permanent and irreversible.
  • Deletion API: A programmatic deletion API allows you to fulfill erasure requests from your end users by removing their specific connections and tokens without affecting other data
  • Data processing agreement: Available for customers who require a DPA for their compliance documentation

Provider Compliance

When connecting to Providers that have their own compliance requirements (such as Google’s OAuth security policies or Slack’s app review process), Authpipe’s OAuth implementation follows Provider-recommended security practices, including mandatory PKCE, minimal scope requests, and proper token revocation.

Audit Logging

All security-relevant events are captured in an immutable audit log, including:

  • Token refresh attempts (success and failure)
  • Connection creation and disconnection
  • Provider configuration changes
  • API key creation and revocation
  • Team member access changes
  • Dashboard login events

Audit log retention varies by plan tier (7 days for Free, 30 days for Pro, 90 days for Scale, configurable for Enterprise). Audit logs are available through the dashboard and API.

Responsible Disclosure

If you discover a security vulnerability in Authpipe, please report it to security@authpipe.dev. We ask that you:

  • Provide sufficient detail for us to reproduce the issue
  • Allow reasonable time for us to address the vulnerability before public disclosure
  • Do not access or modify data belonging to other customers

We commit to acknowledging reports within 24 hours and providing an initial assessment within 72 hours. We do not pursue legal action against researchers who follow responsible disclosure practices.

Open Source Transparency

The Authpipe token proxy is fully open source. This is a deliberate architectural decision: the component that handles your most sensitive credentials should be auditable by your security team.

You can review the proxy source code, run your own security audits, and verify that tokens are handled exactly as we describe on this page. We believe transparency is the strongest foundation for trust when it comes to credential management.

The React SDK and all backend SDKs are also open source under the MIT License, giving you full visibility into how tokens flow between your application and Authpipe.