Cloudflare Access — Protect an Application
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
- What is the difference between a self-hosted and SaaS application in Cloudflare Access?
- Why does Cloudflare Access return a 302 status code for unauthenticated requests?
- 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
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