Single sign-on is a convenience that quietly becomes a single point of failure. When your identity provider (Okta, Microsoft Entra, Google Workspace, Auth0, and friends) has an incident, it doesn't take down one app — it takes down the login step for every app wired to it. Suddenly nobody on the team can get into email, chat, the dashboard, or the deploy tool, even though every one of those services is individually healthy.
Why an IdP outage cascades ¶
With SSO, apps don't check your password — they redirect you to the identity provider, which authenticates you and hands back a token. If the IdP can't issue tokens, the redirect hangs or errors and the app can't let you in. Because dozens of apps share one IdP, a single control-plane failure fans out into a company-wide lockout. This is the same cascade dynamic as a shared-infrastructure outage — one upstream, many dependents — just applied to authentication instead of the network layer. The anatomy of an outage covers why shared dependencies concentrate risk.
How to spot that it's the IdP, not the app ¶
- Many apps fail at the login step, together. Not one app broken — the sign-in broken across several at once.
- The apps themselves report healthy. Their status pages are green; only authentication is failing.
- Already-logged-in sessions keep working. Existing tokens are valid until they expire, so people who were already in stay in — it's new logins that fail. That asymmetry is a strong IdP-outage tell.
- The error is at the redirect. You get stuck on the provider's page, or an OIDC/SAML error, rather than an app-specific message.
The check ¶
- Probe the identity provider directly from four regions (e.g. your IdP's login domain). If it's failing globally, that's your answer — the lockout is upstream of every app.
- Check the IdP's status feed. A genuine incident shows as an acknowledged event; a 503 from the auth endpoint is a server-side failure on their side — see what a 503 means.
- Confirm the apps are actually up. The infrastructure hub and each app's status will show the apps healthy — proving the problem is the shared login layer, not the destinations.
What you can (and can't) do ¶
During an IdP outage there's no client-side fix — you can't authenticate around a broken authenticator. What helps:
- Keep existing sessions alive. Don't log out of things you're already in; you likely can't get back. Avoid clearing cookies.
- Use break-glass access. Well-run orgs keep a local admin / emergency-access account that bypasses SSO for exactly this scenario. Now is when it earns its keep.
- Don't retry-storm the login. Hammering sign-in adds load and slows recovery.
- Communicate scope. Tell the team "SSO is down, existing sessions are fine, hold tight" so people stop trying (and stop logging out).
Afterward, the lesson usually isn't "SSO was a mistake" — it's "we needed a break-glass path and a second factor of resilience." An IdP is worth the concentration if you plan for its bad day.
FAQ ¶
How do I know if SSO is down or it's just one app?
If several apps fail at the login step at the same time while their own status pages are green — and people who were already signed in stay working — it's the identity provider, not the apps. A single broken app fails on its own with an app-specific error, not a shared sign-in failure across many.
Why can some coworkers still use the apps during an SSO outage?
They were already authenticated. SSO issues a token that stays valid until it expires, so existing sessions keep working during an IdP outage — only new logins (and token refreshes) fail. That's why "it works for me but not for the person who just tried to log in" is a classic identity-provider-outage signature.
Is there any way to log in while the identity provider is down?
Not through SSO — you can't authenticate around a broken authenticator. The only path in is a break-glass / emergency-access account that bypasses SSO, which organizations should provision in advance. Otherwise the fix is to wait for the provider to recover, keep existing sessions alive, and avoid retry-storming the login.