Bringing Zero Trust rules to SaaS logins

Cloudflare Access started as an internal tool to fix a problem that will sound familiar: getting rid of a VPN. Cloudflare's own teams relied on a VPN to reach self-hosted applications like the Atlassian suite, which meant dealing with onboarding friction, slow connections while mobile, and a steady stream of help desk tickets. The Security team had its own complaint. Once someone was on the VPN, they typically had more access than they needed, and visibility into what happened on the private network was limited. Network segmentation attempts were error-prone.

Around that time Google published its BeyondCorp paper, outlining what became known as Zero Trust Security. Instead of trusting anyone on the private network, a Zero Trust perimeter evaluates every request based on identity and other variables. Cloudflare built an implementation on top of its own global network, which had effectively been operating as a Zero Trust perimeter for public Internet applications for years via products like the WAF. Adding identity as another layer meant the same network could protect internal applications too.

By moving to this model, Cloudflare could enforce rules beyond simple usernames and passwords — requiring hardware keys for login, restricting access by country, and integrating device posture checks. The internal tools became secure. But the SaaS applications the company used every day did not. They never passed through Cloudflare's network, so there was no way to apply the same level of control or logging to those logins.

That changes today. Cloudflare Access now supports protecting SaaS applications — any app that can integrate with a SAML identity provider can have Cloudflare's Zero Trust rules applied to every login attempt, even though the application itself is not on Cloudflare's network.

Aggregating identity signals into a JWT

Cloudflare Access is an identity aggregator, not an identity provider. It pulls identity from services like Okta, Ping Identity, OneLogin, or public apps like GitHub. When a user tries to reach a resource, Access prompts them to log in with the configured provider, then combines that identity with other contextual rules — country restrictions, device posture from partners like Tanium, and soon CrowdStrike and VMware Carbon Black — before deciding whether to allow the connection.

All of that context gets summarized into a JSON Web Token (JWT) signed by Cloudflare. A JWT is a standard way to share secure, information-dense data between systems, and it follows a published RFC that lets different systems trust one another. Each JWT is made of three Base64-URL strings:

  • Header: defines the cryptographic operation used on the token's data.
  • Payload: contains name-value pairs (claims) encoded in JSON, typically including the user's identity.
  • Signature: lets the receiving party verify the payload is authentic.

The JWT payload stored by Access includes the user's email address from the identity provider, the authentication domain (something like example.cloudflareaccess.com), the multifactor authentication method used if available, the user's connection country, the audience (the application domain), and an expiration time.

Some applications accept JWTs natively for single sign-on, and Cloudflare has released SSO plugins for providers like Atlassian and Sentry. But most SaaS applications rely on a different standard: SAML.

Converting JWT to SAML at the edge

Where Cloudflare's reverse proxy can sit in front of self-hosted applications, SaaS applications are managed by their vendors — you can't interpose rules on requests before they hit a third-party server. What you can control is the login flow, because SAML-capable SaaS applications let you specify who acts as their identity provider.

Cloudflare Access takes advantage of that relationship by making the SaaS application believe Access itself is the SAML identity provider. When a user attempts to log in, the application redirects them to Cloudflare Access. Access then redirects to the actual identity provider — the same flow used for applications behind Cloudflare's reverse proxy — and applies whatever contextual rules the administrator has configured along the way.

Access still generates a JWT for every login as a standard proof of identity. To send that to a SAML-only application, the system needs to convert the JWT into a SAML assertion. That conversion runs on Cloudflare Workers, in every data center on Cloudflare's network, preserving the availability and low latency of the existing Access login flow. The application sees Cloudflare as the identity provider even though Access is really summing up identity signals from the SSO provider and other sources, then relaying that summary to the application via SAML.

What this unlocks

This approach effectively transforms any identity provider into a SAML-capable SSO option. That matters for the two types of login providers most organizations juggle: purpose-built corporate identity providers like Okta or Azure AD, and "accidental" providers — consumer services like LinkedIn, GitHub, and Google that evolved into login options for other applications. Most corporate applications limited their SSO integration to a single corporate SAML provider, leaving public identity providers unusable for team access. Since Access converts logins from any provider into a JWT and now also issues a standard SAML assertion, your team can use LinkedIn or GitHub credentials to access an application that previously required a corporate SAML provider.

The multi-SSO capability that already existed in Cloudflare Access also extends to SaaS applications. Most SaaS apps integrate with just one identity provider, which is awkward when you work with partners, contractors, or recently acquired teams that standardize on different options. Access can connect to multiple providers simultaneously — even multiple instances of the same provider — letting users pick the option their team uses at login. Because Access merges those identities for the SaaS application, team members on Okta and contractors on LinkedIn can both SSO into the same Atlassian instance.

SaaS integrations also show up in the Access App Launch, the single destination Cloudflare already provides for users to discover internal applications they can reach. Once SaaS applications are integrated with Access, they appear there with no additional administrator configuration required.

Getting started

To start protecting SaaS applications, you need a Cloudflare Access account and a SaaS application supporting SAML SSO. In the Cloudflare for Teams dashboard, choose the "SaaS" application option and follow the steps to configure the application to trust Cloudflare Access as its SSO provider. The feature is available to all Cloudflare for Teams customers, including free plans.

Later this year, Cloudflare plans to expand its Gateway beta to integrate Gateway logging and web filtering with Access for SaaS. The goal is a new rule type that requires users to connect through Gateway when logging in to protected SaaS applications, giving administrators visibility into every action taken within the apps.