ClearFoxSecurity & Data Privacy
ClearFox is self-hosted — your data never leaves your infrastructure. Here’s how the OAuth connection flow works and why it’s safe.
Self-hosted
All data stays on your servers, inside your VPN.
Zero data access
The OAuth proxy handles auth tokens only — never your business data.
Full transparency
You see exactly what permissions are granted and can revoke any time.
How the connection flow works
Connecting a service (Jira, Google, Notion) takes one click. Here’s what happens behind the scenes:
You click "Connect"
A standard OAuth consent screen opens — the same one you see when connecting any app to Google, Jira, or Notion.
This page is hosted by the service itself (Google, Atlassian, Notion), not by ClearFox.
You approve access
You choose which workspace, projects, or pages to share and click "Allow".
You see exactly what permissions are requested. You can revoke them at any time in the service settings.
OAuth proxy exchanges the code
The proxy receives a one-time authorization code and exchanges it for access tokens using ClearFox's registered OAuth app credentials.
This is a server-to-server call that takes milliseconds. The authorization code is single-use and expires immediately.
Tokens are delivered to your server
Tokens are passed to your self-hosted portal via a one-time code (valid for 60 seconds, deleted after use). Never exposed in browser URLs.
Your portal stores the tokens in its own MongoDB database on your infrastructure.
All API calls go directly
From this point, your portal talks to Jira, Google, Notion directly. The proxy is not involved in data transfer.
The proxy is only contacted again for periodic token refresh (~once per hour).
Data flow overview
The proxy is only involved in steps 3 and 5 (initial auth + periodic token refresh). All data queries flow directly from your portal to the service API.
What the proxy does not do
Frequently asked questions
Does ClearFox store my data?
No. ClearFox never stores, processes, or has access to your business data. All data stays on your self-hosted infrastructure. The OAuth proxy only handles authentication tokens — it never sees the content of your Jira issues, Notion pages, or Google Sheets.
Where are tokens stored?
Access and refresh tokens are stored exclusively in your self-hosted MongoDB instance, on your servers, within your network. The proxy temporarily holds tokens for up to 60 seconds during the initial handshake, then deletes them.
What does the OAuth proxy see?
During initial setup: the authorization code and resulting access/refresh tokens (for seconds). During periodic token refresh: the refresh token (to obtain a new access token). At no point does the proxy see or access your actual data — it only handles authentication credentials.
Can I use my own OAuth app instead?
Yes. The proxy is optional — you can register your own OAuth apps in Google Cloud Console, Azure Portal, or Atlassian Developer Console and enter the credentials directly in ClearFox Admin. Alternatively, you can host your own instance of the OAuth proxy and set OAUTH_PROXY_URL in your .env to point to it.
Can I revoke access?
Yes, at any time. Revoke the connection in your service's settings (e.g., Google Account → Security → Third-party access, Atlassian → App access). The tokens on your portal become invalid immediately.
Can I host my own OAuth proxy?
Yes. Set the OAUTH_PROXY_URL environment variable in your .env file to point to your own instance. You'll need to register your own OAuth applications with each provider and configure the proxy with your credentials. This gives you complete control over the entire authentication chain — no external dependencies at all.
Is the proxy open source?
The proxy code is available for review in the oauth-proxy repository. It's a minimal Express.js app — under 300 lines of code — that does nothing but shuttle OAuth tokens. You can fork it and deploy on your own infrastructure.
What about GDPR compliance?
ClearFox is self-hosted — all personal data stays on your infrastructure, under your control. The OAuth proxy acts as a pure authentication intermediary and does not store personal data. This architecture is comparable to "Sign in with Google" used by millions of websites.
What if the proxy goes down?
Existing connections continue to work — your portal already has the tokens. Only new connections and token refresh would be temporarily affected. If a token expires while the proxy is down, your portal retries automatically when it comes back up.
HTTPS & HSTS
ClearFox portal does not set the Strict-Transport-Security header itself. This is intentional — many customers start with HTTP during initial setup before configuring TLS certificates. If the portal forced HSTS, the browser would refuse HTTP connections and lock you out before HTTPS is ready.
HSTS is handled by your reverse proxy. If you use the default Caddy setup from our install script, HSTS is enabled automatically when Caddy provisions a TLS certificate. No action needed.
If you use nginx, add this to your server block:
The portal does set other security headers: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and Referrer-Policy — these are applied automatically on every response.
Still have concerns?
We’re happy to walk through the architecture with your security team.
Contact Security Team