← route

LSN 08/10 ACCESS 12 MIN TIER FREE

Access and Zero Trust: putting a login in front of things

How Cloudflare Access challenges visitors at the edge, the identity providers it speaks, and where Tunnel and WARP fit in.

Before this: 05 Pages: hosting your first site

You have a staging site, an admin dashboard, an internal tool. You do not want to write authentication, and you really do not want it on the public internet without a gate. Cloudflare Access is built for exactly this case.

The umbrella product is Cloudflare Zero Trust, which bundles Access, Tunnel, Gateway, and WARP. For most starter use cases, you only need Access and sometimes Tunnel.

What Access does

Conceptually, Access adds a step to the request flow described in lesson 1. Before a request reaches your origin (or your Worker, or your Pages site), Cloudflare checks whether the visitor satisfies an identity policy. If not, it redirects them to a login page. After they authenticate, Cloudflare attaches a signed JWT to the request and lets it through.

Your application can:

  • Trust the proxy and just serve content (simplest).
  • Read and verify the JWT to know who the user is (recommended).

The signed JWT is in the Cf-Access-Jwt-Assertion header. There is a public key endpoint per Cloudflare team domain you can verify against.

Setting up an Access app

The flow:

  1. In the Zero Trust dashboard, AccessApplicationsAdd an application.
  2. Pick Self-hosted for an app at a hostname you control, or SaaS for SSO into a third-party service.
  3. Enter the hostname (e.g., staging.yoursite.com). Cloudflare will intercept all requests matching this pattern.
  4. Define one or more policies. A policy has a name, an action (Allow, Block, Bypass, Service Auth), and rules combining identity conditions.

Example policies that come up constantly:

  • “Allow: emails ending in @yourco.com.”
  • “Allow: members of the Okta group engineering.”
  • “Allow: emails in a list (managed in the dashboard).”
  • “Bypass: requests from a specific IP range (your office).”
  • “Service Auth: service tokens (for CI deployment hooks).”
  1. Pick identity providers. Cloudflare supports Google, GitHub, Microsoft Entra (Azure AD), Okta, OneLogin, SAML, OIDC, plus a built-in one-time PIN flow that emails a code to the visitor.
  2. Save. The next request to that hostname will be challenged.

Service tokens for machines

For non-human callers (CI, monitoring, internal services), use service tokens. Cloudflare issues a client ID plus a client secret. The caller includes them in headers:

CF-Access-Client-Id: <token-id>.access
CF-Access-Client-Secret: <token-secret>

Add a Service Auth policy on the Access app that accepts the token. Now your GitHub Actions can hit a deploy webhook protected by Access without a human in the loop.

Cloudflare Tunnel

The other half of putting a private service online. Cloudflare Tunnel solves the inverse problem: your origin lives behind a firewall, on a home network, or on a laptop, and you do not want to open inbound ports.

Tunnel works by having a small daemon (cloudflared) on your origin make an outbound connection to Cloudflare’s edge. Cloudflare then routes inbound traffic to that hostname through the persistent tunnel.

A typical setup:

# install cloudflared
brew install cloudflare/cloudflare/cloudflared
# or download a release binary

# authenticate (opens a browser)
cloudflared tunnel login

# create a named tunnel
cloudflared tunnel create internal-dash

# point a hostname at the tunnel (creates a CNAME under the hood)
cloudflared tunnel route dns internal-dash internal.yoursite.com

# run it, telling it where to forward requests
cloudflared tunnel run --url http://localhost:8080 internal-dash

internal.yoursite.com is now publicly resolvable, served by your local process, with no inbound ports open on the firewall. Put Access in front of it and you have a production-shaped private app in 15 minutes.

WARP and Gateway, briefly

The other two pieces of Zero Trust:

  • WARP is Cloudflare’s client (basically a VPN-like agent) that routes a device’s traffic through Cloudflare. You install it on laptops and phones. Combined with Access, you can require WARP enrollment as a condition (the visitor must be on a corporate device).
  • Gateway is the outbound counterpart: filter and inspect traffic leaving devices on your network. Useful for security teams; usually overkill for personal projects.

If you are not running a company with employees, you can ignore WARP and Gateway. Access plus Tunnel is the high-leverage pair.

Pricing

Zero Trust is free for up to 50 users. Beyond that, paid plans start at $7 per user per month. For most personal projects, side projects, and small teams, the free tier is the answer.

A concrete scenario

You want to publish a Grafana dashboard for a hobby home-server, but only you should reach it.

  1. Run cloudflared tunnel on the home server, pointing at the Grafana port locally.
  2. Map grafana.yoursite.com to the tunnel.
  3. Create an Access app for grafana.yoursite.com with one policy: Allow your own email via Google.
  4. Done. The hostname is publicly resolvable, served by your home machine, gated by your Google login, end-to-end TLS, no router port forwarding.

This combination is hard to beat.