Ask an infrastructure team how they authenticate users and you'll get a diagram. Ask them how long it takes to de-authenticate one and you'll get an estimate, usually wrong, usually optimistic. We spend enormous effort on the front door and almost none on the eviction notice. Canva's engineering write-up on rebuilding session revocation for hundreds of millions of active sessions is interesting less for the specific technology choices than for the fact that someone treated revocation as a first-class distributed systems problem rather than a footnote in the auth service.

The half of identity nobody tests

Most offboarding runbooks have the same line: disable the account in AD/Entra ID. Some have a second line about resetting the password. Very few have a line that says confirm the user's existing sessions have ended, in every application, and record how long it took. That gap is where a lot of real-world damage happens — not in some exotic bypass, but in a leaver whose Teams client kept working for the rest of the afternoon, or a contractor whose stolen session cookie outlived the password reset that was supposed to fix it.

The uncomfortable mechanic is that bearer tokens are, by design, valid until they aren't. An access token is a signed assertion that the resource server can validate offline. That's the whole point — it's why OAuth scales — and it's also why revocation is not a state change but a message you have to deliver to every place that might accept the token. Disabling the account stops new tokens being issued. It does not reach into a running session.

PKI has been losing this fight for twenty-five years

If this sounds familiar, it's because we've already watched revocation break at scale once. Certificate revocation lists were the original "distribute a list of things that are no longer valid to everyone who might check" problem. CRLs got too big to fetch, OCSP added a latency and privacy tax and a hard availability dependency, so clients started soft-failing — which means, operationally, that revocation checking became advisory. Mozilla eventually went and built CRLite with compressed probabilistic structures because the naive approaches simply didn't fit in a browser's memory or patience.

Canva's choice to keep durable revocation records in S3 and push compact in-memory indexes out to the application gateways is recognisable rather than surprising. That's the same conclusion the web PKI reached: separate the authoritative durable record from the hot-path lookup, and make the hot-path artefact small enough that every enforcement point can hold the whole thing locally. The claimed 87.5% cut in the revocation cache footprint is an eight-fold reduction, which is the sort of number you get from changing the representation of the data rather than tuning it — the article describes the in-memory indexes as sorted arrays that can be searched directly.

What actually transfers to an enterprise estate

You are not going to build this. If you run a mid-sized IT function, your session revocation is whatever Microsoft, Okta or your SaaS vendors decided it should be. But the design tells you exactly which properties to interrogate in the platforms you already own.

On the Microsoft stack, the relevant machinery is Continuous Access Evaluation. Entra ID's default access token lifetime sits around an hour, with refresh tokens for confidential clients sliding on inactivity over a much longer window. CAE changes the model: instead of shortening token lifetimes and hoping, the resource provider subscribes to critical events — account disabled or deleted, password change, explicit admin revocation, a high user risk signal from Identity Protection — and rejects the token with a claims challenge, pushing enforcement to near real time. In exchange, token lifetime is actually extended to around 28 hours, because you no longer need short expiry as a crude revocation proxy.

That trade is the single most useful thing to internalise here. Shortening token lifetimes is the tempting lever and it's the wrong one: it multiplies your token endpoint load, hurts offline behaviour, and still leaves a window. Event-driven revocation with a locally held index does the job properly. Canva's architecture and CAE are the same idea wearing different clothes.

The awkward part: coverage, not capability

CAE only helps where the resource honours it. Exchange Online, SharePoint, Teams and Microsoft Graph do. Your line-of-business SaaS almost certainly does not, and neither does that internal application someone bolted onto OIDC in 2021 with a 30-day session cookie and no back-channel logout. Revoke-MgUserSignInSession resets the refresh token validity timestamp in Entra ID; it says nothing about the application-side session that federated app minted for itself after a successful SAML assertion. That local session is a completely separate object with its own lifetime, and killing it requires either back-channel logout support or a vendor-specific API.

So the questions worth putting to vendors and to your own developers:

  • When we deprovision via SCIM, does that terminate live sessions, or only block new logins?
  • Do you support OIDC back-channel logout, or any session revocation API we can call from our IR tooling?
  • What is the maximum interval between our revocation call and enforcement at your edge — and is that a contractual number or a hope?
  • If your revocation store is unavailable, do you fail open or closed?
  • How long does an application-side session survive independently of our IdP?

That last one catches people out constantly during token-theft incidents. Adversary-in-the-middle kits steal the session artefact, not the password. Resetting credentials feels like remediation and achieves very little on its own.

Make it a measured number

What works is turning this from an assumption into a test. Pick a live session in each tier-one application, revoke from the admin side, and time it with a stopwatch. Write the number down per application. You end up with a table that is genuinely uncomfortable to look at the first time, and it immediately reorders your priorities — because the applications with the worst revocation latency are rarely the ones you'd have guessed, and they're often the ones holding the most data.

Then put that number into the incident playbook. "Contain the account" is not an action; "revoke sessions in these six systems, expect enforcement within N minutes for four of them and a support ticket for the other two" is. Canva had to engineer their way to that guarantee at that scale. Most of us just need to find out what ours currently is.

Source: Canva Shares S3 Based Architecture for Session Revocation Across Hundreds of Millions of Sessions