// Security

Zero-knowledge encryption by default. Your tokens are encrypted with keys only you hold, backed by real cryptography.

Bindify encrypts all OAuth tokens with AES-256-GCM. By default, your tokens use client-side keys — zero-knowledge encryption where Bindify never holds the decryption key. Tokens are refreshed on-demand when your connection is used. Advanced users can opt into managed refresh mode for automatic background renewal. Here is exactly how both modes work.

// Token encryption

When you connect a service through Bindify, the credentials your service provider gives us (OAuth tokens) are immediately encrypted using AES-256-GCM and stored in that encrypted form. They are never stored in plaintext. Your secret URL contains 512 bits of cryptographic entropy — making brute-force guessing mathematically impossible.

This means:

• Encrypted at rest — your service provider credentials are never stored in plaintext
• On-demand refresh — tokens are refreshed automatically when you use your connection
• 512 bits of entropy — the math makes brute-force guessing impossible

Client-side Keys (default)

In this mode, the only way to decrypt your stored credentials is with your secret URL or API key. Bindify never stores the decryption key — it exists only in the credential you hold. Without it, your encrypted credentials are unreadable, even to us.

• Bindify employees cannot access your credentials — we don't have the decryption key
• A database breach leaks nothing usable — encrypted data without the key to unlock it
• Per-connection isolation — each connection has its own encryption key; compromising one reveals nothing about others

How refresh works: Tokens are refreshed on-demand when your connection is used. If you opt into managed refresh (advanced), Bindify also refreshes tokens daily in the background — useful for long-idle connections. Managed connections still use AES-256-GCM encryption, but the decryption keys are stored securely within Bindify's infrastructure rather than solely in your secret URL.

Your secret URL and API key are shown once when you connect a service. We never display them again because we never store them. If you lose them, you reconnect (a new OAuth flow generates fresh credentials).

// API key authentication

In addition to secret URLs, Bindify offers API key authentication for programmatic access and CLI tools like Claude Code.

The API key provides identical security guarantees to the secret URL:

• Same encryption — AES-256-GCM, same storage mode as your connection
• Never stored — shown once after OAuth, then discarded
• Same revocation — revoking a connection invalidates both the URL and API key

When to use which:

• Secret URL — Claude Desktop, Claude.ai, Cursor, and other MCP clients (simpler, single value)
• API key — Claude Code CLI, programmatic access, any tool that supports Authorization headers

Both methods are equivalent. Choose whichever fits your client.

// The math: 512 bits of entropy

Every Bindify secret URL and API key contains 512 bits of cryptographic randomness:

To put that in perspective:

// What we do to protect you

// Honest risk assessment

The URL itself is the credential. Treat it like a password:

• Do not share it publicly
• Do not commit it to public repositories
• If you suspect it has been exposed, revoke it immediately from your dashboard

This is a deliberate trade-off: permanent convenience in exchange for treating a URL as a secret. We believe this is the right trade-off for most users, and it is the same model used by thousands of production APIs and webhooks across the industry.

// Credential rotation

All connections (including OAuth with client-side keys) refresh tokens on-demand when used. If you opt into managed refresh, tokens are also renewed daily in the background.

Connections should be rotated annually for security. Click "Re-authorize" in your dashboard before the 1-year mark to keep your connection active.