IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
When identity goes down — resilience & disaster recovery
It is 9 a.m. on the day of the big festival sale. Thousands of shoppers open the app, and support lights up: nobody can sign in. The identity provider is down, and everything that checks identity is down with it. Your goal: plan so that people keep working when the sign-in service fails.
- The IdP is a single point of failure.
- People already signed in keep working until their access token expires.
- A standby region reopens sign-in. A break-glass account lets admins in.
- Do not fix outages with near-permanent tokens.
Why identity is a single point of failure
Most outages break one feature, and the rest keeps going. An identity outage is worse. Every app, API and admin console depends on sign-in. So an IdP (identity provider) outage fails everything at once. It is a single point of failure. A serious design plans for it first.
Zara's pager shows that 100% of sign-ins fail. Shoppers leave with full carts. She cannot even sign in to the console to fix it. The fix needs the very thing that is broken.
Graceful degradation: use the tokens you already issued
A user who is already signed in holds a valid access token. Your API can check it without calling the IdP. It checks the signature with public keys it saved earlier (a JWKS). So during a short outage, people already at work keep working. This is graceful degradation: new sign-ins fail, but signed-in users do not notice.
There is a limit. A signed-in user works only until their access token expires. After that, the app needs a new token, and only the IdP can give one. So the token life must be longer than the outage, or you need a short grace window. This is the trade-off from the token lifetimes lesson.
One more risk: APIs that ask the IdP about every token fail at once. Plan for that (see Go deeper).
Redundancy and failover
Graceful degradation buys minutes. Failover reopens the front door. Run identity in more than one region. Use health checks that keep testing the main one. When it stops answering, traffic moves to a standby. New sign-ins work again, ideally with nobody pressing a button. Avoid hard dependencies: no single region, database or outside call should bring sign-in to zero. The standby must not share the cause of failure. A bad update that goes to both would break both.
The break-glass door
Failover helps users. The break-glass path helps operators. Admins still need a way in to run the incident. It is an emergency credential, set up in advance and heavily audited. It does not depend on the broken IdP (see break-glass and privileged access). It is loudly logged on purpose, because it skips your normal controls. Without it, Zara is locked out of her own recovery.
The toolkit at a glance
| Pattern | Who it saves during an outage |
|---|---|
| Graceful degradation (saved keys) | Everyone already signed in, until their token expires. |
| Failover region + health checks | New sign-ins. The front door reopens. |
| Break-glass access | Admins. An audited way in that does not need the IdP. |
| Key and secret planning | Everyone. A rotation never joins the outage. |
| Status page + messages | The business. People know what is happening. |
Resilience and security pull in opposite directions. Tokens that live longer survive a longer outage, but a stolen long-lived token is also dangerous for longer. Do not fix outages with near-permanent tokens. Use a modest grace window together with fast revocation.
Go deeper: keys, secrets and incident habits
An outage is the worst time to rotate signing keys. Plan rotation so that it never lands on top of an outage (see federation trust). An outage is also an incident, so use the same habits. Keep a status page and a message plan. Practice a runbook (see the 2 a.m. tabletop).
Go deeper: opaque tokens fail in an outage
If your APIs check tokens by asking the IdP (introspection), every check fails when the IdP is down. Self-contained tokens checked with saved keys keep working. See opaque tokens and introspection. If you use introspection, cache answers for a short time. Decide in advance whether to allow or refuse when the IdP does not answer.
Go deeper: how long can you be down?
Two numbers guide the design. The recovery time objective (RTO) is how long you can be down. The recovery point objective (RPO) is how much recent data you can lose. For an IdP, new accounts and password changes made just before the failure may be missing in the standby.
Decide the numbers with the business, then check that your design meets them. Test the failover. A plan never tested is a hope.
🧪 Interactive lab — enable JavaScript to play with this one.
Make sure your grace window does not outlive your kill switch. Grade an issuer's logout and revocation with Logout Check. Check your Shared Signals setup for pushing revocations in an incident with SSF Check.