Single Sign On, Single Blast Radius

The case for single sign on has never needed much help from anybody. Every application an organization buys arrives with its own account store, its own password rules, its own opinion about how long a session lasts, and its own offboarding step that somebody has to remember to perform. Consolidate all of it behind one identity provider and that last item becomes a single action, taken once, by a person whose job it is. In the decentralized version access does not end when employment ends. It just stops being used.

That is a real gain, it is larger than the arguments against it, and I would not hand it back. But there is a second thing consolidation does, and it is less discussed mainly because it is the same property described from the other side. Every application behind the provider now trusts an assertion instead of a credential. It does not know your users. It knows that something it trusts vouched for one, and it has no independent way to check.

Which means the interesting question was never whether the identity provider is well built. It is what counts as the identity provider. The signing key is obviously in scope. So is the console, and the admin roles inside it, and the provisioning connector that writes group membership into forty downstream applications. And so, though nobody puts it on the diagram, is whatever process exists for helping an administrator who has lost their phone at an airport.

Here is the sentence the rest of this is about. You do not get to concentrate the convenience without concentrating the consequence, because they are one property viewed from whichever side you happen to be standing on. What you do get to decide is how much of the blast radius you are willing to look at before you sign, and the honest answer at most organizations, mine included at various points, is not very much of it.

The customers found it before the vendor confirmed it. Okta disclosed on the twentieth of October that its customer support case management system had been accessed. By then several of its customers had already said so themselves: one had detected activity in its own tenant at the end of September, a second told Okta at the start of October and said publicly that confirmation took more than two weeks, and a third was attacked with a stolen session token in the middle of the month. So the first notice a great many security teams got about their identity provider came from other customers of the same identity provider, which is not a channel anybody designed.

What sat in the support system was live sessions. When a login problem is hard to reproduce, support asks the customer to upload an HTTP archive. A HAR file is a recording of a browser session, and it contains the session cookies, which is precisely why it reproduces the problem. So a queue of support tickets was also a store of working sessions for the product those tickets were about, and reading a ticket was enough to become the administrator who filed it. There is no vulnerability anywhere in that chain. It is a support workflow doing exactly what it was designed to do.

The credential left through a browser sync. Okta's account of the initial access is that a service account's credentials had been saved into an employee's personal Google profile while signed in to Chrome on a company laptop. Not a contractor, not an unmanaged device, not a convincing phishing page. A sync feature working correctly, carrying a password from a place with policy attached to it into a place with none, and the boundary that failed is one that appears on no architecture diagram anywhere because it is a setting in a browser.

And then the number moved by two orders of magnitude. On the third of November Okta put the figure at 134 customers, under one percent. On the twenty-ninth it revised: the attacker had run a report containing the name and email address of every user of the support system, roughly ninety-nine and a half percent of customers. Both numbers were published in good faith by an investigation that was still running, and that is the part worth keeping rather than any complaint about this vendor. A percentage released before an investigation closes is a status rather than a finding, and the distance between those two things was five weeks and a factor of a hundred.

Nothing about this required a weakness in SAML, or in assertion signing, or in the multi-factor implementation, or in any of the things a security review of an identity provider actually looks at. Those are the parts with specifications, threat models and conference talks. The compromise ran through a support console reached from a laptop over remote desktop, which has none of those and is not what anybody thinks they are buying.

An account recovery flow is an authentication mechanism. It has to be, because its entire purpose is to establish that the person on the other end is who they say they are without the evidence they normally use. When that flow ends in a human being clicking a button that resets a factor, you have an authentication mechanism whose strength is a support agent's judgment on a bad afternoon, against somebody who has read your help center and rehearsed the story. Nobody threat-models it because it does not look like authentication. It looks like a ticket queue.

And the artifacts a support process collects are chosen for diagnostic value, by people whose job is to resolve tickets quickly, in a system procured to track tickets rather than to hold credentials. Every one of those decisions is defensible on its own. Together they produce a store of session material sitting outside the product's own security model, administered by a different team, with a different retention policy and a different threat model, which is to say with none of the ones that were evaluated.

So the false binary is the one the vendor questionnaire encodes: is this provider secure, yes or no. The real axis is how far the trust you granted extends past the thing you evaluated. You assessed a login service. You took delivery of its help desk, its ticketing system, the browser configuration on an employee laptop, whatever a support engineer is willing to ask you to upload, and every subprocessor on a list you confirmed the existence of.

Ask how long a session is, and whose session it is. There are at least two clocks and they are not connected. The identity provider has a session, and every application behind it issues its own once the assertion is accepted. Killing the first does not touch the second. An application holding an eight hour session cookie will keep working for eight hours after you disable the account, and nothing in the console will tell you that, because from the console the account is disabled and the job looks done.

Find out what actually happens when you press revoke. SAML has had a Single Logout profile since 2005 and support for it ranges from thorough to absent, with a long middle where it is present and quietly fails on one participant. OpenID Connect defines a back-channel logout that a relying party has to implement and many do not. Refresh tokens outlive everything. The only way to know which of your integrations honors a revocation is to revoke one and go look, which is a drill, not a document.

Check what your own support process asks people to upload. The privilege that mattered in October was not administrative at all. It was possession of a diagnostic file that happened to contain a session, collected through a process nobody classified as credential handling. Ask what your support team requests when a login fails, where those attachments live, how long they are kept, and whether anything strips them. Then ask the same question of every vendor whose support desk your own administrators talk to, because you are on the other side of that workflow too.

Then there is the break-glass account you have not tested. Every tenant needs at least two local accounts that do not federate, held on hardware security keys, with credentials split and stored somewhere physical, and excluded from the conditional access rules that would otherwise lock them out along with everything else. Most organizations have created these. Rather fewer have signed in with one this year, which is how you learn that the key was reissued, the account expired, or the rule you added in June covers it after all.

Every organization I have worked with can quote a recovery time objective for its systems, because someone was made to write one down. Ask instead how long it takes, starting now, to end every live session for every user across every federated application, and the room goes quiet. That figure is the one this incident is actually about. It is your exposure window for any credential or session that turns out to have been compromised, and it is the only thing standing between a disclosure and a decision about whether to tell anyone.

The measurement is a drill and it takes a morning. Pick a test user with realistic access, sign in everywhere, leave every tab open, revoke centrally, then have somebody walk the list clicking around in each application and write down the minute each one stops working. The output is a table with one embarrassing row on it. That row is the answer to the question, and until you have run this the answer you would give an auditor is the marketing number from the console.

The drill buys less than it looks like. It measures revocation, not detection, and revocation is worthless until somebody knows to press the button. Through most of October nobody outside a handful of customer security teams knew there was a button to press, and no session drill anywhere would have changed that. Time to revoke is a floor under your response rather than a description of it, which is a reason to know the figure and not a reason to be comforted by it.

Concentration is not a mistake somebody made while buying an identity provider. It is the shape of every piece of infrastructure worth having. The domain registrar can take every service you run off the internet in a single action. The code signing key ends everything downstream of it. The build system writes to production by design, because that is what it is for. The cloud account root can delete the estate on a Tuesday. An argument that condemns all of that has stopped being an argument and become a mood.

The alternative is not safety either. It is diffusion, and diffusion has the worse record, which nobody writes up because nobody notices. Without a central provider every application keeps its own credentials, and the same attacker calls a support desk at a smaller company with thinner tooling, no session concept worth the name, and log retention measured in days. The compromise still happens. It just produces no statement, no forensic report and no essay, because there is nowhere it would have shown up, and a vendor big enough to be examined and written about is offering me a kind of scrutiny I cannot buy from a login form maintained by two people who also do support.

So what I object to is not the concentration. It is that a customer reported the intrusion to the vendor and then waited weeks for confirmation, and that the scope statement moved by a factor of a hundred after most people had stopped reading. I will consolidate trust, I do it, and I would sign for it again next quarter. What I will not defend is consolidating it into a party whose duty to tell me is written in the contract as prompt, with no definition of prompt and no obligation to say what changed when the number does. The single point of trust is fine. The single point of trust with an unspecified clock attached to it is the defect, and it is the one nobody negotiates.

None of this is a case against buying identity. The product's own boundaries did what they were built to do: nothing here turned on a forged assertion, a signing key or a broken factor, and the customers who caught it caught it because they had session monitoring their own identity provider made possible. There was even guidance, published in advance, telling people to strip credentials out of a diagnostic file before sending it. The gap was that the guidance was advice rather than a mechanism, and advice has no owner and does not run.

The door is the part to remember. Every diagram of a federated estate draws the identity provider as the front entrance, hardened, watched, with the good lock on it, and that drawing is accurate. It is also not where anybody came in. There is always a second door, cut into the side of the building by decent people so that colleagues locked out on a Sunday could still get to their desks, and it is not on the diagram, and it opens with a ticket.