Reverse proxy: Cloudflare Access
Put chmonitor behind Cloudflare Access and let Access handle authentication. Access authenticates the user and forwards a signed JWT; chmonitor verifies it cryptographically. No shared secret needed — the signature is the proof.
How it works
Section titled “How it works”- Cloudflare Access sits in front of the chmonitor Worker.
- On each request, Access adds a
Cf-Access-Jwt-Assertionheader with a signed JWT. - chmonitor verifies the JWT against your team’s JWKS: checks the
aud, issuer,exp, andRS256signature. - The authenticated subject is the token’s
emailfield (falls back tosub). - When
CHM_CF_ACCESS_*are unset, this mechanism is skipped.
Configuration
Section titled “Configuration”CHM_AUTH_PROVIDER=proxyCHM_CF_ACCESS_TEAM_DOMAIN=https://your-team.cloudflareaccess.comCHM_CF_ACCESS_AUD=<access-application-aud-tag>Set these as Worker secrets in production:
wrangler secret put CHM_CF_ACCESS_TEAM_DOMAINwrangler secret put CHM_CF_ACCESS_AUDSetup steps
Section titled “Setup steps”- In the Cloudflare Zero Trust dashboard, create an Access application that protects your chmonitor Worker route.
- Under the application settings, copy the AUD tag (also called Application Audience).
- Copy your team domain — it looks like
https://your-team.cloudflareaccess.com. - Set the env vars on the server:
Terminal window CHM_AUTH_PROVIDER=proxyCHM_CF_ACCESS_TEAM_DOMAIN=https://your-team.cloudflareaccess.comCHM_CF_ACCESS_AUD=<aud-tag> - Redeploy. Users reaching the Worker URL will be sent through the Access login flow.
- The
VITE_AUTH_PROVIDERclient var does not need to be set for proxy auth; the browser UI does not show a sign-in button (Access handles the login page externally). - Combine with
CHM_API_KEY_SECRETto allow MCP/script access alongside Access-authenticated browser sessions. See API keys. - If both Cloudflare Access (
CHM_CF_ACCESS_*) and trusted-header (CHM_PROXY_AUTH_SECRET) are configured, Access is checked first.