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:
- In the Zero Trust dashboard, Access → Applications → Add an application.
- Pick Self-hosted for an app at a hostname you control, or SaaS for SSO into a third-party service.
- Enter the hostname (e.g.,
staging.yoursite.com). Cloudflare will intercept all requests matching this pattern. - 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).”
- 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.
- 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.
- Run
cloudflared tunnelon the home server, pointing at the Grafana port locally. - Map
grafana.yoursite.comto the tunnel. - Create an Access app for
grafana.yoursite.comwith one policy: Allow your own email via Google. - 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.