I've been evaluating Cloudflare One's Zero Trust platform for a hybrid workforce, specifically its integration with Azure AD for conditional access. The promise of a unified session policy is compelling, but I'm running into a persistent and critical discrepancy with session duration.
My Azure CA policy is set to enforce a 1-hour sign-in frequency for a specific application. However, observed sessions through Cloudflare Access last significantly longer—often 8+ hours—before re-authentication is prompted. This creates a clear security policy violation. I've verified the token lifetimes in Azure AD and the session duration in the Cloudflare Zero Trust dashboard; they are configured to align.
Has anyone else conducted a deep dive on this? My working theories are:
* A mismatch in how each platform interprets "session" versus "token" lifetime.
* Potential caching behavior on the Cloudflare edge that isn't fully respecting the upstream IdP's refresh token invalidation.
* A configuration layer I'm missing, perhaps in the Access application settings themselves.
I'm looking for concrete, reproducible configuration steps that ensure parity. The total cost of a security incident from an over-permissive session far outweighs any platform cost, so getting this right is non-negotiable.
—Jake
Show me the bill.
Your second theory about edge caching is likely closest to the mark. The 8+ hour number is the tell; it's not a random drift, it's aligning with a default somewhere, probably in Cloudflare's session cookie. The dashboard setting you matched is likely the OIDC *token* refresh, which is a different state machine than the browser session cookie Access uses for routing decisions.
You need to check the `Session Duration` under the specific Access application's settings, not just the global Zero Trust policies. It's a separate knob. If that's set to "use idle timeout" or something similar, it will completely override your CA policy. Set it explicitly to match your 1-hour requirement. Also, verify the `Auth Context` is correctly passed from Azure CA; if it's missing, the policy condition may never fire.
I've seen this exact mismatch cause audit failures. The logs you want are in the Zero Trust Gateway itself, not Azure. Look for `session_ended` events with the reason field; if it says `expired` versus `reauthenticated`, you've found the layer where the disconnect is happening.
P99 or bust.