Daniel sent us this one — he's pointing at something that's been quietly nagging at anyone who's built anything on the web in the last decade. We've all clicked "Sign in with Google" or "Sign in with GitHub" without thinking twice. It's frictionless, it's convenient, and it arguably improves security by centralizing authentication behind a provider that actually invests in it. But here's the catch: your entire authentication surface — every service, every dashboard, every internal tool — is chained to a single subscription. Lose access to that Google Workspace or GitHub organization, and you don't just lose email or repos. You lose the ability to log into everything. So Daniel's asking: what are the actual options for breaking that dependency chain? Self-hosted identity providers, dedicated SaaS auth services — what do those landscapes look like, and what are the tradeoffs?
The timing on this is not accidental. We've just come through a wave of Google Workspace policy changes in July, Microsoft's been deprecating pieces of Entra ID, and suddenly a dependency that felt theoretical is getting boardroom attention. The question isn't just academic anymore — it's "what happens if our workspace account gets suspended for a billing dispute and nobody can log into anything for twenty-four hours?
And that's the thing to nail down upfront — the risk here isn't really a protocol failure. 0 and OpenID Connect are solid. The problem is that the identity provider you're federating to is also your email provider, your file storage, your collaboration platform. It's a bundled dependency that was never designed with auth isolation in mind.
When you click "Sign in with Google," you're delegating identity proofing to Google's OIDC endpoint. That's the technical mechanism — your application says "I don't want to manage passwords, I trust Google to tell me who this user is." And Google does that brilliantly. But the dependency chain goes deeper than the protocol. If your Google Workspace admin accidentally disables a user, or there's a billing hold, or Google's automated abuse detection flags the account — suddenly every service that relies on that federated identity is dark. Not because OAuth broke, but because the business relationship with the workspace provider hit a snag.
The dependency is organizational, not cryptographic.
That's the cleanest way to put it. And it leads us to the two families of alternatives Daniel's asking about. On one side, you've got self-hosted open-source identity providers — Dex, Authentik, Keycloak are the big three. On the other, dedicated SaaS identity services — Auth0, Clerk, WorkOS. Both approaches decouple authentication from your workspace provider, but they do it with radically different operational profiles.
Let's start with the self-hosted ones. I want to understand how they actually break the chain at the protocol level.
Dex is the one I find most architecturally interesting. It's a CNCF graduated project — originally created by CoreOS back when CoreOS was still a thing — and it's designed to be an identity hub. The core abstraction is something called a connector. You configure Dex with connectors to multiple upstream identity providers — Google, GitHub, Microsoft, LDAP, SAML, whatever you've got. Then your applications only ever talk to Dex. They don't know or care which upstream provider authenticated the user.
Dex is the federation gateway. Your apps see one identity provider, but behind the scenes Dex is routing to multiple backends.
And this is where the dependency actually breaks. If you've configured Dex with connectors to Google and GitHub and an LDAP directory, and Google goes down or your Workspace account gets suspended, users can still authenticate through GitHub or LDAP. Dex handles the failover transparently. The application never needs to know anything changed.
That's clever. But Dex itself is now a critical piece of infrastructure. What's the operational burden?
Dex requires a PostgreSQL database — that's where it stores client configurations, offline tokens, and connector state. You need to manage that database, handle backups, configure high availability. You need TLS certificate rotation for the Dex endpoints. You need to patch it regularly. The April 2026 release — Dex version two point forty-one — added native passkey-based connectors, which is a big deal because it reduces reliance on password-based upstream providers entirely. But adopting that means you're now managing WebAuthn credential storage too.
If you're running Dex in a Kubernetes cluster, you're probably also running something like Istio or Envoy for the service mesh, which means you've got sidecar proxies talking to Dex for authentication decisions. That's a lot of moving parts.
And that's why Dex is overwhelmingly deployed in environments that already have platform engineering teams. You don't see many solo developers running Dex. It's a Kubernetes-native project — it expects to live in that ecosystem.
What about Authentik? I've heard that one mentioned as more accessible.
Authentik is the interesting counterpoint. It's also open source, but it's designed as an all-in-one identity platform with a web UI for configuration. You can deploy it with a single docker-compose file — it's genuinely accessible to teams with basic DevOps skills. And here's the key architectural difference from Dex: Authentik can function as a primary identity provider, not just a federation proxy. It supports WebAuthn, TOTP, and hardware tokens natively without requiring any upstream IdP at all.
With Authentik, you could theoretically have zero dependency on Google or GitHub for authentication.
You'd configure local users with passkeys or TOTP, and Authentik handles everything — authentication, MFA, user management, all through a web interface. Now, in practice, most deployments still federate to at least one upstream provider, because users expect the convenience. But the dependency is optional, not structural. That's the distinction.
The operational burden?
Lower than Dex in some ways, similar in others. Authentik needs PostgreSQL or MySQL — you're still managing a database. You still need TLS, still need to patch, still need to think about high availability if it's production-critical. The web UI reduces the configuration complexity significantly — you're not hand-editing YAML files for every connector — but you're still running a stateful service that, if it goes down, nobody can log in.
The tradeoff is: you've eliminated the workspace provider dependency, but you've created a new one — yourself.
That's exactly the tension. And it brings us to Keycloak, which is the third major self-hosted option and probably the most enterprise-established of the three. Keycloak's been around forever — it's a Red Hat project, now under the Cloud Native Computing Foundation alongside Dex. It supports SAML, OIDC, user federation from LDAP and Active Directory, and it's got a full admin console. The July 2026 release, version twenty-five, introduced a completely redesigned admin console with declarative configuration — which is a direct response to years of complaints about its historically complex XML-based setup.
XML-based identity configuration. There's a phrase that ages you instantly.
It really does. But the new console is modern — it supports infrastructure-as-code workflows, which means you can version-control your identity configuration alongside your application code. That's a pattern that platform teams have been asking for.
How do you choose between these three? What's the actual deployment pattern?
If you're in a Kubernetes-native environment and your primary need is federating across multiple existing identity providers — Google, GitHub, LDAP, SAML — Dex is the natural fit. It's minimal, it does one thing well, and it integrates cleanly with service meshes. If you want an all-in-one solution with a web UI and native MFA without requiring upstream providers, Authentik is the sweet spot. And if you're in a large enterprise with existing LDAP or Active Directory infrastructure, complex role-based access control requirements, and a need for SAML alongside OIDC, Keycloak is still the heavyweight champion.
None of these are common in single-developer or small-team contexts.
They're really not. The operational overhead — database management, TLS rotation, patching, high availability — doesn't scale down gracefully. A three-person startup does not want to be on call for their identity provider.
Which brings us to the other family Daniel mentioned: dedicated SaaS identity providers. Auth0, Clerk, WorkOS. These are the "I want to decouple from Google but I don't want to run infrastructure" option.
And the architectural difference here is subtle but important. These services are pure identity providers. They don't sell you email, file storage, or collaboration tools. Your dependency is on a company whose entire business is authentication — not on a company that offers auth as a loss leader to sell workspace subscriptions.
The risk profile shifts. Google can suspend your account for a billing dispute on your Workspace subscription, and auth is collateral damage. Auth0 isn't going to suspend your account because of something that happened in your email.
The dependency is narrower. But it's still a dependency. And we got a very concrete reminder of that in March 2026, when Auth0 experienced a four-hour global degradation due to a DNS misconfiguration. Thousands of downstream applications couldn't authenticate users for half a business day. That's the "moved dependency" risk — you've eliminated the workspace provider as a single point of failure, but you've introduced a specialized auth vendor as a new one.
Four hours is a long time when your application's login page just spins.
It's an eternity. And Auth0 is the market leader here — acquired by Okta back in 2021, now running on Okta's identity engine underneath. They've got the most comprehensive feature set, the most compliance certifications, and the largest ecosystem of SDKs and integrations. But that outage showed that even the market leader isn't immune to operational mistakes.
What about Clerk? I see them everywhere in the React and Next.
Clerk is the developer-experience play. They've built their entire product around making auth feel native to modern frontend frameworks — Next.js, Remix, that whole world. You drop in their components, you get pre-built sign-in flows, user profile management, organization management. It's elegant. And in June 2026 they launched Clerk Regions, which gives EU customers data residency controls — user data stays in European data centers. That's a direct response to GDPR compliance requirements that self-hosted solutions handle natively but SaaS providers have historically struggled with.
Clerk is differentiating on compliance features that self-hosted solutions get for free by virtue of you controlling the infrastructure.
And that's the compliance asymmetry. When you self-host, you own the compliance burden entirely — which is a lot of work, but it also means you control the data. When you use a SaaS IdP, you inherit the vendor's SOC 2, HIPAA, FedRAMP certifications — but you have to audit their data handling, you have to trust their subprocessors, and you're subject to their data residency capabilities. Clerk's Regions launch is a recognition that for many customers, especially in Europe, "we store your data somewhere" isn't good enough anymore.
Then there's WorkOS, which seems to be positioning differently from both Auth0 and Clerk.
WorkOS is explicitly "Auth0 for B2B SaaS." Their differentiator is built-in directory sync and SCIM — System for Cross-domain Identity Management — which is the protocol enterprises use to automate user provisioning and deprovisioning. If you're building a SaaS product that sells to companies with existing identity infrastructure — Okta, Azure AD, OneLogin — WorkOS handles the enterprise single sign-on integration so you don't have to build SAML connectors yourself.
It's less about replacing Google sign-in for individual users and more about integrating with corporate identity systems.
Different use case. But it still sits in the same category: a dedicated auth provider that decouples identity from workspace. In WorkOS's case, it's decoupling your application's auth from your customers' identity infrastructure — letting you support Okta, Azure AD, and whatever else without building each integration manually.
We've got two clear paths. Self-hosted: maximum control, maximum operational burden, and the ability to federate across multiple upstream providers simultaneously. SaaS: lower operational burden, narrower dependency, but you're still trusting an external vendor with your authentication surface.
The adoption patterns map cleanly to organizational capacity. Self-hosted IdPs dominate in regulated industries — finance, healthcare, government — and in large enterprises with dedicated platform teams who can manage PostgreSQL clusters and TLS rotation and on-call rotations. SaaS IdPs dominate in startups, mid-market B2B SaaS, and any team whose primary goal is shipping auth in days rather than months.
There's an interesting hybrid pattern I've been seeing too. Using Dex as a federation gateway in front of a SaaS IdP. So Dex handles the upstream diversity and failover — you configure it with connectors to Google, GitHub, and your SaaS IdP — and the SaaS IdP handles user management, MFA, and compliance reporting. You get the best of both worlds: Dex's protocol-level decoupling with the operational convenience of a managed service.
That pattern is gaining traction, especially in organizations that are big enough to have a platform team but not big enough to run their own full identity stack. Dex sits in a Kubernetes cluster, federates to multiple backends, and the SaaS IdP is just one of those backends. If the SaaS IdP has an outage, users can still authenticate through Google or GitHub. If Google has an issue, the SaaS IdP is still available. The failover is transparent.
That's elegant. It also addresses one of the misconceptions I keep hearing — the idea that self-hosting an IdP means you never have to trust a third party. Unless you're running Authentik with purely local WebAuthn credentials and no upstream federation at all, you're still trusting someone. You've just changed who and how many.
That's an important point. Most self-hosted deployments still federate to Google or GitHub or both — because users expect those sign-in buttons. The difference is that the dependency is no longer singular. You're not betting the entire authentication surface on one provider's continued goodwill and billing status.
Another misconception worth busting: the idea that dedicated auth providers are just as risky as Google sign-in because they're both SaaS. The failure modes are different. Google can suspend your account for reasons completely unrelated to authentication — a billing issue, a policy violation in an unrelated service, an automated abuse flag. A dedicated auth provider's entire business model depends on auth working. Their incentives are aligned differently.
The March 2026 Auth0 outage complicates that argument a bit — their entire business is auth, and it still went down for four hours. But the point about suspension risk stands. Auth0 isn't going to cut off your access because of something that happened in your email account. The blast radius of a workspace provider relationship is just wider.
On the self-hosted complexity question — there's a myth that these tools are too complex for small teams, full stop. The reality is more nuanced. Authentik can be deployed with a single docker-compose file and configured through a web UI. A team with basic DevOps skills — someone who can manage a VPS, run Docker, set up TLS with Let's Encrypt — can absolutely run Authentik. It's not zero operational cost, but it's not a full-time job either.
The threshold isn't "can you run an IdP" — it's "do you want to be responsible for authentication uptime." For a three-person startup shipping a product, the answer is usually no. For a twenty-person company with a dedicated infrastructure person and regulatory requirements around data residency, the answer might be yes.
Let's talk about the passkey angle, because I think it changes the calculus here. Dex version two point forty-one added passkey-based connectors. Authentik already supports WebAuthn natively. As passkeys become more widespread — device-bound credentials rather than passwords managed by Google — does the whole federated auth model become less relevant?
That's a fascinating question. If users authenticate with passkeys stored on their devices, the dependency on an upstream identity provider weakens considerably. You don't need Google to vouch for a user's identity if the user can prove possession of a device-bound credential. The identity provider becomes a credential registry rather than an identity authority.
The dependency chain collapses differently. Instead of "I trust Google to tell me who you are," it becomes "I trust your device to prove you hold the credential you registered.
And that shifts the role of the IdP from identity proofing to credential management and recovery. Which is still important — people lose devices, credentials need to be rotated — but it's a fundamentally different trust model.
There's also the EU Digital Identity Wallet coming down the pipeline. Phased rollout starting in 2027. That's a government-backed identity layer that could compete with both workspace providers and dedicated auth vendors. If every EU citizen has a state-issued digital identity that works across services, the "Sign in with Google" button starts looking less essential.
That's a wildcard that could reshape the entire landscape. Government identity systems have historically been clunky and under-adopted, but the EU is putting real regulatory weight behind this one. If it works — and that's a big if — it introduces an identity provider that isn't a workspace vendor, isn't a SaaS company, and isn't something you have to self-host. It's just infrastructure.
Where does this leave someone listening right now who's thinking "I should probably audit my auth stack"?
The actionable step is straightforward. List every service in your organization that uses "Sign in with Google" or "Sign in with Microsoft." Then ask the uncomfortable question: what happens if that workspace account is suspended for twenty-four hours? If the answer is "everything breaks" — and for a lot of organizations, it is — you've got a dependency worth addressing.
Then the decision framework flows from there. If you've got the operational capacity — Kubernetes expertise, database administration, someone who can be on call — self-hosted Dex or Authentik gives you maximum control and multi-provider failover. If you want to decouple from workspace providers without running infrastructure, a dedicated SaaS IdP like WorkOS or Clerk is the pragmatic choice. And if you're somewhere in between, that hybrid Dex-in-front-of-SaaS pattern is worth a serious look.
The key insight is that this isn't a binary choice between convenience and control. There's a spectrum, and the right answer depends on what you're actually protecting and who's available to protect it. A healthcare startup handling patient data has different requirements than a marketing agency's internal tools.
The cost of getting it wrong isn't theoretical anymore. Between the Workspace policy changes and the Auth0 outage and the broader trend of providers tightening their automated enforcement, the "it probably won't happen to us" argument is getting harder to make.
The thing I keep coming back to is how invisible this dependency is until it breaks. Nobody thinks about their authentication stack when everything's working. It's only when the login page spins and the error message is cryptic and nobody can reach the Google Workspace admin because they're on a plane that the architecture suddenly matters.
That's the nature of infrastructure dependencies. They're boring right up until they're catastrophic.
Now: Hilbert's daily fun fact.
Hilbert: In 1903, a meteorite fell near the village of Tsarev in the Volga region of the Caspian basin. When it was finally recovered and analyzed decades later, it was found to contain over forty distinct mineral phases, including several that had never before been observed in a meteorite — making it one of the most mineralogically diverse chondrites ever documented from a single fall.
Forty distinct mineral phases. That meteorite had a more interesting internal structure than most software architectures I've seen.
That's going to sit with me.
This has been My Weird Prompts. Our producer is Hilbert Flumingtop. If you enjoyed this episode, leave us a review wherever you listen — it helps other people find the show. We'll be back next week.
