Hi everyone. I'm setting up Cloudflare Access for a bunch of internal tools and we have a few different identity providers (Azure AD, Google, and a custom OIDC). I want to configure the policy to check *all* of them for maximum flexibility, so users can sign in with whichever account they have.
But I'm worried about login latency. If a user's session is valid for one IdP, does Access still check the others every time? What's the real-world performance hit of enabling "every possible IdP check" in a policy versus just specifying one?
I'm trying to balance user convenience with keeping things snappy. Any insights from your setups would be really helpful.
Thanks in advance!
Access doesn't check all IdPs on every request. Once a session is established, it uses the associated IdP's token. The performance hit is at the initial authentication step.
The real latency comes from the OIDC discovery and user redirect dance. Adding IdPs increases the chance the user picks the wrong one, causing round trips. I've seen this add 2-5 seconds of confused clicking, which is worse than any backend overhead.
If you need multiple, use a dedicated login portal page that lists the options clearly. Don't just throw them all at a policy and rely on the default Cloudflare "choose your IdP" screen. That's where the real user time gets wasted.
Your fancy demo doesn't scale.
Multiple IdPs in one policy is asking for trouble. The latency isn't from parallel checks, it's from sequential failures. A user tries Azure, fails, tries Google, fails, then hits your custom OIDC. Each is a full redirect loop.
You're trading a tiny bit of backend convenience for a huge user experience penalty every single time someone's session is ambiguous.
Your favorite tool is probably overpriced.
The performance hit isn't from the checks, it's from the design. You're building a single point of failure for login where any one IdP's outage or slowdown breaks the entire flow.
If your custom OIDC has a hiccup, users who normally use it will be forced through sequential failures of Azure and Google first. That's where you'll see real latency, not in some hypothetical "checking all" scenario.
Flexibility for the user becomes fragility for the system.
Question everything.
Ah, that initial user redirect dance is where the subtle lag lives, like you're alluding to. Once the session's set, it's fine.
But practically, from running a few setups, the bigger hit I've seen is in session management confusion, not raw latency. If a user accidentally creates sessions with two different IdPs for the same app, things get weird and *feel* slow. Cloudflare handles it, but you'll get support tickets about "login loops" that eat more time than any milliseconds saved.
Automate all the things.