Auth Under Attack Catching JavaScript Auth Failures in Production Fast

Hi, I'm Viola. I'm a senior software engineer and a site reliability engineer in London. I work a lot with authentication systems and incidents. So, today, I'm going to present Auth under attack. This is where we're going to catch JavaScript auth failures in production very fast.

I want to start with a phrase every engineer has heard at some point, logging has broken. It sounds small, it sounds contained, but it also sounds like one form, one end point, one place to look. Productions are rarely that polite. Auth failures arrive as users bouncing between pages, sessions that keep after trust has changed, and refresh logic that keeps asking the same question and permission that survived longer than they should.

Today, I'm going to walk through Auth as a production trust chain, how it breaks, how to diagnose it quickly, and how to make the same class of failure harder to reintroduce into your system. And the first thing I want to do is separate the visible door from the actual system behind it. The login page is the door. Behind it, the system is making a chain of decisions. It's never just one action that does the error.

Who provided their identity? How long did that proof survive? What happens when the trust changes, and when is the user allowed to do and what? In real life, we understand this clearly. If someone loses a hotel key card, the hotel does not admire the plastic and hope for the best. The old card is revoked immediately, and a new one is issued, and that's how the doors are updated.

Web systems need the same discipline. A cookie existing in the browser, an old role sitting in a token, or a hidden button in the UI does not complete the trust story. The useful question is, which part of the chain still believes that something that is no longer true? That is where production auth incidents usually begin. Two parts of the system carrying different stories about trust.

The core idea of this talk is that auth failures are often trust-state disagreements. The browser may still be carrying an old version of trust where the API has already rejected it. The router is left trying to navigate between two conflicting stories, and the token may still carry yesterday's authority whilst the permission store already knows the user has been downgraded. To keep that investigation precise, I use four verbs: proof, remember, delegate, and enforce.

Each layer can use and look reasonable isolation, whilst the whole system is wrong. At that point, I would stop dividing the incident by team boundary, and start tracing the trust boundary. Who owns the truth, and who is acting on the stale information? To keep that investigation precise, I use four verbs.

The four verbs are proof, remember, delegate, and enforce. Authentication proves who the subject is. Session management remembers that proof over time. Delegation lets a client or another system act with limited authority. So, authorization enforces what is allowed.

When those verbs blur together, the diagnosis gets muddy. A successful login proves identity at one point in time. A token carries claims for a limited context. A visible button belongs to presentation. And the protected action still needs server-side enforcement. And, yes, JWTs can feel very official, but they're not eternal truth carved into a mountain. They are signed statements with scope, audience, and expiry.

So, keeping these words separate keeps the incident readable. So now, let's place those verbs inside the actual production claim. In a modern JavaScript app, auth travels through browser state, cookies, route guards, identity providers, some backend or backend for frontends, API calls, session stores, permission checks, and this list goes on and on.

But sometimes, an edge, you know, or cache layer adding its own chaos spice can actually up the incident. So, users report the visible pain. They are stuck on the login or their dashboard keeps flashing. And it says, you're signed in, but then kicks them out.

You know, I could have done that yesterday, you would say, but this is not something that the system should be actually telling the user to do. So, those reports are valuable symptoms. The vault may actually show the cookie scope, refresh handling, stale claims, and revoke sessions. But the interesting part of this investigation is that the gap between the layers.

So, once you see the chain, that chain from the browser to observability, the common failure shapes become much easier to recognize. So, there are four shapes I look at first. The first is the loop. The user is sent from app to login, then login to app, then app to login again. A very expensive version of no, you hang up first. The second is the go session. When the trust has changed, but old access is still walking around like nobody told it, the party ended. And the third one is the refresh storm. This is where recovery logic keeps trying to recover from its own recovery. And the fourth is the permission leak. This is our old authority surviving a change that should have reduced access. And these are common failure modes of distributed auth systems when ownership is very unclear.

Let's start with the loudest one, the hallway with no exit. Every direct loop usually points to an auth state that cannot settle. The dashboard requires an authenticated user, the login page, something that looks like an active session. The dashboard checks against it and rejects it. The user gets passed back and forth like a parcel nobody wants to sign for. And I would trace the state machine here. Can the app represent unknown, unauthenticated, or authenticated expired, forbidden, logged out or re-authenticated required? When the model only has true and false, production eventually invents the missing state, usually in the least graceful way possible.

And the next failure is quieter, but it's more dangerous. A ghost session. It appears when trust changes, but old access still keeps moving. So password reset is the cleanest example of this.

Yeah. Starting from here. Can the app represent unknown, unauthenticated, or authenticated, expired, or forbidden, or logged out and re-authentication required state? When the model only has true and false, production eventually invents the missing state, usually in the least graceful way possible.

And the next failure is quieter, but it's more dangerous. A ghost session. It appears when trust changes, but old access still keeps moving. So password reset is the cleanest example of this. The user changes their password, the UI celebrates success, and everyone feels emotionally complete. Meanwhile, another browser session or another device must still hold valid authority.

Password reset changes the trust boundary. And multi-factor authentication reset, account disable, or suspicious activity, or even roll down rates, do the same. So existing sessions and refresh tokens need an explicit decision. Strong recovery flows update the whole trust chain. So not just the credential in between. So refresh tokens are where this often becomes quite messy.

The refresh logic begins with a good intention. The access token expires, the app asks for a new one, and the user avoids logging in every five minutes. This is civilized. But the danger starts when refresh has no single owner, or no retry budget, and no single failure state. This is when the API may return 401, the client refreshes, refresh fails, and the original request retries again. Another 401 arrives, another refresh starts. Suddenly the application is performing a tiny, disturbing denial-of-service attack against itself. So refresh extends the trust, so it needs controls. Rotation, relocation, retry limits, and clean path to re-authentication.

The next failure is the one that makes security people stop smiling. Permission leaks. They happen when old authority survives after authority should have changed. And a user was, for example, an admin yesterday. Today they are a viewer. The client still shows the admin area, the token still carries an old claim, and a cached response still exposes something sensitive. The client can improve the experience and make the UI nicer, but the protected action belongs to the server, and the API serving the data or executing the action has to enforce the current permission model. Otherwise, the UI becomes theater, and the server becomes a very important and expensive stage prop.

So now let's connect these failure modes into one production-shaped incident. This is what I call the small change that moved the boundary. The incident I care about here starts with a small diff. This is a PR exert, and someone just adjusts a route guard. They change refresh behavior. Someone else moves a permission check because the UI already handles it. Someone other changes password reset and forgets the existing sessions. The pull request looks harmless because the line count is small. The production input comes from the trust decision that changed. A trust boundary is measured by what the change now allows and what it preserves, what it removes, and what it stops enforcing. So during the investigation, I would ask what authority did this change create? What did we preserve? What did we remove? And maybe left behind? In the broken version, you can see the system disagree with itself. So let's see this broken demo. In this broken mode, focus on the disagreement rather than the UI.

This demo app actually has already suffered enough aesthetically, but the client still believes that the user is trusted, and the backend has started rejecting that trust. The router is reaching to react to incomplete information, and the refresh flow is trying to recover without knowing when to stop. This is why this incident burned time. The system does not really know when to announce and whether it should announce broken invariant in a polite model. It just gives you repeated 401s, redirect chains, and stale UI that contradicts with the state. The visible symptoms are quite messy because the trust chain is inconsistent.

So we diagnose it like an incident with evidence and ownership. This is where I get strict with diagnosis. I want four things, the symptom, the evidence, the broken invariant, and the trust owner. I use the symptom to understand the user's pain, the evidence to understand what the system actually did, the invariant to define what should never have broken, and the owner to find the layer responsible for restoring it. For every redirect loop, the authentication state must settle. For a Go session, revoked trust must stop traveling through old sessions or refresh tokens. For a refresh storm, failure must reach a terminal state.

For a permission leak, role changes must be enforced server side, not client side. Once that invariant has a name, the fix stops feeling like guesswork. When we're actually sitting in production and time is of essence, we want to be able to detect those failures quite quickly. The fastest engineers here are not the ones who guess faster. They are the ones who narrow the system faster. To be able to narrow the system faster, you've got to map it out before you even put it in place.

In this fixed version of the demo, the same scenario becomes much less dramatic, which is exactly what we want, at least in production. In this fixed version, we're running the same scenario that reaches one consistent story. The server becomes the place where trust is decided. Session validity is checked there, permissions are enforced where the data is served, and the refresh is handled as a control path, waste limits, instead of endless negotiation. The client begins neutral, it asks the server it rents from the confirmed state, and if the session is invalid, the user then moves to the clean reauthentication. If the user no longer has this permission, the API will deny this action and it will not refresh. If it doesn't refresh, the system stops bracketing the reality and it just throws the error. The important change here is the ownership, because the trust in this kind of system, it will have now a clear source. After the incident is fixed, the next question is how this class of failure stays out of production next time? This is where we come with our post-mortems. And patching this back would be great in production. You would be a hero, but protecting the environment of your system is much better. The guardrails all serve the same purpose. They stop the uncertainty from becoming authority. Explicit auth states prevent the app from treating unknown as trusted, and bounded refresh keeps recovery from turning into a loop. Session versioning will give you the server that has a clean way to end stale access after some kind of reset, downgrade, or account disable. Service site authorization keeps the client out of the final authority role. The observability gives you the evidence. 401s, 403s, redirect spikes, refresh failures, session revocations, and permission mismatches. Without evidence, authentication becomes vibes with cookies. So some of those guardrails can actually live in tests and monitoring. Some of them can also move into CI. So this is where grantpact fits into the story. Grantpact is an application that I have recently released to create a governance layer between your authentication grants. I use it here as the prevention layer. The system checks all invariants as contracts before the change reaches production. In this example, it flags the admin APIs are no longer server enforced. So it flags the password reason doesn't anymore have the invalidating behavior. So it doesn't validate the existing sessions. It will also flag that refresh failure does not anymore reach the clean terminal state. And the point is visibility.

When I put through my pull request with changes who can access a route, whether sessions survive reset, or how refresh behaves, the trust boundary change appears before it becomes an incident. A fixed bug is useful in production, for sure. But a protected invariant of your system beforehand much better. And that leads to the final doctrine that authentication should become, in fact, boring. Boring is good. And this is the gift that you can even ask introduction. Because good authentication will feel boring. Because the responsibility will be clear at this point. You won't have to keep firefighting the things that you can already define beforehand.

So the server carries the truth, it will carry the most updated source of truth, and the client will carry the experience. Observability will carry your evidence. And your CI pipeline becomes the checkpoint that stops yesterday's incident from walking back into production under a new pull request. That is what I really truly want in production, this kind of predictability. There is no mystery in here, no magical local storage archaeology where we have to dig up what happened and what changed to actually cause the incident. So, you know, we're not in the mood anymore saying that it works unless Safari is in the mood. Just explicit, observable, and really boring authentication state.

And I'll close with my main takeaway of the session. I think authentication is the trust chain. And the hard part is keeping every layer of authentication honest after the user is already inside. I'm talking about sessions, tokens, routes, API, permission models, and the recovery flow. Eventually those layers start to disagree. And the symptoms will look strange. You will see loops, ghost sessions, refresh storms, and permission leaks. The way through it is to find the disagreement, name the invariant that broke, and restore clear ownership. Good authentication will feel boring because responsibility is clear. The server will carry the truth, the client will carry your experience, but your observability is what carries the evidence, the evidence that you will actually need if something gets broken. But your CI here is that checkpoint that will stop and prevent things from leaking into your production.