On a Tuesday morning in early 2025, a major identity provider suffered a multi-hour outage that locked thousands of users out of their SaaS dashboards, internal wikis, and CI pipelines. The company's status page showed a single red dot, but the blast radius stretched across hundreds of relying parties. This is the federated blind spot: when your login depends on a live IdP endpoint, an outage becomes a global kill switch. Signed OAuth flows, by contrast, keep working because the token itself carries the proof of authentication. This article compares the two approaches, not to declare a winner, but to show where each genuinely leaks and where it holds.

The IdP Outage That Exposed the Federated Blind Spot

Federated login, whether via SAML or OpenID Connect, treats the identity provider as the single source of truth. Every authentication request, every session validation, every token refresh must round-trip to the IdP. That design is elegant for centralized control but fragile in practice. When the IdP has a bad day, every downstream application inherits the failure.

The Okta outage in early 2024 is a case in point. For several hours, users could not access any application that relied on Okta for authentication. The issue was not with the applications themselves; they were healthy. The problem was that their login flows pointed to a service that was not responding. Some teams reported that even users with active sessions were logged out, because the session validation required a live check with the IdP.

This is the hidden lease in federated logins. The session cookie you hold is not self-sufficient; it is a reference to a remote state. If the IdP forgets that state, or cannot be reached to confirm it, the cookie is worthless. The convenience of single sign-on comes with an implicit promise that the IdP will always be there. When that promise breaks, the cost is not just inconvenience; it is lost productivity, missed deadlines, and frustrated users.

The federated model also makes debugging harder. When an app fails to authenticate, the error message often points to the IdP, but the root cause may be a network partition, a misconfigured certificate, or a clock skew. Each of these requires a different fix, and none of them are under the app's control. The app is left waiting for a service that may not come back.

Consider a concrete scenario: a mid-sized company runs a suite of internal tools—a project tracker, a code repository, and a documentation wiki—all federated through a single IdP. On the morning of the outage, the project tracker is the first to fail, showing a generic "authentication error" to every user. The code repository, which caches sessions more aggressively, still works for a few hours, but then starts rejecting requests as it revalidates. The wiki, configured to check the IdP on every page load, becomes unusable immediately. The support team is flooded with tickets, but they cannot even access the ticketing system because it too is federated. This cascading failure is not hypothetical; it is exactly what happens when the trust anchor is a live endpoint.

Signed OAuth: Tokens That Outlive the Issuer

Signed OAuth flows, typically using JSON Web Tokens (JWTs), take a different approach. The token itself contains the claims: who the user is, what scopes they have, when the token expires. The signature, created with the IdP's private key, proves the token's authenticity. Verification requires only the public key, which can be cached locally.

This means that once a token is issued, the IdP does not need to be online for the token to be accepted. The resource server checks the signature, validates the expiration, and grants access. If the IdP goes down, tokens that are still valid continue to work. Users with active sessions are not logged out. New logins may fail, but existing sessions survive the outage.

The offline capability is not an accident; it is a deliberate design choice. By moving the trust anchor from a live endpoint to a cryptographic signature, the system becomes resilient to transient failures. The cost is that revocation becomes harder: if a user is compromised, you cannot immediately invalidate their token unless you also maintain a blacklist. Short-lived tokens mitigate this risk by limiting the window of exposure.

Key rotation is the mechanism that keeps the trust fresh. The IdP periodically changes its signing keys, and resource servers fetch the new public keys from a JWKS endpoint. If the IdP is down during a rotation, the server may still have the old key cached, so tokens signed with the previous key continue to verify. This graceful degradation is a stark contrast to the federated model, where a single failed request can kill a session.

To make this concrete, imagine a microservices architecture with a dozen services, each verifying JWTs. The auth service issues tokens and publishes its public keys on a JWKS endpoint. One of the services, the payment processor, has strict availability requirements. It caches the JWKS and refreshes it every hour. When the auth service goes down for two hours, the payment processor continues to accept tokens signed with the cached key. The other services, which fetch the JWKS on every request, start failing after the cache expires. The difference is not in the token format; it is in the operational discipline of caching and refreshing keys. The payment processor survives because it was designed for offline resilience.

Federated Logins: Convenience With a Hidden Lease

Federated logins are built on the idea of a shared session. When you log in once, the IdP sets a session cookie, and every relying party trusts that cookie. The convenience is real: no password fatigue, no per-app credentials, no need to remember which email you used for which service.

But the session cookie is a lease, not a possession. It is valid only as long as the IdP says it is. If the IdP session expires, or is revoked, the cookie becomes invalid. The relying party does not know this until it tries to validate the cookie, which requires a call back to the IdP. This is the hidden lease: the app's trust in the user is contingent on a remote service.

The dependency is not just for initial login. Many federated flows revalidate the session on every request, or at least on every refresh. This means that even a brief IdP hiccup can cause a wave of failed requests, as every active user tries to refresh their session at the same time. The IdP, already struggling, gets hit with a thundering herd of validation requests, making the outage worse.

IdP logout is another cascade. When a user logs out of the IdP, the IdP broadcasts a logout request to all relying parties. If any of those requests fail, the user may remain logged in on some services, creating a security leak. Alternatively, if the IdP is down, the user cannot log out at all, which is a different kind of problem. The federated model trades offline resilience for centralized control, and the tradeoff is not always worth it.

There is also a subtle operational cost that often goes unnoticed: the need to maintain a highly available IdP. Since every authentication and session validation depends on it, the IdP must be deployed across multiple availability zones, with failover and load balancing. This is not trivial. A small team might rely on a managed IdP, but that does not eliminate the risk—it just moves it to the vendor. The vendor's outage becomes your outage, and you have no direct control over the recovery time. In contrast, with signed OAuth, you can make your own services resilient by caching keys and designing for offline operation, even if the IdP is a third party.

The Supply-Chain Angle: Compromised IdP, Compromised Everything

Federated trust concentrates power in a single key. If an attacker compromises the IdP's signing key, they can forge authentication for any user on any relying party. The blast radius is enormous: every app that trusts the IdP is now vulnerable. This is the supply-chain risk that keeps security teams up at night.

Recent breaches have shown that identity providers are a prime target. Attackers know that a single compromise can unlock thousands of downstream systems. The SolarWinds attack, though not an IdP, demonstrated how a single trusted vendor can become a vector for widespread compromise. The same logic applies to federated login: one key to all doors.

Signed OAuth, when implemented with per-service keys, limits the blast radius. Each resource server can have its own key pair, or at least its own audience restriction. If one service's key is compromised, the attacker can only forge tokens for that service, not for the entire ecosystem. This is a meaningful security improvement, even if it adds operational complexity.

The tradeoff is that key management becomes more distributed. Each service must handle its own key rotation, storage, and revocation. This is more work, but it is also more resilient. A single compromised key does not bring down the whole system. The supply-chain risk is contained, not eliminated.

Consider a real-world example: a large e-commerce platform uses signed OAuth for its internal services, but each service has its own audience claim. The order service accepts tokens with an audience of "order-service", while the inventory service requires "inventory-service". If an attacker compromises the key used to sign tokens for the order service, they can only forge orders, not access inventory or customer data. This is a significant improvement over a federated model where a single IdP key would unlock everything. The cost is that the platform must manage multiple keys, but the security benefit is clear.

What Each Gets Right: A Balanced Tradeoff

Federated login gets the user experience right. Single sign-on is a genuine convenience, and for many organizations, the reduction in password fatigue is worth the operational risk. Centralized revocation is also a plus: when an employee leaves, you can disable their account in one place, and all relying parties immediately stop accepting their sessions.

Signed OAuth gets the resilience right. Offline verification means that the system keeps working when the IdP is unreachable. Fine-grained control is another advantage: each service can define its own scopes and audiences, limiting what a token can do. This is particularly valuable in microservice architectures, where different services need different levels of access.

The choice between the two is not about which is objectively better; it is about which tradeoff you can live with. If your users are internal and your IdP is highly available, federation may be fine. If you are building a public API that must be reliable even when your auth service has a bad day, signed OAuth is the safer bet.

Reasonable people disagree on this. Some argue that the convenience of federation is worth the risk, especially for small teams that cannot afford to build and maintain their own auth infrastructure. Others point out that the cost of an outage, in terms of lost revenue and user trust, far exceeds the cost of implementing signed tokens. The right answer depends on your threat model and your tolerance for downtime.

Let's put some numbers on it, hedged as ranges. A typical enterprise outage can cost between $5,000 and $10,000 per hour in lost productivity, according to industry estimates. If a federated IdP outage lasts for four hours, that is $20,000 to $40,000 in direct costs, not counting reputational damage. Implementing signed OAuth might take a few weeks of engineering time, which could cost $20,000 to $50,000 in salaries. The break-even point is one or two outages. For a company that values reliability, the investment pays off quickly.

Practical Patterns: Making OAuth Leak Less

If you choose signed OAuth, there are patterns that reduce the leaks. First, use short-lived access tokens, typically in the range of 5 to 15 minutes. This limits the window in which a stolen token can be used. The tradeoff is that users must refresh more often, but refresh tokens can be long-lived and stored securely.

Second, implement proper key rotation. Rotate your signing keys on a regular schedule, and keep the previous key valid for a grace period to allow tokens to expire naturally. This reduces the risk of a compromised key being used indefinitely. The JWKS endpoint should be served from a CDN or cached aggressively, so that resource servers can fetch keys even if the IdP is under load.

Third, cache the JWKS on the resource server. This is the single most important pattern for offline resilience. If the IdP goes down, the server can still verify tokens using the cached public key. The cache should be refreshed periodically, but should not be a hard dependency for every request.

Fourth, design refresh tokens with a fallback. If the IdP is unreachable, the refresh flow may fail. In that case, you can allow the user to re-authenticate with a different method, or you can extend the access token's lifetime temporarily. The goal is to avoid a hard failure when the IdP is merely slow, not dead.

Finally, monitor for signature failures. An increase in failed signature verifications can indicate a key rotation issue, a clock skew, or an attack. Alerting on this metric can help you catch problems before they become outages. The patch cadence of your auth library matters as much as the configuration.

When to Choose Federated Anyway

There are legitimate reasons to choose federated login despite its fragility. Small organizations with limited ops capacity may not have the resources to manage their own auth infrastructure. A managed IdP provides a level of security and compliance that they could not achieve on their own. The centralized audit trail is also valuable for compliance requirements, such as SOC 2 or GDPR.

User convenience is another factor. SSO is a feature that users expect, and it reduces the burden on IT support. If your user base is non-technical, the friction of separate logins may be a dealbreaker. Federation is the pragmatic choice for many products.

But even if you federate, you can plan for IdP failure. Implement a fallback that allows users to log in with a local account, or at least provides read-only access to critical data. Cache sessions client-side with a reasonable expiration, so that a brief IdP outage does not log everyone out. The goal is not to eliminate the dependency, but to reduce its impact.

A hybrid approach is also possible: federate for user authentication, but issue your own signed tokens for service-to-service communication. This gives you the convenience of SSO for humans, while keeping the resilience of signed tokens for machine-to-machine calls. The budget you allocate for this complexity should be proportional to the risk you are trying to mitigate.

In the end, the choice is not about which technology is more secure in the abstract. It is about which failure mode you are more willing to tolerate. Federated logins leak when the IdP dies; signed OAuth leaks when a key is compromised. Both are real risks, and both can be mitigated with careful design. The toolchain tenure of your auth stack is a decision you will live with for years, so choose deliberately.