Skip to content

Cloudflare Access — Protect an Application

DodaTech 4 min read

Cloudflare Access protects your web applications by placing an identity verification layer in front of them, blocking unauthenticated requests before they reach your origin.

What You Will Learn

You will learn how to add a self-hosted or SaaS application to Cloudflare Access, configure authentication policies, set session durations, and test the end-to-end login flow.

Why It Matters

Adding authentication at the edge means your application never sees unauthenticated traffic. There is no need to modify application code, add login libraries, or manage session cookies on your origin server.

Real-World Use Case

A healthcare SaaS provider added Cloudflare Access to their legacy PHP application. They configured SAML-based authentication with Azure AD, set session timeouts to 15 minutes for Compliance, and added device posture checks for managed devices. The application code was unchanged.

Application Protection Flow

Cloudflare Access intercepts requests before they reach your origin and validates identity against your configured IdP.

sequenceDiagram
    participant U as User
    participant CF as Cloudflare Edge
    participant IdP as Identity Provider
    participant App as Application

    U->>CF: Request app.example.com
    CF->>U: 302 Redirect to IdP Login
    U->>IdP: Authenticate
    IdP->>IdP: Verify MFA
    IdP->>CF: SAML/OIDC Assertion
    CF->>CF: Evaluate Policies
    CF->>App: Forward Authorized Request
    App->>U: Serve Application

Adding a Self-Hosted Application

Create an Access application in the Cloudflare dashboard or via API.

curl -s -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Internal Dashboard",
    "domain": "dashboard.example.com",
    "type": "self_hosted",
    "session_duration": "24h",
    "allowed_idps": ["Azure AD"],
    "auto_redirect_to_identity": true
  }' | jq '.result.name, .result.domain'

Expected output:

"Internal Dashboard"
"dashboard.example.com"

Configuring a SaaS Application

Protect a third-party SaaS application by adding it as an Access app.

curl -s -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Jira",
    "domain": "jira.example.com",
    "type": "saas",
    "session_duration": "8h",
    "saas_app": {
      "consumer_url": "https://jira.atlassian.com",
      "custom_attributes": [
        {"name": "email", "source": {"name": "email"}},
        {"name": "groups", "source": {"name": "groups"}}
      ]
    }
  }' | jq '.success'

Expected output:

true

Setting Session Duration and Policies

Configure session duration and add policies to control access.

curl -s -X PATCH "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "session_duration": "1h",
    "policies": [
      {
        "name": "Team Access",
        "decision": "allow",
        "include": [{"email_domain": {"domain": "company.com"}}],
        "require": [{"auth_method": {"auth_method": "mfa"}}]
      }
    ]
  }' | jq '.result.session_duration, .result.policies[0].name'

Expected output:

"1h"
"Team Access"

Testing the Application Access Flow

Verify that the application is protected by accessing it through a browser or curl.

# Without authentication - should be blocked
curl -s -o /dev/null -w "%{http_code}" https://dashboard.example.com

Expected output:

302

The 302 redirect means Cloudflare Access is redirecting the user to the identity provider for authentication.

# Verify the JWT is issued after authentication
curl -s "https://dashboard.example.com/cdn-cgi/access/get-identity" \
  -H "Cookie: CF_Authorization=..." | jq '.email, .idp'

Expected output:

"user@company.com"
"Azure AD"

Common Mistakes

Mistake Consequence
Not setting allowed_idps during app creation Users see an IdP selection screen instead of automatic redirect
Using overly long session durations Tokens remain valid after user leaves the company
Forgetting to add DNS records for the domain Application domain does not resolve to Cloudflare
Setting auto_redirect_to_identity to false Users see a landing page instead of direct IdP redirect
Not testing with an incognito browser Cached credentials mask policy misconfigurations

Practice Questions

  1. What is the difference between a self-hosted and SaaS application in Cloudflare Access?
  2. Why does Cloudflare Access return a 302 status code for unauthenticated requests?
  3. How does the session_duration setting affect user experience and security?

Challenge

Create a self-hosted Access application for a Node.js app running on port 3000. Configure it with a 30-minute session duration, require Okta authentication with MFA, and set auto_redirect_to_identity to true. Test the flow with curl and verify the JWT identity endpoint returns the correct user email.

Real-World Task

Your company has three internal tools: a Grafana dashboard, a Jenkins CI server, and a WikiJS documentation site. Protect each as a separate Access application under different subdomains. Configure Grafana with a 1-hour session for engineering, Jenkins with a 4-hour session for CI/CD access, and WikiJS with an 8-hour session for all employees. All applications must require MFA and redirect automatically to Azure AD.

FAQ

Can Cloudflare Access protect applications behind a tunnel?

Yes. Cloudflare Access works natively with Cloudflare Tunnel. When a tunnel is configured, Access policies are evaluated at the edge before traffic is forwarded through the tunnel to your origin. The tunnel and Access combination provides end-to-end security with no exposed IP addresses and no inbound firewall ports.

What happens to existing application authentication when I add Cloudflare Access?

Cloudflare Access adds a separate authentication layer in front of your application. Your existing application authentication continues to work. Users authenticate first with Cloudflare Access (using your IdP), then the request reaches your application where your own login system can still enforce its own authentication. This lets you migrate gradually without breaking existing sessions.


Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro — security-first tools for the modern web.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro