Cloudflare Access Basics: Secure Apps Without a VPN

Previously in this course, we explored handling CORS in Workers to manage cross-origin traffic safely. Today, we shift focus from API-level security to network and application-level protection using Cloudflare Access.

In the old world of infrastructure, we relied on VPNs (Virtual Private Networks) to create a "secure" perimeter. Once a user was on the VPN, they were often implicitly trusted. This "castle-and-moat" model is brittle and hard to scale. Cloudflare Access moves us to a Zero Trust architecture, where every request—whether from the office or a coffee shop—must be authenticated, authorized, and verified.

Why Zero Trust Matters for Developers

When you deploy internal tools—like a D1 database admin panel or a custom observability dashboard—you don't want them exposed to the public internet, but you also don't want the headache of managing a VPN for your team.

Cloudflare Access acts as a gatekeeper at the edge. Before any request hits your origin server (or your Worker), Cloudflare checks the user's identity against an Identity Provider (IdP) and validates that they meet your specific access policies.

Integrating Identity Providers

To use Access, you first need an Identity Provider (IdP). This is the service that holds your user directory (e.g., Google, GitHub, Okta, or Azure AD).

1. Navigate to Zero Trust: In your Cloudflare dashboard, select "Zero Trust" from the sidebar.
2. Settings → Authentication: Go to "Settings" then "Authentication."
3. Add Identity Provider: Click "Add new." You’ll see a list of popular providers. For developers, "GitHub" is a common starting point.
4. Configure: Follow the prompts to create an OAuth application in your provider's console. You will be given a Client ID and Client Secret. Paste these into the Cloudflare dashboard to complete the handshake.

Setting Up an Access Policy

Once your IdP is connected, you define who gets in. This is done via an Access Application.

1. Access → Applications: In the Zero Trust dashboard, click "Add an application."
2. Self-hosted: Choose "Self-hosted" (this applies to Workers, too).
3. Configure App: Give it a name (e.g., "Internal Dashboard") and define the subdomain (e.g., admin.yourdomain.com).
4. Create Policy: This is the core of Access. You will create a rule:
   • Action: Allow.
   • Selector: Emails, Groups, or even specific IP ranges.
   • Example: You might set a rule where email ends in @yourcompany.com.

Securing Your Dashboard (Worked Example)

If you have a Worker serving an internal UI, you can protect it without changing a single line of code in the Worker itself. Once the application is configured in the Access dashboard, Cloudflare intercepts the request at the edge.

If a user visits admin.yourdomain.com:

1. Cloudflare detects the request is for a protected resource.
2. If the user isn't logged in, they are redirected to your IdP (e.g., GitHub).
3. After a successful login, the IdP sends the user back to Cloudflare with a token.
4. Cloudflare validates the token and sets a session cookie (CF_Authorization).
5. Only after this validation does the request reach your Worker.

Hands-on Exercise

Let’s bridge this to our running project. If you have an internal dashboard Worker:

1. Configure the Application: Set up a new "Self-hosted" application in the Zero Trust dashboard for your Worker's route.
2. Add a Policy: Create a policy that only allows your specific work email to access the URL.
3. Verify: Open your browser in Incognito mode and attempt to hit your dashboard URL. You should see the Cloudflare authentication screen instead of your app.
4. Log in: Authenticate with your configured IdP and verify that you can now see the app.

Common Pitfalls

• Bypassing the Proxy: Access only works if the traffic is proxied through Cloudflare. If you have a DNS record with the "grey cloud" (DNS only), Access policies will not apply. Refer back to Cloudflare Proxy Fundamentals to ensure your app is orange-clouded.
• Token Expiration: By default, sessions might last a long time. If you update your team list, remember that active sessions might persist until they expire. Adjust the "Session Duration" in your Access settings to match your security requirements.
• Hardcoding Identity: Do not try to build your own authentication logic inside your Worker if you can offload it to Access. Using Cloudflare Access is significantly more secure and reduces the surface area of your application code.

FAQ

Can I use Access for APIs? Yes. You can use Service Tokens to authenticate service-to-service communication, which is a great way to secure your internal APIs without managing API keys manually.

Does this replace the WAF? No. Access handles who gets in (Identity), while the WAF (as discussed in Rate Limiting Basics) handles what they are doing (Traffic patterns). You should use both.

Recap

Cloudflare Access shifts security from the application layer to the edge. By integrating an identity provider and defining access policies, you can secure internal dashboards and APIs without the complexity of a VPN. Ensure your traffic is proxied, and leverage the built-in identity checks to keep your infrastructure locked down.

Up next: We will discuss Managing Multiple Environments to help you promote your code from staging to production with environment-specific configurations.