Hey everyone! 👋 I've been knee-deep in configuring Cloudflare Access for a few client projects lately, and I think I've stumbled onto a real head-scratcher that's been causing some major headaches. I'm hoping someone here has battled this particular beast and can shed some light.
We've got several applications (mostly internal tools like Admin Panels and Reporting Dashboards) protected behind Access policies. The setup *seems* correct—the policies are in place, the identity providers (like Google Workspace and Okta) are connected, and users are in the right groups. However, a subset of authenticated users are getting stuck in an infinite redirect loop. The browser just flashes "You are being redirected..." until it eventually times out or they give up. It's not happening for everyone, which makes it extra tricky to debug.
Here’s a simplified version of the Access policy we're applying:
```json
{
"name": "Internal Apps Policy",
"decision": {
"status": "allow",
"reason": ""
},
"include": [
{
"email_domain": {
"domain": "ourcompany.com"
}
}
],
"exclude": [],
"require": [
{
"everyone": {}
}
]
}
```
**What we've checked so far:**
* **Cookies & Cache:** Obviously, first step. Cleared everything, tried incognito, different browsers. The issue persists for the affected users.
* **Identity Provider Sessions:** Sessions are active and valid at the IdP level. No weirdness with SAML or OIDC token expiry that we can see.
* **Policy Logic:** The `include` is just the email domain, and the affected users are definitely `ourcompany.com`. The `require` is `everyone`, so it shouldn't be adding extra conditions.
* **Application URL:** The URL in the Access app configuration matches exactly what's in the browser (http vs https, subdomain, path). No trailing slash mismatches.
My current suspicion is that there might be some interaction between:
1. **Existing session cookies** from other Access-protected apps causing a conflict.
2. Something funky with the **`auth_domain`** (our `cloudflareaccess.com` subdomain) or the **CORS settings** on our origin.
3. The **`SameSite` attribute** on the `CF_Authorization` cookie under certain browser conditions.
Has anyone else fought this? I'm about to start digging into browser console logs and the `cf.trace` URL parameter to trace the request flow, but if you've got a known fix or another angle to investigate, I'd be incredibly grateful. Sometimes it's just one little checkbox in a forgotten corner of the dashboard!
Let me know what details would help, and I can provide more config snippets.
-- Ian
Integration Ian