Home » Security Bloggers Network » How SSOJet Uses Cloudflare Workers to Deliver High-Availability SSO for SaaS Apps

How SSOJet Uses Cloudflare Workers to Deliver High-Availability SSO for SaaS Apps

by SSOJet - Enterprise SSO & Identity Solutions on December 1, 2025

Single Sign-On (SSO) is one of those things SaaS companies absolutely need—but rarely want to manage.
When it works, nobody notices. When it breaks, everyone notices.

Slow redirects, regional downtime, or a misconfigured IdP can instantly block thousands of users from logging in. Traditional centralized auth systems become bottlenecks—especially when serving global users.

At SSOJet, we’ve faced this challenge head-on. Instead of relying on conventional cloud servers or single-region deployments, we built our SSO engine on Cloudflare Workers, enabling us to deliver authentication at the edge—fast, resilient, and always available.

In this blog, we’ll break down how SSOJet uses Cloudflare’s global compute network to power enterprise-grade SSO for modern SaaS apps.

Why Traditional SSO Architectures Struggle

Most SaaS products still run their authentication stack in one of these architectures:

1) A Single-Region Server (AWS, DO, GCP)

Login traffic has to travel across continents.
Latency spikes during high load.
If the region has an outage → authentication stops.

2) Containerized Auth Services (K8s)

More scalable, but still region dependent.
SAML metadata hosting often isn’t globally distributed.
Callback latency affects user experience.

3) Self-Hosted SAML/OIDC Implementations

Lots of moving pieces (IdP configs, certificates, redirects).
Hard to keep in sync across environments.
Downtime happens when updating configuration or certificates.

All these approaches share one problem:

SSO is treated like a backend feature… but it should be an edge feature.

Authentication is the first request a user makes.
It must be globally fast and globally available.
This is exactly where Cloudflare Workers shine.

Why Cloudflare Workers Are Ideal for SSO

Cloudflare Workers provide a serverless execution environment inside Cloudflare’s 200+ edge locations. That means SSOJet runs logic almost next to the user—not thousands of miles away.

Here’s why that matters:

⚡ Zero Cold Starts

Unlike AWS Lambda, Workers don’t spin up containers.
SAML or OIDC endpoints execute instantly.

Global Edge Network

Your /authorize, /callback, /saml/acs, /metadata, /userinfo endpoints run worldwide.

Built-in Caching & Key-Value Storage

Cloudflare KV = perfect for storing tenant IdP metadata.
Cloudflare D1/Durable Objects = ideal for storing dynamic configs and sessions.

Security Layer Included

Workers run behind:

Cloudflare WAF
Bot detection
DDoS mitigation
Rate limiting

You get enterprise-grade security "by default."

📈 Massive Scalability

Workers scale automatically with traffic.
Even if 10,000 users hit the login page at once, nothing breaks.

This creates the foundation for SSOJet’s High-Availability SSO architecture.

SSOJet’s Edge-Based Authentication Architecture

Below is a conceptual (text-based) diagram of how SSOJet runs:

User → Cloudflare Edge (Worker) 
     → Tenant Resolver (KV + D1)
     → IdP Redirect (SAML/OIDC)
     ← Callback to Worker
     → Token Issuer (Edge Signed JWT)
     → SaaS Application

Let’s break this architecture down step-by-step.

1. Edge Authentication Layer (Cloudflare Workers)

Every SSO request—SAML or OIDC—hits our Cloudflare Worker first.

Endpoints include:

/authorize (OIDC)
/callback
/saml/metadata
/saml/acs
/login
/logout

The Worker detects:

Which tenant is being accessed
Which SSO provider is configured
Whether the user should be routed to OAuth, SAML, or Magic Link
Security requirements (MFA, risk score, CAPTCHA)

This all happens at the edge, within ~10–20ms.

2. Multi-Tenant Configuration Layer (KV + D1)

SSOJet supports multi-tenant SaaS products, where each customer uses:

Their own IdP (Azure AD, Okta, Google, ADFS, JumpCloud, Ping, etc.)
Their own SAML metadata
Their own OIDC secrets
Their own SCIM configuration

To serve this instantly, we store:

Cloudflare KV (Static Data)

SAML metadata XML
Certificates
IdP URLs
Provider-specific settings

KV replicates globally → reads are extremely fast.

Cloudflare D1 (Dynamic Data)

Tenant settings
Enabled/disabled features
Allowed domains
Branding
User session configurations

This combo allows SSOJet to resolve any tenant from anywhere on the planet with minimal latency.

3. Session & Token Layer (Durable Objects + JWT)

Durable Objects:

Ideal for:

Managing per-user sessions
Tracking login state during OAuth and SAML flows
Ensuring consistency during redirects

Edge JWT Signing:

We generate and sign tokens directly on the edge:

Access tokens
ID tokens
Session cookies

No server calls required.
No latency.
No downtime.

4. Failover & High Availability Strategy

SSOJet achieves true high availability because:

1. Authentication runs on 200+ global edge nodes

Even if an entire region goes down, authentication still works elsewhere.

2. KV is globally replicated

SAML metadata & IdP configs are never unavailable.

3. D1 has fallback logic

If write region is slow, read requests still work.

4. No centralized servers to break

No EC2, no Kubernetes, no regional load balancers.

5. Dynamic routing based on user’s email domain

Automatic routing to correct IDP → even during outages.

This results in near-perfect uptime for SSO flows, even during:

Cloud provider outages
Traffic spikes
Deployment errors
Regional failures

SSO Flow Example: How Authentication Works at the Edge

Let’s walk through a typical SAML login.

Step 1 — User Opens SaaS App

SaaS redirects user to:

https://auth.ssojet.com/login?tenant=acme

Step 2 — Worker Identifies Tenant

Worker pulls:

Tenant configuration from D1
SAML metadata from KV

Latency: 3–5ms

Step 3 — Worker Redirects User to IdP

Worker constructs the SAML AuthnRequest and redirects to:

Azure AD / Okta / Google / Ping / JumpCloud, etc.

This is signed at the edge.

Step 4 — User Authenticates at IdP

SSOJet is not involved here.

Step 5 — IdP Sends Response to `/saml/acs`

SSOJet Worker:

Validate SAML response
Send valid SAML response to SSOJet server
Extracts attributes
Performs domain validation
Applies security checks
Creates session

Step 6 — Worker Generates JWT & Redirects User

User is redirected to the SaaS app with:

id_token
access_token
or session cookie

All issued at the edge for minimal latency.

Performance Benchmarks (Internal Tests)

Across 10,000 SSO authentication events:

Operation	Avg Latency
KV read for metadata	2–4 ms
D1 read for tenant	5–9 ms
Worker execution	10–20 ms
Total SAML flow (edge portions)	< 80 ms
Total OIDC flow (edge portions)	< 40 ms

End-to-end SSO times depend on IdP (Azure AD, Okta = 200–500ms),
but SSOJet adds almost no overhead.

Why SaaS Companies Choose SSOJet for Edge-Based SSO

1. No downtime

If the cloud goes down, SSO stays online.

2. Faster global authentication

Edge execution = logins are closer to the user.

3. Lower total cost

No need for:

Load balancers
Kubernetes clusters
Dedicated auth servers

4. Multi-tenant prepared

Each customer has isolated identities & configs.

5. SCIM-ready

Our Workers architecture also powers SCIM provisioning on the edge.

6. Developer-friendly

Simple SDKs and API-first approach for easy integration.

Conclusion

Authentication shouldn’t live in a single region.
It shouldn’t depend on a centralized server.
And it definitely shouldn’t be slow.

By building SSOJet on top of Cloudflare Workers, KV, Durable Objects, and D1, we’ve created a globally distributed authentication engine that delivers: