The technical integration between Cloudflare Access and an enterprise identity provider takes less than an hour in most cases — exchanging metadata, a few URLs, authentication testing. What takes weeks is what comes next: deciding which groups have access to which applications, with what session length, with what MFA requirement, and what to do with external collaborators on a different IdP. Protocol configuration is a documentation detail. Policy architecture is design decision.
SAML, OIDC and what matters when choosing
Cloudflare Access supports both SAML 2.0 and OIDC. For larger enterprise providers — Okta, Azure AD, Google Workspace, OneLogin, Ping Identity, JumpCloud — Cloudflare maintains integration guides with exact field mapping. The choice between SAML and OIDC is rarely a critical technical decision; Both work equivalently for the Access authentication use case.
The practical difference is that OIDC is simpler to configure for modern providers and returns attributes in JWT format directly. SAML requires attribute mapping in XML assertion format, which adds friction in more complex configurations — especially when you want to pass custom attributes from the IdP for use in policies. For new integrations with Okta or Azure AD, OIDC is the path of least resistance.
Multiple identity providers simultaneously
An Access capability that goes unnoticed in initial projects: the same organization can have multiple providers configured and assign different providers to different applications. An application accepts authentication via Google Workspace for employees and via GitHub for external collaborators. Another restricts exclusively to corporate Okta. A third displays the choice menu for the user to select which provider to use.
This solves the frequent scenario of companies with employees in different partner companies, each with their own Azure AD or Google Workspace. Instead of creating guest accounts on all providers, Access accepts multiple providers with different policies per provider. The practical limit is not technical — it is management: each additional provider is a configuration point to maintain and an access vector to monitor.
Groups and authorization synchronization
Access policies that reference groups pull membership directly from the IdP at authentication time. An "allow: group engineering" policy is not a static list in Cloudflare — it's a check against the group in Okta or Azure AD at the time the authentication token arrives. When a collaborator is added or removed from the group on the IdP, the effect is immediate on the next authentication, without manual synchronization on the Cloudflare platform.
This has an important operational consequence: the offboarding process needs to remove the user from the IdP, not just revoke access in each individual application. If the user is deactivated in Okta, all Access policies that depend on that IdP stop working for that account. The active session remains valid until it expires — which reinforces the importance of configuring appropriate session durations per application.
Session duration and MFA enforcement per application
Session duration is configured per application in Access, not globally. For a low sensitivity indoor monitoring application, seven days is reasonable. For SSH access to the production environment, an hour session requires frequent reauthentication, reducing the window for a compromised token. For a database administration panel, 15 minutes may be more appropriate.
MFA can be required at the Access level, regardless of what the IdP does. If the IdP does not enforce MFA by default, Access policy may require second-factor authentication to be used — Access will redirect the user to complete MFA at the IdP if the token does not include this guarantee. Different applications can have different authentication assurance requirements without needing to configure multiple MFA policies on the IdP.
Service tokens for machine-to-machine access
CI/CD pipelines, monitoring agents, webhooks — any automated system that needs to access an Access-protected resource faces a problem: there is no human user to go through the SSO flow. Access solves this with service tokens: a client ID and client secret pair that identify a service as a trusted entity.
The automated service includes the client ID in header CF-Access-Client-Id and the secret in CF-Access-Client-Secret. Access recognizes the service token, evaluates the associated policy, and allows or denies access — generating an audit event like any other access. Service tokens have a configurable expiration date and can be revoked individually without affecting other tokens or users.
How to structure policies before calling
The most common design mistake when adopting Access is creating a per-application policy without a hierarchy model. With dozens of internal applications, maintaining individual policies for each one becomes a considerable operational burden. The alternative is to define reusable access groups — "basic access for all employees", "elevated access for the engineering team", "administrative access for SRE" — and apply them as blocks in each application's individual policies.
The access policy of a new application can inherit a base group and add specific conditions, such as mandatory device posture or time restrictions. When the engineering team grows and a new group is created in the IdP, the reusable group policy update in Access propagates to all applications that reference it automatically.
What needs to be decided before configuring
Technical integration with the IdP is the least of the challenges. The biggest one is documenting policy decisions and their rationale before enabling Access in production. Which applications have automatic access for all employees? Which ones require explicit group approval? How are external employees from partner companies treated? Who keeps groups in the IdP aligned with Access policies?
These questions have no technical answer — they are decisions that the security team and the product team need to make together. Teams that come to the technical setup without having answered these questions often end up with very permissive policies that replicate the VPN problem with a layer of authentication on top.